Re: OSPFv2 Opaque LSAs in OSPFv3

[Acee Lindem <[e-mail]>]

I originally thought that we'd simply define an opaque LSA type
for OSPFv3. However, after hearing all the arguments, I think that defining
a new LSA type for each OSPFv3 application is the right direction. In
addition to Bill's points, I think that defining unique LSA types
will lend itself to a more natural implementation and user interface
for handling application specific LSAs.


Bill Fenner wrote:

> To avoid misunderstandings: although I am contributing to this discussion
> because I am an AD, this message is a technical contribution, not a ruling
> from on high.  I'd like to actually have the discussion, not make a mandate,
> so please treat this like you would treat a technical contribution from
> anyone else.
>
> Kireeti says:
>
>>there are a *small* number of
>>currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more.
>>If we analyse the applicability of those LSAs to OSPF v3, and mandate
>>that any future definition of an OSPFv2 Opaque LSA MUST have a similar
>>analysis, that seems to me to address the "backdoor" problem.
>>
>
> Let's step back half a step and look at this solution -- documenting
> the v3 applicability of the existing Opaque LSAs and requiring documentation
> of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each
> OSPFv2 Opqaue LSA type.
>
> Boiling it down to the basics, OSPFv2 Opaque LSAs have a flooding
> scope (type 9, 10 or 11), an 8-bit type and a 24-bit LS [Opaque] ID.
> All OSPFv3 LSAs have a flooding scope (the top 2 bits of the LS Type),
> a 14-bit type and a 32-bit LS ID.
>
> Given this, why is it better to allocate a single OSPFv3 type for
> this purpose?  Presumably, the real place that code reuse comes into
> play is in parsing the contents of the LSA, not the header; the OSPFv2
> and OSPFv3 headers are only subtly different but different enough that
> you're not going to use the same code to parse both of them anyway.
>
> Using the native OSPFv3 LSA format instead of a copied Opaque format
> gives you more bits in the type space and more bits in the LS ID.
> It also gives you the flexibility to standardize independently;
> you may want to standardize an OSPFv2 Opaque LSA before the implications
> of that type on OSPFv3 is fully understood.  With a shared space,
> and your suggestion of analyzing the OSPFv3 implications of any Opaque
> LSA, that wouldn't be allowed.  Finally, it also allows a proposal to
> utilize the OSPFv3 U bit, if the non-global behavior is desired.
>
> Perhaps I'm missing something, but it seems that saying "OSPFv2
> type-10 LSA opaque type #4, OSPFv3 type-0xa014, LSA contents ____" is
> not significantly different than saying "OSPFv2 type-10 LSA, OSPFv3
> type-(whatever 10 maps to) LSA, opaque type #4, LSA contents ____".
>
>   Bill
>
>


--
Acee