Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 8 Oct 2002 06:22:36 -0400

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

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. I guess Spencer had tried a similar approach in the draft
http://www.watersprings.org/links/mlr/id/draft-giacalone-te-optical-next-02.
txt .

Thanks,
Vishwas

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 1:01 PM
To: [email-masked]
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

> If you take into account changes to the LS type for OSPFv3, the code
points
> are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2)
and it
> contains the flooding scope and a bit indicating what to do with
unrecognized
> types.

No kidding!

> There are no LS type collisions pervent use of the same function codes.

I beg to differ.

>                                 OSPFv2             OSPFv3
>    Link Scoped Opaque LSAs        0x09             0x0009
>
>    Area Scoped Opaque LSAs        0x0a             0x200a
>
>    AS   Scoped Opaque LSAs        0x0b             0x400b

Where did you read this?  I see in rfc 2740:

         LSA function code   LS Type   Description
         ----------------------------------------------------
         1                   0x2001    Router-LSA
         2                   0x2002    Network-LSA
         3                   0x2003    Inter-Area-Prefix-LSA
         4                   0x2004    Inter-Area-Router-LSA
         5                   0x4005    AS-External-LSA
         6                   0x2006    Group-membership-LSA
         7                   0x2007    Type-7-LSA
         8                   0x0008    Link-LSA
         9                   0x2009    Intra-Area-Prefix-LSA

which says that function code 9 represents Intra-Area Prefix LSAs;
it doesn't define a function code 10 or 11.

Since Function Codes are independent of flooding scope in v3, the
LS types 0009, 4009 and 6009 should be interpreted as link local,
AS-wide and ?? Intra-Area-Prefix LSAs, i.e., mostly nonsense.  The
same applies to 0001, 4001 and 6001, etc.

Using the value 0009 for Link Local Opaque LSAs (i.e., requiring that
the function code be interpreted *in the context of the flooding scope*)
negates the entire point of separating LS function and flooding scope.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 08:19:32 -0700

Hi Vishwas,

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

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

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.

Kireeti.