Re: OSPFv2 Opaque LSAs in OSPFv3

[Tony Przygienda <[e-mail]>]

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.
>
Dennis,  I suspect it's connected to certain IAB's members' recent
hysteria as to 'opaque LSAs are a big security problem and de-facto
allow vendors to
do non-interoperable things under the cloak of IETF by using
non-documented opaques'.
Not much sense in it but that's what goes around ...

    -- tony