Re: OSPFv2 Opaque LSAs in OSPFv3

"Manral, Vishwas" <VishwasM@NETPLANE.COM> Tue, 08 October 2002 08:36 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03521 for <ospf-archive@LISTS.IETF.ORG>; Tue, 8 Oct 2002 04:36:01 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0075E564@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 4:38:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 259300 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 04:38:03 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 04:38:03 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3L3L>; Tue, 8 Oct 2002 04:38:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <E7E13AAF2F3ED41197C100508BD6A3287917AB@india_exch.hyderabad.mindspeed.com>
Date: Tue, 08 Oct 2002 04:40:13 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Acee,

I would prefer we do not reuse the function code 0x9.

I am wondering why we require three different function codes for OSPFv2
Opaque LSA's itself. Why can't we have one for OSPFv2 Opaque LSA's a value
of 0xa instead? The flooding scope of the OSPFv2 Opaque LSA contained in
such an LSA should be the same as the flooding scope of OSPFv3 LSA.

So LSA type would be
                                 OSPFv2            OSPFv3
   Link Scoped Opaque LSAs        0x09             0x000a

   Area Scoped Opaque LSAs        0x0a             0x200a

   AS   Scoped Opaque LSAs        0x0b             0x400a

Besides although setting the U-bit to 0, helps in flooding optimizations as
we will not be flooding opaque LSA's across non-joint TE parts within an
areas if there are some routers which do not understand this type of LSA. It
may break assumption of flooding of Opaque LSA's thru out the flooding scope
routers.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Tuesday, October 08, 2002 8:49 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3


Kireeti Kompella wrote:

> Hi Kunihiro,
>
>
>>BTW I haven't submitted the draft but I prepared TE extensions to
>>OSPFv3.  I just define a new LS type for TE then use OSPFv3 built in
>>flooding mechanism.  I believe this is straight forward way to do it.
>>
>
> The draft I submitted also uses the OSPFv3 built in flooding.  It is the
> only way to do it.
>
>
>> LSA function code  LS Type  Description
>> --------------------------------------------------------------------
>> 10                 0x2000a  Traffic-Engineering-LSA



Kunihiro,

Believe you mean 0x200a.



>>
>
> Do you plan to have a different Function Code for each OSPFv2 Opaque LSA
> Type?


Kiretti,

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. There are no LS type collisions pervent use of the same function
codes.


                                OSPFv2             OSPFv3
   Link Scoped Opaque LSAs        0x09             0x0009

  Area Scoped Opaque LSAs        0x0a             0x200a

   AS   Scoped Opaque LSAs        0x0b             0x400b

One could argue that the functions types for area and AS scoped opaque LSAs
should be 0xa00a and 0xc00b as well. This would indicate that a router that
does not recognize the type should store and flood it anyway. Any strong
feelings
on this?

Thanks,
Acee
>
> It seems to me to be much easier to have a single code point for all
> OSPFv2 Opaque LSAs.  This way, all defined OSPFv2 Opaque LSAs get
> automatically defined in v3; moreover, if a new Opaque LSA seems to be
> useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA.
>
> Kireeti.
--
Acee