From idr-bounces@ietf.org Thu Jun 01 03:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhN6-0001pY-2g; Thu, 01 Jun 2006 03:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhN5-0001ou-0k; Thu, 01 Jun 2006 03:13:31 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlhN3-0003AY-Fb; Thu, 01 Jun 2006 03:13:30 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k517DPC9007582; Thu, 1 Jun 2006 10:13:26 +0300 Date: Thu, 1 Jun 2006 10:13:25 +0300 (EEST) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1504/Wed May 31 22:59:14 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: idr@ietf.org Subject: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Tue, 30 May 2006, The IESG wrote: > The IESG has received a request from the Inter-Domain Routing WG to consider > the following document: > > - 'Graceful Restart Mechanism for BGP ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-13. The spec seemed reasonably clear, but seems to have a couple of open issues, as described below. Btw, it's interesting that AFAIK no vendor enables graceful restart by default. Some don't even enable graceful restart helper mode by default, but that's more difficult to find out because it seems very difficult to see whether this is enabled or not when GR is not enabled. I wonder if vendors see some issues in enabling graceful restart or GR helper mode that this document does not bring up. substantial ----------- 1) Is there an implementation report? I couldn't find any. In particular, I'd be interested about two things: - section 5 states: "In general the Restart Time SHOULD NOT be greater than the HOLDTIME carried in the OPEN." while default in two vendors I checked appeared to not honor this; Cisco has 120sec restart, 90 sec holdtime. Juniper has 300 sec restart, 60 sec holdtime. - Forwarding State bit seems interesting especially to for planned outage use, but I does any vendor allow it to be configured? I couldn't find any.. 2) The deployment and security considerations sections are not sufficiently clear on the hazards of graceful restart. For example, if the router crashes in a certain manner or shuts down due to power loss, the traffic is blackholed for up to Restart Time + following routing convergence (instead of just routing convergence). This threat can be mitigated e.g., by using control-plane independent liveness detection mechanisms (e.g., BFD on hardware -- probably no one implemented that yet) or just using graceful restart for planned maintenance (but forwarding state bit doesn't appear to be configurable so this isn't an option in practice). Also lowering restart time to something like 10 seconds (if you have multiple control processors) might help. It is also not clear how the issues above differ whether the BGP speaker has one or multiple control processors. I think many deployment require two but the assumptions about this aren't stated in the document. editorial --------- This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. ==> maybe s/proposes/describes/ ? 5.1. Procedures for the Restarting Speaker When the Restarting Speaker restarts, possible it SHOULD retain, if possible, the forwarding state for the BGP routes in the Loc-RIB, and SHALL mark them as stale. ==> "possible it SHOULD retain" doesn't parse, maybe ", possible" was leftover from editing and should be removed.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 01 07:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fllk2-0006zU-GI; Thu, 01 Jun 2006 07:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fllk0-0006gL-BO; Thu, 01 Jun 2006 07:53:28 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flljy-0000pe-Qc; Thu, 01 Jun 2006 07:53:28 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k51Bx4rB023518; Thu, 1 Jun 2006 07:59:22 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200606011159.k51Bx4rB023518@workhorse.brookfield.occnc.com> To: Pekka Savola Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) In-reply-to: Your message of "Thu, 01 Jun 2006 10:13:25 +0300." Date: Thu, 01 Jun 2006 07:59:04 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Pekka Savola writes: > > On Tue, 30 May 2006, The IESG wrote: > > The IESG has received a request from the Inter-Domain Routing WG to consider > > the following document: > > > > - 'Graceful Restart Mechanism for BGP ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-13. > > The spec seemed reasonably clear, but seems to have a couple of open > issues, as described below. > > Btw, it's interesting that AFAIK no vendor enables graceful restart by > default. Some don't even enable graceful restart helper mode by > default, but that's more difficult to find out because it seems very > difficult to see whether this is enabled or not when GR is not > enabled. I wonder if vendors see some issues in enabling graceful > restart or GR helper mode that this document does not bring up. At least one vendor prefers that their customers take advantage of redundant route processor support that makes it look to the external world as if no route processor failure occurrred. For most EBGP the actual protocol exchange is on the line card processor. For IBGP or EBGP multihop the "tepid" route processor takes over (not quite hot since recovery of some derived state occours on failover). At least two vendors have done this although one is no longer in business. The remaining vendor is not one of the big two but has some tier one and tier two customers. > substantial > ----------- > > 1) Is there an implementation report? I couldn't find any. > > In particular, I'd be interested about two things: > - section 5 states: "In general the Restart Time SHOULD NOT be greater > than the HOLDTIME carried in the OPEN." while default in two vendors > I checked appeared to not honor this; Cisco has 120sec restart, 90 sec > holdtime. Juniper has 300 sec restart, 60 sec holdtime. The practical reason for this is most route processors can't reload and get to a state where BGP can come up in less than their HOLDTIME. Bad things happen if the grace timer expires first. I think this reflects a worst case setting. > - Forwarding State bit seems interesting especially to for planned outage > use, but I does any vendor allow it to be configured? I couldn't find > any.. > > 2) The deployment and security considerations sections are not > sufficiently clear on the hazards of graceful restart. For example, > if the router crashes in a certain manner or shuts down due to power > loss, the traffic is blackholed for up to Restart Time + following > routing convergence (instead of just routing convergence). You need to also have IGP graceful restart running and the grace time for that is often shorter. The down side of a not-so-gracefull restart in which graceful restart is indicated is a recovery in the lesser of route processor reboot time or the grace period plus convergence. In practical terms this is almost always over a minute, sometimes a few minutes. > This threat can be mitigated e.g., by using control-plane independent > liveness detection mechanisms (e.g., BFD on hardware -- probably no > one implemented that yet) or just using graceful restart for planned > maintenance (but forwarding state bit doesn't appear to be > configurable so this isn't an option in practice). Also lowering > restart time to something like 10 seconds (if you have multiple > control processors) might help. Lets just leave it at "there are other ways to accomplish BGP failover". btw- Same vendor does BFD on line cards with line cards aware of route processor liveness or the state of a route processor failover. They don't need gracefull restart since the failover is completely transparent to the outside world but implement it (I think). > It is also not clear how the issues above differ whether the BGP > speaker has one or multiple control processors. I think many > deployment require two but the assumptions about this aren't stated in > the document. Depends on whether the extra control processors just sit there and require intervention to be put into service or act as cold spares or act as warm or hot spares. I think how redundant route processors are used is out of scope for the document though. A hibernating spare seems common (spare has read in config and that stuff and "has a heartbeat" but has acquired no adjacenies or routing information). Graceful restart seems appropriate for this sort of sparing and in that case you could configure the graceful restart timer to a much lower value than the default. > editorial > --------- > This document proposes a mechanism for BGP that would help minimize > the negative effects on routing caused by BGP restart. > > ==> maybe s/proposes/describes/ ? > > 5.1. Procedures for the Restarting Speaker > > When the Restarting Speaker restarts, possible it SHOULD retain, if > possible, the forwarding state for the BGP routes in the Loc-RIB, and > SHALL mark them as stale. > > ==> "possible it SHOULD retain" doesn't parse, maybe ", possible" was > leftover from editing and should be removed.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Your point about an implementation report is valid. I think you'll find most major vendors already implement this and support this enough to make the effort to provide an implementation report so we'll just have to wait for one. I don't know for sure how many providers deplyed this and whether some of those later decided to turn it off but I do know that providers have insisted that it be implemented. For now it is in use. Maybe in a few years redundant route processors will be more common but even then single route processor routers or ones without a warm or hot spare will still exist for a long time. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 01 09:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fln3g-0005XP-C7; Thu, 01 Jun 2006 09:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fln3e-0005RR-6B; Thu, 01 Jun 2006 09:17:50 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fln3b-0000Au-Q6; Thu, 01 Jun 2006 09:17:50 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k51DHiX19260; Thu, 1 Jun 2006 06:17:44 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k51DHd577281; Thu, 1 Jun 2006 06:17:39 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606011317.k51DHd577281@merlot.juniper.net> To: Pekka Savola Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) In-Reply-To: Your message of "Thu, 01 Jun 2006 10:13:25 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79415.1149167859.1@juniper.net> Date: Thu, 01 Jun 2006 06:17:39 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Pekka, > On Tue, 30 May 2006, The IESG wrote: > > The IESG has received a request from the Inter-Domain Routing WG to conside r > > the following document: > > > > - 'Graceful Restart Mechanism for BGP ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-13. > > The spec seemed reasonably clear, but seems to have a couple of open > issues, as described below. > > Btw, it's interesting that AFAIK no vendor enables graceful restart by > default. Some don't even enable graceful restart helper mode by > default, but that's more difficult to find out because it seems very > difficult to see whether this is enabled or not when GR is not > enabled. I wonder if vendors see some issues in enabling graceful > restart or GR helper mode that this document does not bring up. > > substantial > ----------- > > 1) Is there an implementation report? I couldn't find any. > > In particular, I'd be interested about two things: > - section 5 states: "In general the Restart Time SHOULD NOT be greater > than the HOLDTIME carried in the OPEN." while default in two vendors > I checked appeared to not honor this; Cisco has 120sec restart, 90 sec > holdtime. Juniper has 300 sec restart, 60 sec holdtime. > > - Forwarding State bit seems interesting especially to for planned outage > use, but I does any vendor allow it to be configured? I couldn't find > any.. Here is the URL for the implementation report: http://tools.ietf.org/wg/idr/draft-ietf-idr-bgp-gr-survey/draft-ietf-idr-bgp-gr-survey-01.txt Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 01 10:44:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloPS-0004QC-18; Thu, 01 Jun 2006 10:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloPQ-0004Q2-H6; Thu, 01 Jun 2006 10:44:24 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FloPN-0001ZP-AQ; Thu, 01 Jun 2006 10:44:24 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 172698678; Thu, 1 Jun 2006 10:44:21 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k51EiL6g023989; Thu, 1 Jun 2006 07:44:21 -0700 From: Bill Fenner Message-Id: <200606011444.k51EiL6g023989@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Pekka Savola Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) Date: Thu, 1 Jun 2006 07:44:20 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > 1) Is there an implementation report? I couldn't find any. Thanks to Yakov for posting the pointer. My apologies for jumping the gun a tad - I sent the draft that Yakov points to to the Secretariat for posting on the implementation report page at the same time as requesting the Last Call, but the Last Call process is mostly automated and posting implementation reports isn't. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 01 11:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpCW-0006Z6-5k; Thu, 01 Jun 2006 11:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpCU-0006YZ-Sg; Thu, 01 Jun 2006 11:35:06 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpCU-0007Xw-9y; Thu, 01 Jun 2006 11:35:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k51FYjiO022736; Thu, 1 Jun 2006 18:34:50 +0300 Date: Thu, 1 Jun 2006 18:34:45 +0300 (EEST) From: Pekka Savola To: curtis@faster-light.net Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) In-Reply-To: <200606011159.k51Bx4rB023518@workhorse.brookfield.occnc.com> Message-ID: References: <200606011159.k51Bx4rB023518@workhorse.brookfield.occnc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1504/Wed May 31 22:59:14 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_05,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, I'll follow-up to Curtis inline, but first I'd like to make the comment about the implementation report: http://tools.ietf.org/wg/idr/draft-ietf-idr-bgp-gr-survey/draft-ietf-idr-bgp-gr-survey-01.txt It's 4 years old, though fortunately (or unfortunately) the spec hasn't really changed that much since. The main differences seem to be: - now using uppercase language - restarting router procedures now SHOULD retain forwarding state (instead of shall) - BGP FSM update inclusion - Selection_Deferral_Timer specification spelled out I'd have liked greater detail in the implementation report, given that at least two vendors state compliance but do not note that (or why) they do not conform to a SHOULD NOT. While this specific issue probably does not hinder interoperability, it raises a question about the credibility of the spec. On Thu, 1 Jun 2006, Curtis Villamizar wrote: >> 1) Is there an implementation report? I couldn't find any. >> >> In particular, I'd be interested about two things: >> - section 5 states: "In general the Restart Time SHOULD NOT be greater >> than the HOLDTIME carried in the OPEN." while default in two vendors >> I checked appeared to not honor this; Cisco has 120sec restart, 90 sec >> holdtime. Juniper has 300 sec restart, 60 sec holdtime. > > The practical reason for this is most route processors can't reload > and get to a state where BGP can come up in less than their HOLDTIME. > Bad things happen if the grace timer expires first. I think this > reflects a worst case setting. Correct, but this gets back to the point below -- "how applicable is this with just a single control processor?" These seem to be two very distinct scenarios with very different requirements and applicability. >> - Forwarding State bit seems interesting especially to for planned outage >> use, but I does any vendor allow it to be configured? I couldn't find >> any.. >> >> 2) The deployment and security considerations sections are not >> sufficiently clear on the hazards of graceful restart. For example, >> if the router crashes in a certain manner or shuts down due to power >> loss, the traffic is blackholed for up to Restart Time + following >> routing convergence (instead of just routing convergence). > > You need to also have IGP graceful restart running and the grace time > for that is often shorter. That does not apply to all the sessions though. (Funnily enough, a major vendor has minimum GR restart-time for BGP 1 second, but for IS-IS 30 seconds..) > The down side of a not-so-gracefull restart in which graceful restart > is indicated is a recovery in the lesser of route processor reboot > time or the grace period plus convergence. In practical terms this is > almost always over a minute, sometimes a few minutes. You seem to make some assumptions here. For most non-stub routers, there's always a backup path, and reconvergence doesn't need to take more than a second or two (we've certainly measured very short BGP reconvergence inside our network). For stub edge routers which only connect single-homed users and are not used to transit traffic to/from any other router, always doing graceful restart may be better than non-GR. >> It is also not clear how the issues above differ whether the BGP >> speaker has one or multiple control processors. I think many >> deployment require two but the assumptions about this aren't stated in >> the document. > > Depends on whether the extra control processors just sit there and > require intervention to be put into service or act as cold spares or > act as warm or hot spares. I think how redundant route processors are > used is out of scope for the document though. A hibernating spare > seems common (spare has read in config and that stuff and "has a > heartbeat" but has acquired no adjacenies or routing information). > Graceful restart seems appropriate for this sort of sparing and in > that case you could configure the graceful restart timer to a much > lower value than the default. I personally believe that IETF documents should be useful to non-vendors as well.. and more than just bare bones spec required for interoperability would be useful to have. Given that we already have a section 'Deployment Considerations', it could easily be expanded to include useful information. Likewise, security considerations would (perhaps in addition to above) need to better discuss the hazards of delayed convergence, i.e., routing packets into a black hole instead of rerouting around the problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 01 13:15:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqkn-0005BP-DV; Thu, 01 Jun 2006 13:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqkm-0005BH-Gj; Thu, 01 Jun 2006 13:14:36 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flqkl-0002QE-6h; Thu, 01 Jun 2006 13:14:36 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k51HKOS5029074; Thu, 1 Jun 2006 13:20:24 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200606011720.k51HKOS5029074@workhorse.brookfield.occnc.com> To: Pekka Savola Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) In-reply-to: Your message of "Thu, 01 Jun 2006 18:34:45 +0300." Date: Thu, 01 Jun 2006 13:20:24 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: idr@ietf.org, curtis@faster-light.net, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Pekka Savola writes: > > I personally believe that IETF documents should be useful to > non-vendors as well.. and more than just bare bones spec required for > interoperability would be useful to have. Given that we already have a > section 'Deployment Considerations', it could easily be expanded to > include useful information. Likewise, security considerations would > (perhaps in addition to above) need to better discuss the hazards of > delayed convergence, i.e., routing packets into a black hole instead > of rerouting around the problem. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Pekka, Sorry to trim so much. The things I pointed out were mostly regarding an alternative to graceful restart and some of the implication of the various ways of supporting a spare route processor (one or more). That sort of thing does seem beyond the scope of the document. I do support this document and I don't feel that it needs to be a review paper on the convergence properties of the various approaches to handling route processor failure or planned maintenance. At most it should briefly describe how it is intended to improve this situation, which is does in Section 5 "Operation". Section 7 "Deployment Considerations" points out the transient blackhole or loop problem if things change. It is safe to assume that the reader knows that blackholes and route loops are bad and knows in detail what the consequences are. I don't see that omiting an embedded review paper makes this useful only to vendors unless you consider protocol specification in general to be of no use to providers or researchers or anyone but vendors. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 02 11:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBIo-0008N1-0i; Fri, 02 Jun 2006 11:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBIm-0008Hu-O5; Fri, 02 Jun 2006 11:11:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBIl-0006iv-Bz; Fri, 02 Jun 2006 11:11:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2006 08:11:02 -0700 X-IronPort-AV: i="4.05,204,1146466800"; d="scan'208"; a="287813987:sNHT56245746" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k52FB2fd013052; Fri, 2 Jun 2006 08:11:02 -0700 Received: from [10.0.1.2] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id k52FB0It018756; Fri, 2 Jun 2006 11:11:01 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 Jun 2006 11:10:57 -0400 To: Pekka Savola From: "John G. Scudder" Subject: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=3766; t=1149261062; x=1150125062; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:[Idr]=20Re=3A=20Last=20Call=3A=20'Graceful=20Restart=20Mechanism=20for=2 0BGP'=20to=20=0A=20Proposed=20Standard=20(draft-ietf-idr-restart); X=v=3Dcisco.com=3B=20h=3DMijOgVt+AiI9l/kq3mmLIGcD0hw=3D; b=TIPBPcqLER/EXEW6NZXSU/tRXW63e/EeUZGvvpKnggjl30iDJrb2RpcmmxU/ikvNkY9RZcJz hVDX2nKNhxPM7ez7KhbSw3HkJxge7c/+ORYyH3rd2Yum+8LLRnhuWLfn; Authentication-Results: sj-dkim-4.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Pekka, Thanks for your comments. I've addressed the substantive ones below. (No quibbles with the editorial.) At 10:13 AM +0300 6/1/06, Pekka Savola wrote: >In particular, I'd be interested about two things: > - section 5 states: "In general the Restart Time SHOULD NOT be greater > than the HOLDTIME carried in the OPEN." while default in two vendors > I checked appeared to not honor this; Cisco has 120sec restart, 90 sec > holdtime. Juniper has 300 sec restart, 60 sec holdtime. I think this demonstrates that we erred in using the SHOULD NOT language, and should weaken it to make it a suggestion, rather than using the SCARY ALL CAPS standards words. There's no interoperability issue in doing so. (BTW I believe you have the cisco numbers wrong, should be 120/180 which is in fact compliant with the spec as written.) > - Forwarding State bit seems interesting especially to for planned outage > use, but I does any vendor allow it to be configured? I couldn't find > any.. I'm not aware of any though there could be. I agree with your comment about planned outage use, and so does the spec -- such an implementation choice is specifically discussed in the last paragraph of section 5.1. >2) The deployment and security considerations sections are not >sufficiently clear on the hazards of graceful restart. For example, >if the router crashes in a certain manner or shuts down due to power >loss, the traffic is blackholed for up to Restart Time + following >routing convergence (instead of just routing convergence). The deployment considerations section does mention the possibility of black holes and loops, though it doesn't specifically mention the power failure scenario. Granted we don't present the algebra or all the possible failure cases, but I like to think that our audience is bright enough to do that. I tend to prefer drafts and RFCs that assume I can think for myself and don't waste my time making me read through stuff that's self-evident. That said, if there's significant support for expanding the deployment section, I don't see any real reason not to. In any case we can explicitly mention the loss-of-FIB (e.g., power loss) scenario. You also mention the security considerations section above but I don't see the connection? (Your later comment to Curtis, "Likewise, security considerations would (perhaps in addition to above) need to better discuss the hazards of delayed convergence, i.e., routing packets into a black hole instead of rerouting around the problem" doesn't help me understand why you think black holing is a security rather than a deployment consideration.) >This threat can be mitigated e.g., by using control-plane >independent liveness detection mechanisms (e.g., BFD on hardware -- >probably no one implemented that yet) Yes, and as I'm sure you're aware this was one of the principal motivations behind BFD. At least some implementations I'm aware of can do this. It does seem worthwhile to me that we mention this in the spec. >or just using graceful restart for planned maintenance (but >forwarding state bit doesn't appear to be configurable so this isn't >an option in practice). Also lowering restart time to something >like 10 seconds (if you have multiple control processors) might help. > >It is also not clear how the issues above differ whether the BGP >speaker has one or multiple control processors. I think many >deployment require two but the assumptions about this aren't stated >in the document. Indeed, this is an implementation detail. As such I think it's correct for the document to be silent on this point. Regards, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Jun 03 04:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmRTK-0007gk-Qw; Sat, 03 Jun 2006 04:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmRTI-0007b4-HV; Sat, 03 Jun 2006 04:27:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmRTI-0004NX-FD; Sat, 03 Jun 2006 04:27:00 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmRPS-00022I-IG; Sat, 03 Jun 2006 04:23:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k538MsYq025605; Sat, 3 Jun 2006 11:22:54 +0300 Date: Sat, 3 Jun 2006 11:22:54 +0300 (EEST) From: Pekka Savola To: "John G. Scudder" Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.4 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, 2 Jun 2006, John G. Scudder wrote: > At 10:13 AM +0300 6/1/06, Pekka Savola wrote: >> In particular, I'd be interested about two things: >> - section 5 states: "In general the Restart Time SHOULD NOT be greater >> than the HOLDTIME carried in the OPEN." while default in two vendors >> I checked appeared to not honor this; Cisco has 120sec restart, 90 sec >> holdtime. Juniper has 300 sec restart, 60 sec holdtime. > > I think this demonstrates that we erred in using the SHOULD NOT language, and > should weaken it to make it a suggestion, rather than using the SCARY ALL > CAPS standards words. There's no interoperability issue in doing so. Agreed, though picking the right restart time is still very important if you want the protocol to work well without negative impact in worst case scenarios. >> 2) The deployment and security considerations sections are not sufficiently >> clear on the hazards of graceful restart. For example, if the router >> crashes in a certain manner or shuts down due to power loss, the traffic is >> blackholed for up to Restart Time + following routing convergence (instead >> of just routing convergence). > > The deployment considerations section does mention the possibility of black > holes and loops, though it doesn't specifically mention the power failure > scenario. The current text is in the context of changes in routing _after_ GR has been started. A loop/blackhole as a result of initiating GR, and a loop that occurs because a routing update was missed due to ongoing GR are two very different things. The document is silent about the former. > Granted we don't present the algebra or all the possible failure > cases, but I like to think that our audience is bright enough to do > that. I tend to prefer drafts and RFCs that assume I can think for > myself and don't waste my time making me read through stuff that's > self-evident. Degradation of the "BGP service model" is AFAICS one of the biggest reasons why graceful restart hasn't been used that much, and folks are pretty uncertain about turning it on. If we want folks to endorse using our protocols, more text would not hurt. If we don't care, I can see that publishing bare bones specs could be deemed sufficient. > You also mention the security considerations section above but I don't see > the connection? (Your later comment to Curtis, "Likewise, security > considerations would (perhaps in addition to above) need to better discuss > the hazards of delayed convergence, i.e., routing packets into a black hole > instead of rerouting around the problem" doesn't help me understand why you > think black holing is a security rather than a deployment consideration.) The existing routing (and BGP) "service model" is that it reroutes around failures in the network if another path is available. By introducing graceful-restart, you change BGP and this service model so that in certain common scenarios, packets get blackholed or looped up to restart-time instead instead of always rerouting around the problem. This has an impact on availability of the network. Availability is one important aspect of security. >> or just using graceful restart for planned maintenance (but forwarding >> state bit doesn't appear to be configurable so this isn't an option in >> practice). Also lowering restart time to something like 10 seconds (if you >> have multiple control processors) might help. >> >> It is also not clear how the issues above differ whether the BGP speaker >> has one or multiple control processors. I think many deployment require >> two but the assumptions about this aren't stated in the document. > > Indeed, this is an implementation detail. As such I think it's correct for > the document to be silent on this point. Maybe. It is not required for interoperability, but it would be useful if we wanted the protocol to be useful. For instance, the recommendation for the restart-time could be very different (e.g., 5 or 10 seconds instead of, say, 300) depending on whether multiple control processors are available or not. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Jun 03 06:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmTh2-00046K-M9; Sat, 03 Jun 2006 06:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmTh0-000463-PN; Sat, 03 Jun 2006 06:49:18 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmTgy-0002L3-67; Sat, 03 Jun 2006 06:49:18 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k53AtKhp015220; Sat, 3 Jun 2006 06:55:20 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200606031055.k53AtKhp015220@workhorse.brookfield.occnc.com> To: Pekka Savola Subject: Re: [Idr] Re: Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart) In-reply-to: Your message of "Sat, 03 Jun 2006 11:22:54 +0300." Date: Sat, 03 Jun 2006 06:55:20 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Pekka Savola writes: > > On Fri, 2 Jun 2006, John G. Scudder wrote: > > At 10:13 AM +0300 6/1/06, Pekka Savola wrote: > >> In particular, I'd be interested about two things: > >> - section 5 states: "In general the Restart Time SHOULD NOT be greater > >> than the HOLDTIME carried in the OPEN." while default in two vendors > >> I checked appeared to not honor this; Cisco has 120sec restart, 90 sec > >> holdtime. Juniper has 300 sec restart, 60 sec holdtime. > > > > I think this demonstrates that we erred in using the SHOULD NOT language, and > > should weaken it to make it a suggestion, rather than using the SCARY ALL > > CAPS standards words. There's no interoperability issue in doing so. > > Agreed, though picking the right restart time is still very important > if you want the protocol to work well without negative impact in worst > case scenarios. > > >> 2) The deployment and security considerations sections are not sufficiently > >> clear on the hazards of graceful restart. For example, if the router > >> crashes in a certain manner or shuts down due to power loss, the traffic is > >> blackholed for up to Restart Time + following routing convergence (instead > >> of just routing convergence). > > > > The deployment considerations section does mention the possibility of black > > holes and loops, though it doesn't specifically mention the power failure > > scenario. > > The current text is in the context of changes in routing _after_ GR > has been started. A loop/blackhole as a result of initiating GR, and > a loop that occurs because a routing update was missed due to ongoing > GR are two very different things. The document is silent about the > former. If "about the former" means initiating GR to a router that died then thats where BFD comes in. BFD in now often implemented in the line cards with a liveness check on the route processor such that the line cards can quickly tell if the route processor is in its reload or failover process and proceeding normally or has tripped up in this process. If the RP is going to need a full reload rather than a fast failover or where failover is not supported, if the RP is dead rather than reloading normally, the line card can indicate BFD deadness by not responding and shortcut the GR time. This is all implementation detail and none of it belongs in the GR protocol spec. > > Granted we don't present the algebra or all the possible failure > > cases, but I like to think that our audience is bright enough to do > > that. I tend to prefer drafts and RFCs that assume I can think for > > myself and don't waste my time making me read through stuff that's > > self-evident. > > Degradation of the "BGP service model" is AFAICS one of the biggest > reasons why graceful restart hasn't been used that much, and folks are > pretty uncertain about turning it on. > > If we want folks to endorse using our protocols, more text would not > hurt. If we don't care, I can see that publishing bare bones specs > could be deemed sufficient. Protocol specs are suppose to define the protocol and provide major security and deployment considerations, and not provide excessive text simply advocating their use. > > You also mention the security considerations section above but I don't see > > the connection? (Your later comment to Curtis, "Likewise, security > > considerations would (perhaps in addition to above) need to better discuss > > the hazards of delayed convergence, i.e., routing packets into a black hole > > instead of rerouting around the problem" doesn't help me understand why you > > think black holing is a security rather than a deployment consideration.) > > The existing routing (and BGP) "service model" is that it reroutes > around failures in the network if another path is available. > > By introducing graceful-restart, you change BGP and this service model > so that in certain common scenarios, packets get blackholed or looped > up to restart-time instead instead of always rerouting around the > problem. > > This has an impact on availability of the network. Availability is > one important aspect of security. If it exposed a denial of service attack it would be a security issue. If it just has the potential to lengthen a failure or worsen a failure (causing a black hole) then it is a deployment consideration. AFAIK providers are using this (or similar approaches) to provide gracefull software upgrade which for some routers occurs more often than RP failures (ie: a software upgrade might occur once or twice a year while RP failures might be many years but even more likely might not occur for the life of the router). (... as opposed to the pre-ECC memory days when RPs would die much more often on "high sun spot days" - not likely to be related but everything seems to get blamed on sun spots in a joking manner - might also been related more to memory timing or noise on the boards than to lack of ECC but that's another story). :-) > >> or just using graceful restart for planned maintenance (but forwarding > >> state bit doesn't appear to be configurable so this isn't an option in > >> practice). Also lowering restart time to something like 10 seconds (if you > >> have multiple control processors) might help. > >> > >> It is also not clear how the issues above differ whether the BGP speaker > >> has one or multiple control processors. I think many deployment require > >> two but the assumptions about this aren't stated in the document. > > > > Indeed, this is an implementation detail. As such I think it's correct for > > the document to be silent on this point. > > Maybe. It is not required for interoperability, but it would be > useful if we wanted the protocol to be useful. > > For instance, the recommendation for the restart-time could be very > different (e.g., 5 or 10 seconds instead of, say, 300) depending on > whether multiple control processors are available or not. How about adding "The use of redundant control processors is outside of the scope of this document except to mention that the Selection_Deferral_Timer timer can be set to a much lower value in implementations which support this feature and make use of BGP Graceful Restart"? This could be tacked onto the deployment considerations section. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 07 15:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42U-00025l-Vp; Wed, 07 Jun 2006 15:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo42U-00025N-7h; Wed, 07 Jun 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo42T-0007Xi-TA; Wed, 07 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k57Jo1WR007955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fo42T-0002ih-Iu; Wed, 07 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as-pathlimit-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : The AS_PATHLIMIT Path Attribute Author(s) : T. Li, et al. Filename : draft-ietf-idr-as-pathlimit-02.txt Pages : 15 Date : 2006-6-7 This document describes the 'AS path limit' (AS_PATHLIMIT) path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP graph are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as-pathlimit-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as-pathlimit-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-7113107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as-pathlimit-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as-pathlimit-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-7113107.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Wed Jun 07 16:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4ON-0002vU-JF; Wed, 07 Jun 2006 16:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo48w-000581-ET for idr@ietf.org; Wed, 07 Jun 2006 15:56:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo48t-0001k0-OH for idr@ietf.org; Wed, 07 Jun 2006 15:56:41 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2006 12:55:40 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="asc'?txt'208?scan'208,208"; a="430130205:sNHT46811400" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k57JtdTU016287; Wed, 7 Jun 2006 12:55:39 -0700 Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k57JtccL002435; Wed, 7 Jun 2006 12:55:38 -0700 (PDT) Message-ID: <44872F3A.2000702@cisco.com> Date: Wed, 07 Jun 2006 12:55:38 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: multipart/mixed; boundary="------------020209020403030909040204" DKIM-Signature: a=rsa-sha1; q=dns; l=3181; t=1149710139; x=1150574139; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:[Fwd=3A=20I-D=20ACTION=3Adraft-chen-bgp-orf-survey-00.txt]; X=v=3Dcisco.com=3B=20h=3DpAe5uGksE6rda+JegGaCMlG1GWQ=3D; b=LPZsOYx3WN2IW5V2LUc8qujq6e3TdMe1NkGJHhgyjxKDjXFV2FDqoCCJNWWDZiVS2hsgeQhh DzvDqFTMUn59lpKUJs2Koq7RxGQYwlg5r5rcuGUmnXydrkdkUbjzyLet; Authentication-Results: sj-dkim-6.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Idr] [Fwd: I-D ACTION:draft-chen-bgp-orf-survey-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --------------020209020403030909040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. -- Enke -------- Original Message -------- Subject: I-D ACTION:draft-chen-bgp-orf-survey-00.txt Date: Wed, 07 Jun 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementation Survey for BGP ORF and Prefix-ORF Author(s) : E. Chen Filename : draft-chen-bgp-orf-survey-00.txt Pages : 7 Date : 2006-6-7 This document provides an implementation report for these two documents: "Cooperative Route Filtering Capability for BGP-4" and "Address Prefix Based Outbound Route Filter for BGP-4". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-orf-survey-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chen-bgp-orf-survey-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-chen-bgp-orf-survey-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020209020403030909040204 Content-Type: Message/External-body; name="draft-chen-bgp-orf-survey-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chen-bgp-orf-survey-00.txt" Content-Type: text/plain Content-ID: <2006-6-7114007.I-D@ietf.org> --------------020209020403030909040204 Content-Type: text/plain; name="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.asc" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------020209020403030909040204 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --------------020209020403030909040204-- From idr-bounces@ietf.org Mon Jun 12 15:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprnp-0000fh-TZ; Mon, 12 Jun 2006 15:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprnm-0000fW-0N; Mon, 12 Jun 2006 15:10:18 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprnk-0000Sq-Lp; Mon, 12 Jun 2006 15:10:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5CJAGWR031215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jun 2006 19:10:16 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fprnk-0007pK-8d; Mon, 12 Jun 2006 15:10:16 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 12 Jun 2006 15:10:16 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: idr chair , idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'Multiprotocol Extensions for BGP-4' to Draft Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'Multiprotocol Extensions for BGP-4 ' as a Draft Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-10.txt Technical Summary This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. In the move to Draft Standard, the support for SAFI 3 (unicast+ multicast for congruent topologies) was removed due to lack of implementation support. The value remains reserved in case this feature is implemented. In addition, the support for SNPA was removed, also due to lack of implementation support. The "Number of SNPAs" field was changed to reserved and MUST be set to zero. Working Group Summary The working group had consensus to move this document to Draft Standard. Protocol Quality Bill Fenner reviewed this spec for the IESG. There are several implementations, as described in the accompanying implementation report, which can be found at http://www.ietf.org/IESG/Implementations/mp-bgp-implementation-report.txt Note to RFC Editor This document obsoletes RFC 2858. Please make the following changes: In the Abstract, remove the first sentence and add another example to the list; OLD: Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that NEW: This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that OLD: To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI this document uses a combination of Address Family, as defined in [RFC1700], and Subsequent Address Family (as described in this document). NEW: To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI this document uses a combination of Address Family, as defined in [IANA-AF], and Subsequent Address Family (as described in this document). This paragraph appears twice, please change both: OLD: Presently defined values for the Address Family Identifier field are specified in RFC1700 (see the Address Family Numbers section). NEW: Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry [IANA-AF]. In section 8: OLD: Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender and ignored by the receiver. NEW: Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender and ignored by the receiver. Note that not setting the field value to 0 may create issues for a receiver not ignoring the field. In addition this definition is problematic if it is ever attempted to redefine the field. In the IANA considerations section: OLD: - SAFI values 128 through 240 are part of the previous "private use" range. Of this space, allocations which are currently in use are to be recognized by IANA. Unused values, namely 130, 131, 135 through 139, and 141 through 240 should be considered reserved, in order to avoid conflicts. NEW: - SAFI values 128 through 240 are part of the previous "private use" range. At the time of approval of this document, a list of allocations which are currently in use will be provided to IANA by the Routing Area Director. Unused values, namely 130, 131, 135 through 139, and 141 through 240 should be considered reserved, in order to avoid conflicts. References: OLD: [BGP-CAP] "Capabilities Advertisement with BGP-4", R. Chandra, J. Scudder, RFC2842, May 2000 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1700] "Assigned Numbers", J. Reynolds, J. Postel, RFC1700, October 1994 (see also http://www.iana.org/iana/assignments.html) NEW: [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [IANA-AF] "Address Family Numbers", reachable from http://www.iana.org/numbers.html Authors' Addresses: [change juniper.com to juniper.net] OLD: Dave Katz Juniper Networks, Inc. email: dkatz@juniper.com Yakov Rekhter Juniper Networks, Inc. email: yakov@juniper.com NEW: Dave Katz Juniper Networks, Inc. email: dkatz@juniper.net Yakov Rekhter Juniper Networks, Inc. email: yakov@juniper.net _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 12 15:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsPw-00071k-94; Mon, 12 Jun 2006 15:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsPv-00071f-H5 for idr@ietf.org; Mon, 12 Jun 2006 15:49:43 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsPu-0005pg-Be for idr@ietf.org; Mon, 12 Jun 2006 15:49:43 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 13AFF147C8C for ; Mon, 12 Jun 2006 15:49:40 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k5CJndBX011412; Mon, 12 Jun 2006 12:49:40 -0700 From: Bill Fenner Message-Id: <200606121949.k5CJndBX011412@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idr mailing list Subject: Re: [Idr] Protocol Action: 'Multiprotocol Extensions for BGP-4' to Draft Standard Date: Mon, 12 Jun 2006 12:49:39 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Congratulations to Tony, Ravi, Dave and Yakov, and thanks for the hard work involved. Thanks also to Sue for coordinating the implementation report. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 12 15:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsR6-0000xL-SO; Mon, 12 Jun 2006 15:50:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsQK-0007Fs-HF; Mon, 12 Jun 2006 15:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsQK-0005tK-Eg; Mon, 12 Jun 2006 15:50:08 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpsQE-0005FT-F9; Mon, 12 Jun 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5CJo2WR001057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FpsQE-0006hk-1C; Mon, 12 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, et al. Filename : draft-ietf-idr-restart-12.txt Pages : 11 Date : 2006-6-12 This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-12113738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-12113738.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Mon Jun 12 17:23:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptsJ-0007Sd-U9; Mon, 12 Jun 2006 17:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptsI-0007ST-IY for idr@ietf.org; Mon, 12 Jun 2006 17:23:06 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptsH-0000Mb-5V for idr@ietf.org; Mon, 12 Jun 2006 17:23:06 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5CLN2X43654 for ; Mon, 12 Jun 2006 14:23:04 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5CLMv500668 for ; Mon, 12 Jun 2006 14:22:57 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606122122.k5CLMv500668@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60328.1150147377.1@juniper.net> Date: Mon, 12 Jun 2006 14:22:57 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Idr] draft-ietf-idr-restart-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, The revised draft (see attached) reflects the comments we received during the Last Call. Yakov. ------- Forwarded Message Date: Mon, 12 Jun 2006 15:50:02 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-12.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, et al. Filename : draft-ietf-idr-restart-12.txt Pages : 11 Date : 2006-6-12 This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the mess age. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-12113738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-12.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-12113738.I-D@ietf.org> - --OtherAccess-- - --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr - --NextPart-- ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 14 15:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNV-0005A9-PD; Wed, 14 Jun 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNK-00055A-FB; Wed, 14 Jun 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqbNK-00014x-0j; Wed, 14 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1Hp001512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006rV-Ej; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-14.txt Pages : 0 Date : 2006-6-14 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-filter-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-filter-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-14110438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14110438.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Wed Jun 14 16:25:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqbvp-0005KH-Lx; Wed, 14 Jun 2006 16:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqbvo-0005KC-Qj for idr@ietf.org; Wed, 14 Jun 2006 16:25:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqbvn-0005w5-IV for idr@ietf.org; Wed, 14 Jun 2006 16:25:40 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 13:25:39 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208"; a="1825729670:sNHT37088698" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5EKPc2v012439; Wed, 14 Jun 2006 13:25:38 -0700 Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5EKPcIs018220; Wed, 14 Jun 2006 13:25:38 -0700 (PDT) Message-ID: <449070C2.6000805@cisco.com> Date: Wed, 14 Jun 2006 13:25:38 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter , Susan Hares Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=376; t=1150316738; x=1151180738; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Request=20WG=20Last=20Call=20for=20BGP=20ORF=20and=20Prefix-ORF=20drafts; X=v=3Dcisco.com=3B=20h=3DtvG6+LfOhVKKNWR2zkIIrThkeSg=3D; b=E/MJ7ur8Khskk7bhnczFYdJlWSyp7U5yAsQI0Lhi4oZ0WFcJl/X+L9GSDKQ4/aICY3SPghXX PtNZkfSF4fCht6iWhelWnwMzTWbHvrxx7bY2K2qn0W4J2gxibHSRR92c; Authentication-Results: sj-dkim-8.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Inter-Domain Routing List Subject: [Idr] Request WG Last Call for BGP ORF and Prefix-ORF drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Yakov and Sue: I would like request that the WG Last Call be issued for the following drafts: draft-ietf-idr-route-filter-14.txt draft-ietf-idr-bgp-prefix-orf-03.txt The implementation report is draft-chen-bgp-orf-survey-00.txt. The issues identified in the implementation report has been addressed by the revised draft (-14.txt). Thanks. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 14 17:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqca7-0006s2-S2; Wed, 14 Jun 2006 17:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqca6-0006rx-QX for idr@ietf.org; Wed, 14 Jun 2006 17:07:18 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqca5-0000nr-FW for idr@ietf.org; Wed, 14 Jun 2006 17:07:18 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5EL7EX93591; Wed, 14 Jun 2006 14:07:14 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5EL79572946; Wed, 14 Jun 2006 14:07:09 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606142107.k5EL79572946@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61315.1150319229.1@juniper.net> Date: Wed, 14 Jun 2006 14:07:09 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Idr] WG Last Call for BGP ORF and Prefix-ORF drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, This is to start IDR WG Last Call on advancing the following documents to Proposed Standard: draft-ietf-idr-route-filter-14.txt draft-ietf-idr-bgp-prefix-orf-03.txt Implementation report is draft-chen-bgp-orf-survey-00.txt. The Last Call ends Jun 28, 2006. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 26 04:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fum44-0002Pk-O4; Mon, 26 Jun 2006 04:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fum44-0002Pf-5S for idr@ietf.org; Mon, 26 Jun 2006 04:03:24 -0400 Received: from mail03.powweb.com ([66.152.97.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fum42-0006o3-ST for idr@ietf.org; Mon, 26 Jun 2006 04:03:24 -0400 Received: from [192.168.1.101] (host81-129-66-3.range81-129.btcentralplus.com [81.129.66.3]) by mail03.powweb.com (Postfix) with ESMTP id BD3B014D866 for ; Mon, 26 Jun 2006 01:03:21 -0700 (PDT) Message-ID: <449F94CB.9060109@abelon.com> Date: Mon, 26 Jun 2006 09:03:23 +0100 From: Neil Matthew User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: Re: [Idr] WG Last Call for BGP ORF and Prefix-ORF drafts References: <200606142107.k5EL79572946@merlot.juniper.net> In-Reply-To: <200606142107.k5EL79572946@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Folks Just one question on the route filter draft. The section on Community and Extended Community ORF types has been removed. I can see that this makes for a more generic document but are these ORF types to be described in a separate document and does their removal at this stage alter their behaviour? Cheers Neil Yakov Rekhter wrote: >Folks, > >This is to start IDR WG Last Call on advancing the following documents >to Proposed Standard: > > draft-ietf-idr-route-filter-14.txt > draft-ietf-idr-bgp-prefix-orf-03.txt > >Implementation report is draft-chen-bgp-orf-survey-00.txt. > >The Last Call ends Jun 28, 2006. > >Yakov. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 26 08:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqKY-0006FP-1z; Mon, 26 Jun 2006 08:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqKW-000644-73 for idr@ietf.org; Mon, 26 Jun 2006 08:36:40 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqKU-0003Xh-Ri for idr@ietf.org; Mon, 26 Jun 2006 08:36:40 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5QCac1Z070317; Mon, 26 Jun 2006 05:36:38 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5QCaX553475; Mon, 26 Jun 2006 05:36:33 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606261236.k5QCaX553475@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] IDR WG meeting at IETF 66 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59124.1151325393.1@juniper.net> Date: Mon, 26 Jun 2006 05:36:33 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: skh@nexthop.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, So far we received no requests for presentations at the upcoming IDR WG meeting. If you plan to make a presentation at the IDR WG meeting this IETF, please send an e-mail to Sue and myself. The deadline is June 30. Sue and Yakov. P.S. If you plan to make a presentation, please also keep in mind the rule "no Internet Draft - no time slot". _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 26 08:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqMw-0007YD-5O; Mon, 26 Jun 2006 08:39:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqMu-0007Y2-EI for idr@ietf.org; Mon, 26 Jun 2006 08:39:08 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqMt-0003ga-3F for idr@ietf.org; Mon, 26 Jun 2006 08:39:08 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5QCd31Z070428; Mon, 26 Jun 2006 05:39:03 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5QCd3554008; Mon, 26 Jun 2006 05:39:03 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606261239.k5QCd3554008@merlot.juniper.net> To: Neil Matthew Subject: Re: [Idr] WG Last Call for BGP ORF and Prefix-ORF drafts In-Reply-To: Your message of "Mon, 26 Jun 2006 09:03:23 BST." <449F94CB.9060109@abelon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59200.1151325543.1@juniper.net> Date: Mon, 26 Jun 2006 05:39:03 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Neil, > Hi Folks > > Just one question on the route filter draft. The section on Community > and Extended Community ORF types has been removed. I can see that this > makes for a more generic document but are these ORF types to be > described in a separate document and does their removal at this stage > alter their behaviour? Yes to the former. No to the latter. See draft-chen-bgp-ext-community-orf-00.txt Yakov. > > Cheers > > Neil > > Yakov Rekhter wrote: > > >Folks, > > > >This is to start IDR WG Last Call on advancing the following documents > >to Proposed Standard: > > > > draft-ietf-idr-route-filter-14.txt > > draft-ietf-idr-bgp-prefix-orf-03.txt > > > >Implementation report is draft-chen-bgp-orf-survey-00.txt. > > > >The Last Call ends Jun 28, 2006. > > > >Yakov. > > > >_______________________________________________ > >Idr mailing list > >Idr@ietf.org > >https://www1.ietf.org/mailman/listinfo/idr > > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr