Re: OSPFv2 Opaque LSAs in OSPFv3

[Acee Lindem <[e-mail]>]

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