Re: OSPFv2 Opaque LSAs in OSPFv3

[Sina Mirtorabi <[e-mail]>]

Dennis,


>
> 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?

not much, however I guess opaque LSA was introduced in order to not define a
new LSA type for each LSA needed therefore staying on the same logic for v3
looked to me natural ( but see more below )

> 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.

agree, however we could still define all the opaque type having the same
flooding scope on a given FC. therefore by setting the flooding scope bit of
this FC we won't need to add more code ...

>
> 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.


I think maping directly might not always work, imagine we have a opaque type
between 1-9 that could conflict with FC 1-9 that are already defined...
so we would probably have to define a new LSA type and could not simply use
/ or map ( at least direct mapping ) the opaque ID in v2 already defined (or
will be defined) to v3 given that those opaque could be used in v3 although
the content might be different


>
> 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.

I am not arguing about flooding scope definition in v3 versus v2 way of
flooding scope (through opaque)
just that having the same opaque ID as for v2 could accelerate defining same
functionality in v3 by using the same opaque ID number ( when applicable)


>
> > 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?
>

we could use the same opaque ID already defined in v2 which apply also to v3
for example PCSD LSA already define address type so if we have the opaque ID
we won't need to wait to allocate a new LSA type

as far as flooding scope and code, as I mentioned above we could define all
the opaque type that requires the same flooding scope in a given FC and use
that FC flooding bit to handle flooding correctly

Please note that I am Not saying to define flooding for each FC, each FC has
already 'flooding scope' bit but simply put those opaque ID that requires
the same flooding in a given FC and set the flooding bit of that FC


> > 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?

I understand both opaque type and flooding scope, honestly there is not much
technical advantage of one over the other
in one case opaque ID of v2 could be used in order to accelerate Opaque ID
definition in v3 in other case I guess a correct mapping could do the same
thing at the end it is a personal preference ....


Sina


>
> Dennis Ferguson
>


Outgoing messages scanned and certified safe by Stop-Sign, the Personal Alarm Service.
http://defender.veloz.com/dlp_ban/?n=tl&sp=08.out002