Re: OSPFv2 Opaque LSAs in OSPFv3

[Acee Lindem <[e-mail]>]

Kireeti Kompella wrote:

>>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.
>>
>
> No kidding!
>
>
>>There are no LS type collisions pervent use of the same function codes.
>>
>
> I beg to differ.


The collision is at different flooding scopes. Hence, the LS type
is unambiguous. Since the application of the opaque LSA is specified
by the Opaque type (in the first 8 bits of the link-state ID)
I can't imagine how the reuse of 0x09 at different flooding scopes
would pose a problem.

>
>
>>                                OSPFv2             OSPFv3
>>   Link Scoped Opaque LSAs        0x09             0x0009
>>
>>   Area Scoped Opaque LSAs        0x0a             0x200a
>>
>>   AS   Scoped Opaque LSAs        0x0b             0x400b
>>
>
> Where did you read this?  I see in rfc 2740:


It was simply an extension of RFC 2370. As Vishwas proposed,

OSPFv3 opaque LSAs can be implemented with a single function
code. This seems to be the best solution given that the only
reason for 3 types in OSPFv2 was to support different flooding
scope. It also removes the collision between function codes.


                                OSPFv2             OSPFv3
   Link Scoped Opaque LSAs        0x09             0x000a
   Area Scoped Opaque LSAs        0x0a             0x200a
   AS   Scoped Opaque LSAs        0x0b             0x400a

As for the setting of the U bit, I think this could stand

some discussion.


--
Acee