Re: OSPFv2 Opaque LSAs in OSPFv3

[Sina Mirtorabi <[e-mail]>]

Bill,

> Kireeti says:
> >there are a *small* number of
> >currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more.
> >If we analyse the applicability of those LSAs to OSPF v3, and mandate
> >that any future definition of an OSPFv2 Opaque LSA MUST have a similar
> >analysis, that seems to me to address the "backdoor" problem.
>
> Let's step back half a step and look at this solution -- documenting
> the v3 applicability of the existing Opaque LSAs and requiring
> documentation
> of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each
> OSPFv2 Opqaue LSA type.
>

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


> Boiling it down to the basics, OSPFv2 Opaque LSAs have a flooding
> scope (type 9, 10 or 11), an 8-bit type and a 24-bit LS [Opaque] ID.
> All OSPFv3 LSAs have a flooding scope (the top 2 bits of the LS Type),
> a 14-bit type and a 32-bit LS ID.

I believe it is better to have opaque LSA as it was introduced in v2 that
is, use LSID to break it down to Opaque type and instance, if you are
concerned about 'bit shortcoming' for those fields we could always add more
Functional code in LS type to handle this.
since flooding is now explicitly coded, we could allocate a range say 10-20
for opaque LSA
so if we are done with FC = 10 as it was introduced in Kireeti draft and
used all the bits for opaque type in LS ID  we will use FC = 11 etc

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

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

Sina





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