Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 8 Oct 2002 04:40:13 -0400

Hi Acee,

I would prefer we do not reuse the function code 0x9.

I am wondering why we require three different function codes for OSPFv2
Opaque LSA's itself. Why can't we have one for OSPFv2 Opaque LSA's a value
of 0xa instead? The flooding scope of the OSPFv2 Opaque LSA contained in
such an LSA should be the same as the flooding scope of OSPFv3 LSA.

So LSA type would be
                                 OSPFv2            OSPFv3
   Link Scoped Opaque LSAs        0x09             0x000a

   Area Scoped Opaque LSAs        0x0a             0x200a

   AS   Scoped Opaque LSAs        0x0b             0x400a

Besides although setting the U-bit to 0, helps in flooding optimizations as
we will not be flooding opaque LSA's across non-joint TE parts within an
areas if there are some routers which do not understand this type of LSA. It
may break assumption of flooding of Opaque LSA's thru out the flooding scope
routers.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 8:49 AM
To: [email-masked]
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

Kireeti Kompella wrote:

> Hi Kunihiro,
>
>
>>BTW I haven't submitted the draft but I prepared TE extensions to
>>OSPFv3.  I just define a new LS type for TE then use OSPFv3 built in
>>flooding mechanism.  I believe this is straight forward way to do it.
>>
>
> The draft I submitted also uses the OSPFv3 built in flooding.  It is the
> only way to do it.
>
>
>> LSA function code  LS Type  Description
>> --------------------------------------------------------------------
>> 10                 0x2000a  Traffic-Engineering-LSA

Kunihiro,

Believe you mean 0x200a.

>>
>
> Do you plan to have a different Function Code for each OSPFv2 Opaque LSA
> Type?

Kiretti,

If you take into account changes to the LS type for OSPFv3, the code points
are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and
it
contains the flooding scope and a bit indicating what to do with
unrecognized
types. There are no LS type collisions pervent use of the same function
codes.

                                OSPFv2             OSPFv3
   Link Scoped Opaque LSAs        0x09             0x0009

  Area Scoped Opaque LSAs        0x0a             0x200a

   AS   Scoped Opaque LSAs        0x0b             0x400b

One could argue that the functions types for area and AS scoped opaque LSAs
should be 0xa00a and 0xc00b as well. This would indicate that a router that
does not recognize the type should store and flood it anyway. Any strong
feelings
on this?

Thanks,
Acee
>
> It seems to me to be much easier to have a single code point for all
> OSPFv2 Opaque LSAs.  This way, all defined OSPFv2 Opaque LSAs get
> automatically defined in v3; moreover, if a new Opaque LSA seems to be
> useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA.
>
> Kireeti.
--
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 8 Oct 2002 10:45:47 -0400

>    AS   Scoped Opaque LSAs        0x0b             0x400a

Vishwas,

Completely agree. Could you put this in draft form? This is at least
the second time the question of opaque LSAs and OSPFv3 has been raised.

> may break assumption of flooding of Opaque LSA's thru out the flooding scope

Since opaque LSA's are meant to be used for many applications and the setting
of the U bit is based solely on the function code, I'm not sure that a
TE specific argument is a good reason for not setting the U bit.

--
Acee

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Tue, 8 Oct 2002 08:04:19 -0700

>TE specific argument is a good reason for not setting the U bit.

BTW, I still have big doubt about how many OSPFv2 Opaque LSA can be
exported to OSPFv3 without any change.  Almost cases, at least IPv4
address should be changed to IPv6 address.  TE draft said router-id is
really reachable address.  But this assumption is wrong in case of
IPv6 network.

Before we think about exporting OSPFv2 Opaque LSA to OSPFv3, we should
think about it's applicability.  I've tried it both specification and
implementation stand point...but from my experience unfortunately the
applicability is very low...
--
Kunihiro Ishiguro

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 08:02:01 -0700

Hi Vishwas,

>    AS   Scoped Opaque LSAs        0x0b             0x400a

You've just summarized my draft :-)

Kireeti.