Re: OSPFv2 Opaque LSAs in OSPFv3

["Manral, Vishwas" <[e-mail]>]

Hi Kireeti,

>> Though I agree the approach you suggest does minimize the amount of
effort
>> for the working group to get similar functionality in OSPFv3 as OSPFv2,
by
>> simply ignoring the OSPFv2 header(i.e. first 20 bytes of the payload).

> Not entirely accurate: the OSPFv2 header (if you mean the LSA header) is
> almost identical; the LS type field is the only thing that changes.
Ok. I thought you meant you were copying the entire OSPFv2 LSA and not just
the payload. So agree that the Opaque OSPFv2 for OSPFv3 LSA we would have
the same value of Opaque type etc too.

>> I prefer a cleaner approach from the protocol implementations point of
view.
>> Probably giving an LSA type to Area Scope TE LSA's and using the Link ID
as
>> instance id.

>If you were to add "and keep the LSA body identical between OSPFv2 TE
>LSA and the new OSPFv3 TE LSA", I'd be inclined to agree with you.

That is exactly what I meant earlier(however changed views, for simplicity
and work overload for the group). The use of TLV's themselves could be the
same as that of the v2 Opaque LSA's. I think that is what you mean in the
draft Section 2. ;-)

> However, having gone that far, why not import all OSPFv2 Opaque LSAs
> into v3 in one go?  For example, you get Grace LSAs for free; if
> tomorrow someone were to invent yet another OSPFv2 Opaque LSA, you get
> that for free too, should you desire it.
Agreed it would be far simpler.

> Apropos of nothing, it's amusing that the only instance of an OSPF v3
> LSA that really fully uses the separation of flooding scope and LS
> function code is the 'OSPFv2 Opaque LSA' -- all other function codes
> have pre-defined flooding scopes.

I agree. As the LSA function codes of the RFC2740 LSA's themselves tell the
flooding scope (i.e. LSA in any other flooding scope would not make sense).

Thanks,
Vishwas