Re: OSPFv2 Opaque LSAs in OSPFv3

[Dennis Ferguson <[e-mail]>]

Sina,

> if you want to allocate a new LSA type for each opaque type ( or better say
> for each new LSA introduced ) then we won't need to call this opaque LSA,
> you basically want to go to the idea of 'introducing a new LSA type' for
> each 'new LSA defined' and we will end up with many, many LSA type which I
> am not sure is a clean way ...

Why is having "many, many LSA types" any less clean than having many, many
opaque LSA types?  What difference does it make whether you need to look at
the LSA type or the opaque LSA's internal type to determine if you recognize
it?  Note that if you don't recognize the LSA type OSPFv3 already forces you
to implement the procedures both to handle any number of unrecognized LSAs
and to flood them properly in any case, so why would you want to add yet
more code to the implementation to do the same thing a different way?  If
there's anything unclean about this it would be adding a second way to
provide functionality which already exists, and must be implemented,
in the protocol.

To be clear, I think the proper way to handle moving functionality from
OSPFv2 Opaque LSAs to OSPFv3 is to take the LSA-type+Opaque-type and map
it to an OSPFv3 LSA-type+flooding-scope.  I am still concerned that there
be a way to specify the contents of the OSPFv2 LSA-type+Opaque-type, or
an equivalent OSPFv3 LSA-type+flooding-scope, in a single document, but
adding Opaque LSAs themselves to OSPFv3 (as opposed to mapping the contents
of a particular OSPFv2 opaque LSA type to an OSPFv3 LSA type) is an orthogonal
issue which adds no new functionality to the protocol, but requires that
every write code to support a second way to do the same thing.  This doesn't
seem to make much sense.

If there was some advantage to Opaque LSAs over OSPFv3's generic LSA flooding
procedures I think the time to point this out was the 3 years between
1996, when OSPFv3's flooding procedures were first proposed, and 1999,
when the document became an RFC, so that the generic procedures could be
removed (like OSPFv2) and Opaque LSAs added instead.  No matter how it is
done there needs to be only one way to do it, and OSPFv3 already has a way.

> that way we honor the name opaque LSA ;-) and won't introduce a new LSA type
> every time we need to define a LSA

But you've still not pointed out what is wrong with introducing a new LSA
type every time you need one.  OSPFv3 makes everyone write code to handle
this, so what is wrong with making use of that code?

> also it is not because we define opaque in v3 the same way as in v2 ( that
> is, using LS ID for opaque type and instance ) that we have to sync
> completely between v2 and v3, ospfv3 could have its own opaque type to be
> defined / standardized independently ...

But OSPFv3 has already has its own opaque type.  It is an LSA type you don't
understand with a flooding scope that you do understand.  What's the use
of having another one?

Dennis Ferguson