Re: Comments on draft-katz-yeung-traffic-08.txt
Acee Lindem <acee@REDBACK.COM> Tue, 22 October 2002 20:27 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 QAA03325 for <ospf-archive@LISTS.IETF.ORG>; Tue, 22 Oct 2002 16:27:31 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00788A7E@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 16:29:47 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328222 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 16:29:47 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 16:29:47 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 43E2D449A2C; Tue, 22 Oct 2002 13:29:45 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20021017131430.M37850-100000@kummer.juniper.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3DB5B4F6.9060409@redback.com>
Date: Tue, 22 Oct 2002 16:28:38 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
Comments: To: IETF CCAMP WG <ccamp@ops.ietf.org>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
Kireeti, Can we close on the remaining issues? 1. With respect to the Remote Interface IP Addres TLV, is there really any reason to include it with a value of 0.0.0.0 for a multi-access link? I can't see how there could be a compatibility issue since the rough count on the list revealed more implementations that omitted the TLV altogether. 2. With respect to more than two routers on a multi-access network, it seems there is considerable support for allowing this even though it is not fully specified. Could you add something along these lines to the second paragraph of the limitations section: "Operation over multiaccess links with more than two devices is not specifically prohibited. TE operation and the use of reservation state is a matter for further study". Thanks, Acee Kireeti Kompella wrote: > Hi Acee, > > On Thu, 17 Oct 2002, Acee Lindem wrote: > > >>Comments: >> >> - The LSA Header Diagram in section 2.3.1 does not reflect >> the fact that the instance has been extended to 24 bits. >> > > Thanks. Someone else also pointed this out. > > >> - Section 2.4.1 - Replace "but for obvious reasons this..." >> with "but this nomenclature is avoid here since the >> OSPF router ID is not necessarily a routable address." >> > > Any objections? If not, I will make this change. > > >> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >> multiaccess links? It seems the TLV should either be >> omitted or set to the single neighbor address (since >> section 1.2 limits traffic engineering to multiaccess >> networks with 2 devices). >> > > While this document doesn't work ideally for multipoint links with > more that 2 devices, it is used. Also, this has been implemented > and is running code, so changing the spec to omitting this TLV at > this point would cause more problems than it would solve. > > >>Suggestion: >> >> - Include "Implications on Graceful Restart" section >> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >> Explicitly state that the goal is to maintain >> existing traffic engineered paths while discouraging >> any new ones until reservation state is obtained. >> > > Instead, how about specifying explicitly in the ospf gmpls draft > that the text there applies to the base TE doc as well as the GMPLS > extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need > the graceful restart doc as a normative reference. Note that the > TE doc has been around for many years, with interoperable > implementations etc., while graceful restart for OSPF much more recent. > > BTW, can we start to progress the graceful restart (aka hitless > restart) document? There are interoperable implementations now, and > while this doc is not as mature as TE, it certainly seems ready .... > > Kireeti. > > -- Acee
- Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: Comments on draft-katz-yeung-traffic-08.txt Kireeti Kompella
- Re: Comments on draft-katz-yeung-traffic-08.txt Rohit Dube
- Re: Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: Comments on draft-katz-yeung-traffic-08.txt Don Goodspeed
- Re: Comments on draft-katz-yeung-traffic-08.txt Don Goodspeed
- Re: Comments on draft-katz-yeung-traffic-08.txt Tony Przygienda
- Re: Comments on draft-katz-yeung-traffic-08.txt Rohit Dube
- Re: Comments on draft-katz-yeung-traffic-08.txt Naidu, Venkata
- Re: Comments on draft-katz-yeung-traffic-08.txt Naiming Shen
- Re: Comments on draft-katz-yeung-traffic-08.txt Rohit Dube
- Re: Comments on draft-katz-yeung-traffic-08.txt Sina Mirtorabi
- Re: Comments on draft-katz-yeung-traffic-08.txt Rohit Dube
- Re: Comments on draft-katz-yeung-traffic-08.txt Sina Mirtorabi
- Re: Comments on draft-katz-yeung-traffic-08.txt Rohit Dube
- Re: Comments on draft-katz-yeung-traffic-08.txt Li, Ke Qin (Peter)
- Re: Comments on draft-katz-yeung-traffic-08.txt Sina Mirtorabi
- Re: Comments on draft-katz-yeung-traffic-08.txt Rohit Dube
- Re: Comments on draft-katz-yeung-traffic-08.txt Naidu, Venkata
- Re: Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: Comments on draft-katz-yeung-traffic-08.txt Kireeti Kompella
- Re: Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: Comments on draft-katz-yeung-traffic-08.txt Kireeti Kompella
- Re: Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: Comments on draft-katz-yeung-traffic-08.txt Don Goodspeed
- Re: Comments on draft-katz-yeung-traffic-08.txt Tom Petch
- Re: Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: Comments on draft-katz-yeung-traffic-08.txt Tom Petch
- Re: Comments on draft-katz-yeung-traffic-08.txt Acee Lindem
- Re: OSPFv3 Applications Support Rohit Dube
- Re: OSPFv3 Applications Support Quaizar Vohra
- Re: OSPFv3 Applications Support Acee Lindem
- Re: OSPFv3 Applications Support Erblichs
- Re: OSPFv3 Applications Support Kunihiro Ishiguro
- Re: OSPFv3 Applications Support Kireeti Kompella
- Re: OSPFv3 Applications Support Acee Lindem
- Re: I-D ACTION:draft-katz-yeung-ospf-traffic-10.t… Rohit Dube