OSPF IGP Capabilities Draft
Acee Lindem <acee@REDBACK.COM> Fri, 31 January 2003 02:26 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 VAA16477 for <ospf-archive@LISTS.IETF.ORG>; Thu, 30 Jan 2003 21:26:01 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008C1246@cherry.ease.lsoft.com>; Thu, 30 Jan 2003 21:29:32 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 587958 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 Jan 2003 21:29:32 -0500
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 30 Jan 2003 21:29:32 -0500
Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 5B1233512EF for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 30 Jan 2003 18:29:31 -0800 (PST)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3E39DF3F.5080201@redback.com>
Date: Thu, 30 Jan 2003 21:28:15 -0500
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: OSPF IGP Capabilities Draft
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
As many of you recall, we've discussed this draft at both the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama but apparently there were some present who voiced reservations with the draft. In Atlanta, there wasn't a lot of discussion (other than strong support from the authors ;^). We agreed to discuss this draft further on the OSPF list. Are there still people who have reservations with the draft? http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt [Speaking as a WG member] I think the draft is a natural mechanism for advertising new OSPF capabilities now that the LSA option bits have been exhausted. We've already extended OSPF to support traffic engineering (TE) information and this mechanism is slated to be used for propagating an OSPF router's ability to act as an MPLS TE path computation server (PCS). Thanks, -- Acee
- OSPF IGP Capabilities Draft Acee Lindem
- Re: OSPF IGP Capabilities Draft Abhay Roy
- Re: OSPF IGP Capabilities Draft Acee Lindem
- Re: OSPF IGP Capabilities Draft Manral, Vishwas
- Re: OSPF IGP Capabilities Draft Acee Lindem
- Re: OSPF IGP Capabilities Draft Jean Philippe Vasseur
- unsubscribe Patricia macedo (NC)