Re: ospf te doc
"Manral, Vishwas" <VishwasM@NETPLANE.COM> Thu, 22 August 2002 10:04 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 GAA20293 for <ospf-archive@LISTS.IETF.ORG>; Thu, 22 Aug 2002 06:04:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006E5766@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 6:05:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86040 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 22 Aug 2002 06:05:59 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 22 Aug 2002 06:05:58 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <P9P4P8Z9>; Thu, 22 Aug 2002 06:05:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <E7E13AAF2F3ED41197C100508BD6A32879149A@india_exch.hyderabad.mindspeed.com>
Date: Thu, 22 Aug 2002 06:07:59 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Hi Kireeti, My views/answers on the questions you raised: - a) I would prefer the suggestion to require the "Reserved" field to be 0 for TE-LSA's and a value of non-zero should be treated as a non-TE LSA(unknown). (as in the case of Grace-LSA) If we left the meaning of the text as it is, it could create problems. Two LSA's with different "Reserved" values but same "Instance" would be treated as different LSA's by the OSPF process, however for the TE application because the "Instance" would be the same it would be the same instance although the contents could well be different. Besides, the number of "Instance" values are probably sufficient even for future requirements(every router can originate 65536 TE LSA's). By imposing the above condition I specified we could use different values of "Reserved" bits for future uses. Another less preferable option could be to have all 24 bits as "Instance". b) A non-zero value of reserved should be treated as a non-TE LSA. c) Unknown opaque LSA's are flooded(not dropped) further depending on the flooding scope of the LSA. Thanks, Vishwas -----Original Message----- From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET] Sent: Thursday, August 22, 2002 2:12 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: ospf te doc Hi All, Here's what the updated section 2.2 of the ospf te doc (draft-katz-yeung-ospf-traffic-07.txt) looks like: 2.2. LSA ID The LSA ID of an Opaque LSA is defined as having eight bits of type and 24 bits of type-specific data. The Traffic Engineering LSA uses type 1. The remaining 24 bits are broken up into eight bits of reserved space (which SHOULD be zero on transmission and ignored on receipt) and sixteen bits of instance: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Reserved | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 65536 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance. The issues are a) what should the wording regarding the "Reserved" field be? b) how should TE LSAs received with "illegal" values be treated? (for example in the wording as above, how should a TE LSA with a non-zero Reserved field be treated)? One suggestion is to require the "Reserved" field to be zero, much as John Moy requires the Opaque ID to be zero in a Grace LSA. A TE LSA received with a non-zero Reserved field is to be treated as an unknown Opaque LSA (how are unknown Opaque LSAs treated? Dropped? Flooded?). Thoughts? Other suggestions? Kireeti.
- ospf te doc Kireeti Kompella
- Re: ospf te doc Dovolsky, Dan
- Re: ospf te doc Kireeti Kompella
- Re: ospf te doc Acee Lindem
- Re: ospf te doc Alex Zinin
- Re: ospf te doc Manral, Vishwas
- Re: ospf te doc Dovolsky, Dan
- Re: ospf te doc Manral, Vishwas
- Re: ospf te doc Dovolsky, Dan
- Re: ospf te doc Manral, Vishwas
- Re: ospf te doc Kireeti Kompella
- Re: ospf te doc Gray, Eric