Re: OSPFv2 Opaque LSAs in OSPFv3

[Acee Lindem <[e-mail]>]

Manral, Vishwas wrote:

> 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



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.


>
> 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.


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.


>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]]
> Sent: Tuesday, October 08, 2002 8:49 AM
> To: [e-mail]
> 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
>
>


--
Acee