Re: OSPFv2 Opaque LSAs in OSPFv3

[Erblichs <[e-mail]>]

Dennis,

        Sorry, but I agree with your first statement.
        "Why is having "many, many LSA types" any less clean than having many,
many
        > opaque LSA types?"

        If I recieve a LSA, I only need to parse the LSA header before I need
to
        decide how I am going to handle it.

        If I have many LSA opaque subtypes, don't I need to do more
        initial parsing before I can decide what to do with it?

        Thus, I am not really a fan of having 45 or so opaque LSA subtypes
        in the possible future.

        Mitchell Erblich
        Sr. Software Engineer
        ===================================




Dennis Ferguson wrote:
>
> 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