Re: OSPFv2 Opaque LSAs in OSPFv3

[Bill Fenner <[e-mail]>]

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