Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29949 for ; Thu, 26 Jul 2001 18:07:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBA6A9121A; Thu, 26 Jul 2001 18:04:37 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A184291332; Thu, 26 Jul 2001 18:04:37 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 793759121A for ; Thu, 26 Jul 2001 18:04:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 856855DDA9; Thu, 26 Jul 2001 18:06:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from miata.procket.com (miata.procket.com [209.140.237.2]) by segue.merit.edu (Postfix) with ESMTP id D21625DDA6 for ; Thu, 26 Jul 2001 18:06:34 -0400 (EDT) Received: (from srihari@localhost) by miata.procket.com (8.11.1/8.11.1) id f6QM59a09038; Thu, 26 Jul 2001 15:05:09 -0700 (PDT) Date: Thu, 26 Jul 2001 15:05:09 -0700 (PDT) From: "Srihari R. Sangli" To: "Waters, Stephen" Cc: "'idr@merit.edu'" Subject: RE: RE: Re: suggestions for draft-ietf-idr-restart-01 In-Reply-To: <3820E2042B6ED5118DC200D0B78EDC470F1DE7@exc-reo1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > > When a peer does not send the Graceful restart capability, does that mean > that there is no point saving state? To extend the life of the box as a 'forwarding device' when BGP has crashed, in some topologies it may be useful to keep the state. See the Deployment section of the draft for some insight. > For example, > > If peer A sends the Graceful Restart capability to preserve IP IV to peer B, > but peer B does not send the GR cap, and then peer A restarts, is there any > point peer A doing the GR 'Restarting side' stuff, since it would appear > that peer B will not merely mark A's routes as stale, but will delete them > on detecting a failure or restart? Like I said above, there may be benefit in A doing the 'Restarting side' stuff which is going to be useful if B has not detected failure yet. Once A learns that B is not GR capable - this is equivalent to B being capable but was also restarted (see simulataneous restart case in the draft). I would do treat them similarly. > If peer B knows nothing about GR, then if peer A 'guessed' that it did, that > would cause delay in routes know to A being re-learnt by B since it may wait > for an End-Of-RIB from B and B would have no 'old' routes to work with. No. You may want to classify the peers as GR-capable and non-GR-capable/ restarted and hence do not wait for End-of-RIB from the second group of peers. So the 'guess work' is not needed. This section has been updated in the draft based on recent email discussion. srihari... Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA29192 for ; Thu, 26 Jul 2001 17:32:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E9591331; Thu, 26 Jul 2001 17:29:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 500CF91332; Thu, 26 Jul 2001 17:29:59 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E16091331 for ; Thu, 26 Jul 2001 17:29:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D2A05DDA9; Thu, 26 Jul 2001 17:31:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from miata.procket.com (miata.procket.com [209.140.237.2]) by segue.merit.edu (Postfix) with ESMTP id 602615DDA6 for ; Thu, 26 Jul 2001 17:31:57 -0400 (EDT) Received: (from srihari@localhost) by miata.procket.com (8.11.1/8.11.1) id f6QLUSu04649; Thu, 26 Jul 2001 14:30:28 -0700 (PDT) Date: Thu, 26 Jul 2001 14:30:28 -0700 (PDT) From: "Srihari R. Sangli" To: "Waters, Stephen" Cc: "'idr@merit.edu'" Subject: RE: suggestions for draft-ietf-idr-restart-01 In-Reply-To: <3820E2042B6ED5118DC200D0B78EDC470F1DE2@exc-reo1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > And in the case where AFIs are present, but the restart timer value is zero? > Unless otherwise stated, this would be read to mean that the peer intends to > recover instantly, Yes. > which is going to difficult given the TCP/BGP opening > game.. Yes, most of the time. > I am assuming the Restart Timer will be started when a TCP or BGP failure is > spotted (TCP error or HOLD TIME timer). If the Restart Timer expires, then > the non-restarting peer gives up on the peer flushes all routes learnt. True. But exceptions are when a BGP peer is using MD5 like the draft says: When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. > When would the Restart timer be 'stopped'? When a new TCP > connection/OPEN-message arrives from the failed peer? TCP connection establishment. We can clarify this in the draft. > A value of zero would seem to be useless, and should either have a special > meaning (as originally suggested), or be illegal. > Making it illegal will not buy us anything IMO. It may add a mimimum delay in convergence when you know you should have come up instantly, but could not (in the multi-RP case we talked about before). > It does make me think that most sane implementations should impose a > lower-limit on this value - a value that will presumably need to be > system/model specific to allow for various architectures and their recovery > rate. Yes. Its completely optional. srihari... Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28954 for ; Fri, 20 Jul 2001 16:54:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A2FC912D9; Fri, 20 Jul 2001 16:51:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3593A912DA; Fri, 20 Jul 2001 16:51:46 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1160E912D9 for ; Fri, 20 Jul 2001 16:51:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EA235DDA9; Fri, 20 Jul 2001 16:53:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from miata.procket.com (miata.procket.com [209.140.237.2]) by segue.merit.edu (Postfix) with ESMTP id BB1C85DDA8 for ; Fri, 20 Jul 2001 16:53:32 -0400 (EDT) Received: (from srihari@localhost) by miata.procket.com (8.11.1/8.11.1) id f6KKqFZ05685; Fri, 20 Jul 2001 13:52:15 -0700 (PDT) Date: Fri, 20 Jul 2001 13:52:14 -0700 (PDT) From: "Srihari R. Sangli" To: robcrane40@netscape.net Cc: idr@merit.edu Subject: RE: RE: Re: suggestions for draft-ietf-idr-restart-01 In-Reply-To: <3AF0F88C.0EBF0586.106E1E70@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > But the switch-over from the primary controller to the secondary > controller could also be planned. For example, you could have put a new > release of software on the secondary controller and they you might type > some "switch now" command to switch over to the secondary controller. In > this scenario, it is very plausible that the primary controller might try > to gracefully close the BGP sessions by sending a CEASE NOTIFICATION. The problem can be solved w/o sending the CEASE notification here and rely on the mechanims specified in the draft. CEASE notification are useful if one wants to override the behaviour specified in the draft. (i.e. to get rid of the routes when a router is being taken out of service) > According to this draft it MUST not do that (because if it would, the > other side would not keep the routes and mark them as stale). We might > introduce a "I-am-going-to-switch-over-now" NOTIFICATION specifically for > this purpose. I don't see the need. See above. srihari... Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28242 for ; Fri, 20 Jul 2001 16:24:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9AFA912D8; Fri, 20 Jul 2001 16:21:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5049912D9; Fri, 20 Jul 2001 16:21:47 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B154C912D8 for ; Fri, 20 Jul 2001 16:21:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 067775DDA9; Fri, 20 Jul 2001 16:23:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by segue.merit.edu (Postfix) with ESMTP id C0DE45DDA8 for ; Fri, 20 Jul 2001 16:23:34 -0400 (EDT) Received: from robcrane40@netscape.net by imo-d04.mx.aol.com (mail_out_v31.7.) id s.4.1b840e9 (16220); Fri, 20 Jul 2001 16:16:44 -0400 (EDT) Received: from netscape.com (mow-d02.webmail.aol.com [205.188.138.66]) by air-in01.mail.aol.com (v79.27) with ESMTP id MAILININ18-0720161644; Fri, 20 Jul 2001 16:16:44 -0400 Date: Fri, 20 Jul 2001 16:16:44 -0400 From: robcrane40@netscape.net To: "Srihari R. Sangli" Cc: idr@merit.edu Subject: RE: RE: Re: suggestions for draft-ietf-idr-restart-01 Message-ID: <3AF0F88C.0EBF0586.106E1E70@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-idr@merit.edu Precedence: bulk >> ***> I was looking for some more specific statement of what it was that >> you are *not* supposed to do when you receive a notification (e.g. keep >> routes and mark them as stale). But if that is obvious to everyone, I >> guess it is not needed. > >I think its obvious. NOTIFICATIONs are sent when errors are encountered. >That quite explains it. Except the CEASE NOTIFICATION which is not sent as a result of an error. If a primary controller crashes and you switch over to a secondary controller as a result of that, the (crashed) primary controller is obviously not going to send any NOTIFICATION. But the switch-over from the primary controller to the secondary controller could also be planned. For example, you could have put a new release of software on the secondary controller and they you might type some "switch now" command to switch over to the secondary controller. In this scenario, it is very plausible that the primary controller might try to gracefully close the BGP sessions by sending a CEASE NOTIFICATION. According to this draft it MUST not do that (because if it would, the other side would not keep the routes and mark them as stale). We might introduce a "I-am-going-to-switch-over-now" NOTIFICATION specifically for this purpose. R. __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27002 for ; Fri, 20 Jul 2001 15:34:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E9BF912D6; Fri, 20 Jul 2001 15:32:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7207F912D5; Fri, 20 Jul 2001 15:32:04 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E274F912D6 for ; Fri, 20 Jul 2001 15:31:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A9095DDB2; Fri, 20 Jul 2001 15:33:37 -0400 (EDT) Delivered-To: idr@merit.edu Received: from miata.procket.com (miata.procket.com [209.140.237.2]) by segue.merit.edu (Postfix) with ESMTP id 89EB25DD91 for ; Fri, 20 Jul 2001 15:33:36 -0400 (EDT) Received: (from srihari@localhost) by miata.procket.com (8.11.1/8.11.1) id f6KJWIt28076; Fri, 20 Jul 2001 12:32:18 -0700 (PDT) Date: Fri, 20 Jul 2001 12:32:18 -0700 (PDT) From: "Srihari R. Sangli" To: robcrane40@netscape.net Cc: idr@merit.edu Subject: RE: Re: suggestions for draft-ietf-idr-restart-01 In-Reply-To: <329A4B95.6C33E992.106E1E70@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > ***> Ah! I missed that part. So, just to make sure we're on the same > page: If I send the capability without any AFI/SAFI I am indicating that > I will send an End-of-RIB marker for all address families but I am not > capable of preserving forwarding state for any address family. And, if I > send the capability with only AFI=ipv4 SAFI=unicast I am saying that I > will send the end-of-rib marker for all (!) address families but I can > only preserve forwarding state for the ipv4-unicast address family (but > not for ipv4 multicast or ipv6 unicast). Yes. I can see the why its confusing. May be we should add "will generate End-of-RIB marker for all address familiy(s) exchanged". Will update the draft. > ***> I was looking for some more specific statement of what it was that > you are *not* supposed to do when you receive a notification (e.g. keep > routes and mark them as stale). But if that is obvious to everyone, I > guess it is not needed. I think its obvious. NOTIFICATIONs are sent when errors are encountered. That quite explains it. srihari... Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA26248 for ; Fri, 20 Jul 2001 15:04:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 287B3912D4; Fri, 20 Jul 2001 15:02:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5BBD912E1; Fri, 20 Jul 2001 15:02:10 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDD4B912D4 for ; Fri, 20 Jul 2001 15:02:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 078A25DDA9; Fri, 20 Jul 2001 15:03:53 -0400 (EDT) Delivered-To: idr@merit.edu Received: from imo-d08.mx.aol.com (imo-d08.mx.aol.com [205.188.157.40]) by segue.merit.edu (Postfix) with ESMTP id C80355DD91 for ; Fri, 20 Jul 2001 15:03:52 -0400 (EDT) Received: from robcrane40@netscape.net by imo-d08.mx.aol.com (mail_out_v31.9.) id s.1b.1b5cd0f (16244); Fri, 20 Jul 2001 15:02:04 -0400 (EDT) Received: from netscape.com (mow-d02.webmail.aol.com [205.188.138.66]) by air-in03.mail.aol.com (v79.27) with ESMTP id MAILININ38-0720150203; Fri, 20 Jul 2001 15:02:03 -0400 Date: Fri, 20 Jul 2001 15:02:03 -0400 From: robcrane40@netscape.net To: "Srihari R. Sangli" Cc: idr@merit.edu Subject: RE: Re: suggestions for draft-ietf-idr-restart-01 Message-ID: <329A4B95.6C33E992.106E1E70@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-idr@merit.edu Precedence: bulk "Srihari R. Sangli" wrote: See inline comments ***> below Thanks for your clarifications -- R. > > >> Would it make sense to make the following changes to draft-ietf-idr-restart-01? >> >> < CHANGE 1 > >> >> OLD: >> >> Restart Time: >> >> This is the estimated time (in seconds) it will take for the BGP >> session to be re-established after a restart. This can be used to >> speed up routing convergence by its peer in case that the BGP >> speaker does not come back after a restart. >> >> NEW: >> >> Restart Time: >> >> This is the estimated time (in seconds) it will take for the BGP >> session to be re-established after a restart. This can be used to >> speed up routing convergence by its peer in case that the BGP >> speaker does not come back after a restart. A restart time of >> zero indicates that the BGP speaker will generate an End-Of-RIB >> marker but is not able to preserve its forwarding state during >> a BGP restart. > >I don't think the above is necessary because its already taken care of in >the draft like below: > > Capability value: Consists of the "Restart Flags" field, > "Restart Time" field, and zero or more of the tuples Sub-AFI, Flags for address family> as follows. > >and > > The advertisement of this capability by a BGP speaker also implies > that it will generate the End-of-RIB marker upon completion of its > initial routing update to its peer. The value of the "Restart Time" > field is irrelevant in the case that the capability does not carry > any . ***> Ah! I missed that part. So, just to make sure we're on the same page: If I send the capability without any AFI/SAFI I am indicating that I will send an End-of-RIB marker for all address families but I am not capable of preserving forwarding state for any address family. And, if I send the capability with only AFI=ipv4 SAFI=unicast I am saying that I will send the end-of-rib marker for all (!) address families but I can only preserve forwarding state for the ipv4-unicast address family (but not for ipv4 multicast or ipv6 unicast). > > > >> >> < CHANGE 2 > >> >> OLD: >> >> However, it shall defer route >> selection for an address family until it receives the End-of-RIB >> marker from all its peers (excluding the ones with the "Restart >> State" bit set in the received capability). >> >> NEW: >> >> However, it shall defer route >> selection for an address family until it receives the End-of-RIB >> marker from all its peers (excluding the ones with the "Restart >> State" bit set in the received capability and excluding the ones >> which did not advertise the graceful restart capability). > >Can be done. Will update the draft. ***> Thanks > >> >> < CHANGE 3 > >> >> OLD: >> >> When the TCP reset is detected by the Receiving Speaker, it shall >> retain the routes received from the Restarting Speaker for all the >> address families that were previously received in the Graceful >> Restart Capability, and shall mark them as stale routing information. >> >> NEW: >> >> When the TCP reset is detected by the Receiving Speaker, it shall >> retain the routes received from the Restarting Speaker for all the >> address families that were previously received in the Graceful >> Restart Capability, and shall mark them as stale routing information. >> >> However, if the peer advertised a restart time of zero (indicating >> that the peer is not able to preserve the forwarding state) it shall >> not retain the routes received from the Restarting Speaker and any >> routes from that peer previously marked as stale shall be deleted. > >I take the above is not needed. See above. ***> Agreed. >> >> < CHANGE 4 > >> >> Could some additional language be added to clarify the following statement? >> >> It is noted that the normal BGP procedures MUST be followed when the >> TCP session terminates due to the sending or receiving of a BGP >> NOTIFICATION message. >> > >What needs to be clarified here. The draft does not change the >interpretation of existing NOTIFICATION message. ***> I was looking for some more specific statement of what it was that you are *not* supposed to do when you receive a notification (e.g. keep routes and mark them as stale). But if that is obvious to everyone, I guess it is not needed. >srihari... > >> >> >> >> __________________________________________________________________ >> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ >> >> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ >> >> _______________________________________________ >> Idr-external mailing list >> Idr-external@mailist.procket.com >> http://mailist.procket.com/mailman/listinfo/idr-external >> > __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA26132 for ; Fri, 20 Jul 2001 14:59:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1901791217; Fri, 20 Jul 2001 14:57:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8FBC912D4; Fri, 20 Jul 2001 14:56:59 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A418B91217 for ; Fri, 20 Jul 2001 14:56:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9F1D5DDB2; Fri, 20 Jul 2001 14:58:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from miata.procket.com (miata.procket.com [209.140.237.2]) by segue.merit.edu (Postfix) with ESMTP id F31F45DD91; Fri, 20 Jul 2001 14:58:45 -0400 (EDT) Received: (from srihari@localhost) by miata.procket.com (8.11.1/8.11.1) id f6KIvSB24033; Fri, 20 Jul 2001 11:57:28 -0700 (PDT) Date: Fri, 20 Jul 2001 11:57:28 -0700 (PDT) From: "Srihari R. Sangli" To: robcrane40@netscape.net Cc: idr@merit.edu, idr-post@merit.edu Subject: Re: suggestions for draft-ietf-idr-restart-01 In-Reply-To: <44292E31.05FC1AC7.106E1E70@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > Would it make sense to make the following changes to draft-ietf-idr-restart-01? > > < CHANGE 1 > > > OLD: > > Restart Time: > > This is the estimated time (in seconds) it will take for the BGP > session to be re-established after a restart. This can be used to > speed up routing convergence by its peer in case that the BGP > speaker does not come back after a restart. > > NEW: > > Restart Time: > > This is the estimated time (in seconds) it will take for the BGP > session to be re-established after a restart. This can be used to > speed up routing convergence by its peer in case that the BGP > speaker does not come back after a restart. A restart time of > zero indicates that the BGP speaker will generate an End-Of-RIB > marker but is not able to preserve its forwarding state during > a BGP restart. I don't think the above is necessary because its already taken care of in the draft like below: Capability value: Consists of the "Restart Flags" field, "Restart Time" field, and zero or more of the tuples as follows. and The advertisement of this capability by a BGP speaker also implies that it will generate the End-of-RIB marker upon completion of its initial routing update to its peer. The value of the "Restart Time" field is irrelevant in the case that the capability does not carry any . > > < CHANGE 2 > > > OLD: > > However, it shall defer route > selection for an address family until it receives the End-of-RIB > marker from all its peers (excluding the ones with the "Restart > State" bit set in the received capability). > > NEW: > > However, it shall defer route > selection for an address family until it receives the End-of-RIB > marker from all its peers (excluding the ones with the "Restart > State" bit set in the received capability and excluding the ones > which did not advertise the graceful restart capability). Can be done. Will update the draft. > > < CHANGE 3 > > > OLD: > > When the TCP reset is detected by the Receiving Speaker, it shall > retain the routes received from the Restarting Speaker for all the > address families that were previously received in the Graceful > Restart Capability, and shall mark them as stale routing information. > > NEW: > > When the TCP reset is detected by the Receiving Speaker, it shall > retain the routes received from the Restarting Speaker for all the > address families that were previously received in the Graceful > Restart Capability, and shall mark them as stale routing information. > > However, if the peer advertised a restart time of zero (indicating > that the peer is not able to preserve the forwarding state) it shall > not retain the routes received from the Restarting Speaker and any > routes from that peer previously marked as stale shall be deleted. I take the above is not needed. See above. > > < CHANGE 4 > > > Could some additional language be added to clarify the following statement? > > It is noted that the normal BGP procedures MUST be followed when the > TCP session terminates due to the sending or receiving of a BGP > NOTIFICATION message. What needs to be clarified here. The draft does not change the existing interpretation of any message. srihari... > > > > > __________________________________________________________________ > Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ > > Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ > > _______________________________________________ > Idr-external mailing list > Idr-external@mailist.procket.com > http://mailist.procket.com/mailman/listinfo/idr-external > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA16415 for ; Fri, 20 Jul 2001 08:37:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4EEAF912C1; Fri, 20 Jul 2001 08:34:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A47A912C4; Fri, 20 Jul 2001 08:34:46 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F058C912C1 for ; Fri, 20 Jul 2001 08:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA6B65DDA8; Fri, 20 Jul 2001 08:36:32 -0400 (EDT) Delivered-To: idr@merit.edu Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41]) by segue.merit.edu (Postfix) with ESMTP id 422DD5DD9F for ; Fri, 20 Jul 2001 08:36:32 -0400 (EDT) Received: from robcrane40@netscape.net by imo-d09.mx.aol.com (mail_out_v31.7.) id m.2e.1acf7e3 (16234); Fri, 20 Jul 2001 08:35:13 -0400 (EDT) Received: from netscape.com (mow-m04.webmail.aol.com [64.12.184.132]) by air-in02.mail.aol.com (v79.27) with ESMTP id MAILININ210-0720083512; Fri, 20 Jul 2001 08:35:12 -0400 Date: Fri, 20 Jul 2001 08:35:12 -0400 From: robcrane40@netscape.net To: idr@merit.edu, isp-bgp@isp-bgp.com Subject: IPv6 RIB size? Message-ID: <19FA2D2E.4C4BFA80.106E1E70@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-idr@merit.edu Precedence: bulk Does anyone have any experience with the number of and distribution of prefixes in an IPv6 network? Imagine that we change every existing IPv4 host in the world to an IPv6 host. - Would we have more or less than the current 100K distinct prefixes in the BGP local-RIB? What about the number of paths (multi-homing is done differently)? - What would the distribution of prefix lengths look like? For example, would we ever expect to see a prefix more specific than a /64 in the default-free zone? Would these assumptions change if IPv6 has different kinds of hosts than IPv4 (e.g. cell phones and toasters instead of PCs)? R. __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26695 for ; Thu, 19 Jul 2001 19:12:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB58A91290; Thu, 19 Jul 2001 19:10:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F06A91291; Thu, 19 Jul 2001 19:10:15 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 791BA91290 for ; Thu, 19 Jul 2001 19:10:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3265C5DDAB; Thu, 19 Jul 2001 19:12:01 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id A71EA5DDA5; Thu, 19 Jul 2001 19:12:00 -0400 (EDT) Received: from lx-eval3.redback.com (lx-eval3.redback.com [155.53.34.163]) by prattle.redback.com (Postfix) with ESMTP id 697F6F2C5C; Thu, 19 Jul 2001 16:10:45 -0700 (PDT) Received: (from roque@localhost) by lx-eval3.redback.com (8.9.3/8.9.3/null redback linux client) id QAA05889; Thu, 19 Jul 2001 16:10:45 -0700 X-Authentication-Warning: lx-eval3.redback.com: roque set sender to roque@redback.com using -f From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15191.26869.371370.706666@lx-eval3.redback.com> Date: Thu, 19 Jul 2001 16:10:45 -0700 (PDT) To: "Li, Eve" Cc: idr@merit.edu, idr-post@merit.edu Subject: RE: IPV4 NLRI & MP_REACH NLRI In-Reply-To: <6B190B34070BD411ACA000B0D0214E56C663E8@newman.tenornet.com> References: <6B190B34070BD411ACA000B0D0214E56C663E8@newman.tenornet.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-idr@merit.edu Precedence: bulk >>>>> "Eve" == Li, Eve writes: Eve> After looking through RFC 2858, it is not clear to me if a Eve> BGP4 packet can carry both MP_REACH_NLRI and regular IPv4 Eve> NLRI. Can anyone clarify this issue? Eve> on page 16 of draft-ietf-idr-bgp4-12, it says: " All path Eve> attributes contained in a given UPDATE messages apply to the Eve> destinations carried in the Network Layer Reachability Eve> Information field of the UPDATE message. " Eve> This implies that there should never be both MP_REACH_NLRI Eve> and IPv4 NLRI in one packet. If you have an update msgs that includes n attributes + an MP_REACH_NLRI for an af other than ipv4 + NEXTHOP attr + nlri that msg would apear to be consistent to all the rules. Eve> However, on page 5 of RFC2858, it says: Eve> An UPDATE message that carries no NLRI, other than the one Eve> encoded in the MP_REACH_NLRI attribute, should not carry the Eve> NEXT_HOP attribute. If such a message contains the NEXT_HOP Eve> attribute, the BGP speaker that receives the message should Eve> ignore this attribute. Eve> This seems to imply that it is OK to carry both MP_REACH_NLRI Eve> & IPv4 NLRI. Eve> If a BGP packet can carry both MP_REACH_NLRI attribute and Eve> regular IPv4 NLRI. How does the path attribute apply to both Eve> NLRIs? For example, suppose the path attribute contains Eve> extended community with Route Target Community as type Eve> field. Does this path attribute applies to both MP_reach_nlri Eve> and Ipv4 unicast nlri? Also, does MP_REACH_NLRI apply to the Eve> IPV4 NLRI. The MP_REACH_NLRI is not an attribute per se... it is encoded as such because attributes are the extensible encoding mechanism in update msgs. But one should look at it as encoding extension to encode non ipv4 unicast NLRI. All attributes of an update apply to nlri and mp_reach_nlri except: - mp_reach_nlri isn't really an attribute and as such doesn't apply to nlri. - nexthop doesn't apply to mp_reach_nlri's as it is superceeded by the nexthop included in mp_reach (which would tend to be for a different address family anyway). regards, Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA26271 for ; Thu, 19 Jul 2001 18:50:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2DF29128F; Thu, 19 Jul 2001 18:48:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C5B891290; Thu, 19 Jul 2001 18:48:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9473B9128F for ; Thu, 19 Jul 2001 18:48:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 454FE5DDA0; Thu, 19 Jul 2001 18:50:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from imo-m07.mx.aol.com (imo-m07.mx.aol.com [64.12.136.162]) by segue.merit.edu (Postfix) with ESMTP id C4E475DDA5 for ; Thu, 19 Jul 2001 18:50:26 -0400 (EDT) Received: from robcrane40@netscape.net by imo-m07.mx.aol.com (mail_out_v31.7.) id m.1f.1a612d0 (16230) for ; Thu, 19 Jul 2001 18:49:03 -0400 (EDT) Received: from netscape.com (mow-m03.webmail.aol.com [64.12.184.131]) by air-in02.mail.aol.com (v79.27) with ESMTP id MAILININ26-0719184902; Thu, 19 Jul 2001 18:49:02 -0400 Date: Thu, 19 Jul 2001 18:49:02 -0400 From: robcrane40@netscape.net To: idr@merit.edu Subject: suggestions for draft-ietf-idr-restart-01 Message-ID: <44292E31.05FC1AC7.106E1E70@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-idr@merit.edu Precedence: bulk Would it make sense to make the following changes to draft-ietf-idr-restart-01? < CHANGE 1 > OLD: Restart Time: This is the estimated time (in seconds) it will take for the BGP session to be re-established after a restart. This can be used to speed up routing convergence by its peer in case that the BGP speaker does not come back after a restart. NEW: Restart Time: This is the estimated time (in seconds) it will take for the BGP session to be re-established after a restart. This can be used to speed up routing convergence by its peer in case that the BGP speaker does not come back after a restart. A restart time of zero indicates that the BGP speaker will generate an End-Of-RIB marker but is not able to preserve its forwarding state during a BGP restart. < CHANGE 2 > OLD: However, it shall defer route selection for an address family until it receives the End-of-RIB marker from all its peers (excluding the ones with the "Restart State" bit set in the received capability). NEW: However, it shall defer route selection for an address family until it receives the End-of-RIB marker from all its peers (excluding the ones with the "Restart State" bit set in the received capability and excluding the ones which did not advertise the graceful restart capability). < CHANGE 3 > OLD: When the TCP reset is detected by the Receiving Speaker, it shall retain the routes received from the Restarting Speaker for all the address families that were previously received in the Graceful Restart Capability, and shall mark them as stale routing information. NEW: When the TCP reset is detected by the Receiving Speaker, it shall retain the routes received from the Restarting Speaker for all the address families that were previously received in the Graceful Restart Capability, and shall mark them as stale routing information. However, if the peer advertised a restart time of zero (indicating that the peer is not able to preserve the forwarding state) it shall not retain the routes received from the Restarting Speaker and any routes from that peer previously marked as stale shall be deleted. < CHANGE 4 > Could some additional language be added to clarify the following statement? It is noted that the normal BGP procedures MUST be followed when the TCP session terminates due to the sending or receiving of a BGP NOTIFICATION message. __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA26232 for ; Thu, 19 Jul 2001 18:49:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0C759120D; Thu, 19 Jul 2001 18:46:19 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89D519128F; Thu, 19 Jul 2001 18:46:19 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96B899120D for ; Thu, 19 Jul 2001 18:46:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 431355DDAA; Thu, 19 Jul 2001 18:48:01 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id A4D7E5DDA5; Thu, 19 Jul 2001 18:48:00 -0400 (EDT) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6JMkiK00783; Thu, 19 Jul 2001 18:46:45 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; THU, 19 Jul 2001 18:38:45 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Jul 2001 18:38:45 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56C663E8@newman.tenornet.com> From: "Li, Eve" To: idr@merit.edu, idr-post@merit.edu Subject: RE: IPV4 NLRI & MP_REACH NLRI Date: Thu, 19 Jul 2001 18:38:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk -----Original Message----- From: Li, Eve Sent: Wednesday, July 18, 2001 11:45 AM To: idr@merit.edu Subject: IPV4 NLRI & MP_REACH NLRI After looking through RFC 2858, it is not clear to me if a BGP4 packet can carry both MP_REACH_NLRI and regular IPv4 NLRI. Can anyone clarify this issue? on page 16 of draft-ietf-idr-bgp4-12, it says: " All path attributes contained in a given UPDATE messages apply to the destinations carried in the Network Layer Reachability Information field of the UPDATE message. " This implies that there should never be both MP_REACH_NLRI and IPv4 NLRI in one packet. However, on page 5 of RFC2858, it says: An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message should ignore this attribute. This seems to imply that it is OK to carry both MP_REACH_NLRI & IPv4 NLRI. If a BGP packet can carry both MP_REACH_NLRI attribute and regular IPv4 NLRI. How does the path attribute apply to both NLRIs? For example, suppose the path attribute contains extended community with Route Target Community as type field. Does this path attribute applies to both MP_reach_nlri and Ipv4 unicast nlri? Also, does MP_REACH_NLRI apply to the IPV4 NLRI. Any clarifications? -eve Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16504 for ; Tue, 17 Jul 2001 12:30:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B21FD91238; Tue, 17 Jul 2001 12:28:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 882B891239; Tue, 17 Jul 2001 12:28:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6992F91238 for ; Tue, 17 Jul 2001 12:28:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1E175DDEB; Tue, 17 Jul 2001 12:30:26 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 231735DDE3 for ; Tue, 17 Jul 2001 12:30:26 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f6HGTDH47808; Tue, 17 Jul 2001 09:29:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200107171629.f6HGTDH47808@merlot.juniper.net> To: idr@merit.edu Cc: yakov@juniper.net, skh@nexthop.com Subject: WG meeting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4973.995387353.1@juniper.net> Date: Tue, 17 Jul 2001 09:29:13 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, We'll be meeting in London. Please send the proposed agenda items to co-chairs (Sue Hares and myself). Yakov. Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16384 for ; Tue, 17 Jul 2001 12:26:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4469D91243; Tue, 17 Jul 2001 12:24:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A91939124C; Tue, 17 Jul 2001 12:24:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD4A591242 for ; Tue, 17 Jul 2001 12:24:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D94C55DDEB; Tue, 17 Jul 2001 12:25:50 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ren-9.cais.net (ren-9.cais.net [205.252.14.84]) by segue.merit.edu (Postfix) with ESMTP id 51F625DDF1 for ; Tue, 17 Jul 2001 12:25:50 -0400 (EDT) Received: from [63.216.127.100] (63-216-127-100.sdsl.cais.net [63.216.127.100]) by ren-9.cais.net (8.11.1/8.11.1) with ESMTP id f6HGOcm76157 for ; Tue, 17 Jul 2001 12:24:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: Date: Tue, 17 Jul 2001 12:24:32 -0400 To: idr@merit.edu From: "Howard C. Berkowitz" Subject: Experiments on why the routing table is growing Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk This is a very experimental draft that still may be of interest to IDR people who are interested not just that the BGP table is growing, but why it is growing. It's coauthored by Elwyn Davies of Nortel (UK) and Loa Andersson of Utfors (Sweden). We'd like to run over it briefly in London, and may have some early experimental data to present. ---------- Title : An Experimental Methodology for Analysis of Growth in the Global Routing Table Author(s) : H. Berkowitz et al. Filename : draft-berkowitz-tblgrow-00.txt Pages : 5 Date : 16-Jul-01 Measurements [3,4,5] have shown that the rate of growth of routes and route instances in the default-free table have resumed exponential growth, which had slowed to linear growth after the introduction of CIDR [7]. This memorandum explores some analytical methods, admittedly heuristic in most cases, to understand why growth is faster than the simple rate of allocation. When accelerated growth can be attributed to operational practices or poor understanding, it may be possible to propose approaches to reducing the rate of table explosion without reducing the services delivered to end users. Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16362 for ; Tue, 17 Jul 2001 12:26:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D94C291237; Tue, 17 Jul 2001 12:23:48 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF60F91238; Tue, 17 Jul 2001 12:23:48 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C174191237 for ; Tue, 17 Jul 2001 12:23:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C7795DDEB; Tue, 17 Jul 2001 12:25:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ren-8.cais.net (ren-8.cais.net [205.252.14.83]) by segue.merit.edu (Postfix) with ESMTP id B96105DDE3 for ; Tue, 17 Jul 2001 12:25:29 -0400 (EDT) Received: from [63.216.127.100] (63-216-127-100.sdsl.cais.net [63.216.127.100]) by ren-8.cais.net (8.11.1/8.11.1) with ESMTP id f6HGOG165624 for ; Tue, 17 Jul 2001 12:24:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: Date: Tue, 17 Jul 2001 12:23:14 -0400 To: idr@merit.edu From: "Howard C. Berkowitz" Subject: New drafts on BGP convergence Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk These new Internet Drafts are now standards track in the IETF Benchmarking Technology Working Group. Obviously, they relate closely to IDR, and we'd like to give a brief briefing in London, along with any experimental results we may have available by then. These were coauthored by a multivendor team, including Alvaro Retana of Cisco, Marianne Lepp of Juniper, Sue Hares and Padma Krisnaswamy of Nexthop, and myself at Nortel. Elwyn Davies (Nortel) should have some early experimental data available in the next couple of weeks, although this is to validate the methodology rather than make any direct comparisons of commercial routers. ------------------- Title : Terminology for Benchmarking External Routing Convergence Measurements Author(s) : H. Berkowitz et al. Filename : draft-ietf-bmwg-conterm-00.txt Pages : Date : 16-Jul-01 This draft establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single router. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and internet-wide convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-00.txt ------------------- Title : Benchmarking Methodology for Basic BGP Convergence Author(s) : H. Berkowitz et al. Filename : draft-ietf-bmwg-bgpbas-00.txt Pages : Date : 16-Jul-01 This draft establishes standards for measuring BGP convergence performance. Its initial emphasis is on the control plane of single BGP routers. We do not address forwarding plane performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-bgpbas-00.txt Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29190 for ; Tue, 3 Jul 2001 14:59:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C172191210; Tue, 3 Jul 2001 14:56:44 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93651912E1; Tue, 3 Jul 2001 14:56:44 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4CBA91210 for ; Tue, 3 Jul 2001 14:56:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95B075DDAE; Tue, 3 Jul 2001 14:57:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 5056A5DD99 for ; Tue, 3 Jul 2001 14:57:56 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f63Iv1Z56856; Tue, 3 Jul 2001 14:57:02 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f63Iv1i16070; Tue, 3 Jul 2001 14:57:01 -0400 (EDT) Date: Tue, 3 Jul 2001 14:57:01 -0400 From: Jeffrey Haas To: Alex Zinin Cc: John Engelhart , idr@merit.edu Subject: Re: RFC 3065, confeds.. Message-ID: <20010703145701.G15782@nexthop.com> References: <20010627105343.A7138@nexthop.com> <20010702130805.B246@nexthop.com> <17685437102.20010703115452@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <17685437102.20010703115452@nexsi.com>; from azinin@nexsi.com on Tue, Jul 03, 2001 at 11:54:52AM -0700 Sender: owner-idr@merit.edu Precedence: bulk On Tue, Jul 03, 2001 at 11:54:52AM -0700, Alex Zinin wrote: > Except that I don't believe that "silently" is a correct behavior. > The BGP speaker need to draw the administrator's attention by (at > least) logging a message. Apologies. My error. > > Alex also made additional suggestions about rules for modification > > of the AS_PATH. Without a mechanism to know the configuration of > > your peer's confederation settings, these additions wouldn't work. > > IMO, > > Do you mean not sending AS_CONF_* out to an eBGP peer outside > the confed? Yes. Upon reviewing the message in question, I misinterpreted announcing things outside of the confederation as implying pre-knowledge by a protocol mechanism that a peer was part of the confederation or not. You didn't actually say that. > Alex. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28892 for ; Tue, 3 Jul 2001 14:49:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 05AFC9120A; Tue, 3 Jul 2001 14:47:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD139120D; Tue, 3 Jul 2001 14:47:53 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7D759120A for ; Tue, 3 Jul 2001 14:47:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 848355DDB0; Tue, 3 Jul 2001 14:49:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [63.121.79.248]) by segue.merit.edu (Postfix) with ESMTP id E246A5DDAE for ; Tue, 3 Jul 2001 14:49:07 -0400 (EDT) Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA19295; Tue, 3 Jul 2001 11:54:53 -0700 Date: Tue, 3 Jul 2001 11:54:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <17685437102.20010703115452@nexsi.com> To: Jeffrey Haas Cc: John Engelhart , idr@merit.edu Subject: Re: RFC 3065, confeds.. In-Reply-To: <20010702130805.B246@nexthop.com> References: <20010627105343.A7138@nexthop.com> <20010702130805.B246@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeffrey, > Add: > A BGP speaker receiving an AS_PATH attribute containing an > AS_CONFED_SEQUENCE or AS_CONFED_SET from a peer which is not > configured to be a member of its confederation SHALL . > Where could either be: > generate a > notification message specifying an "UPDATE Message Error" and a sub- > code of "Malformed AS_PATH". > Or: > silently discard the BGP route. > The first case is what I would prefer given the current design of > the BGP protocol. The second case would possibly please the operational > community. Please see the most recent discussion on RFC-1771 on > the NANOG list if you don't know what I'm talking about. A polite > summary is, IDR should consider the implications of soft-failure > in the presence of "Bad Routing Data". > Alex Z. suggested similar text using the latter behavior. Except that I don't believe that "silently" is a correct behavior. The BGP speaker need to draw the administrator's attention by (at least) logging a message. > Alex also made additional suggestions about rules for modification > of the AS_PATH. Without a mechanism to know the configuration of > your peer's confederation settings, these additions wouldn't work. > IMO, Do you mean not sending AS_CONF_* out to an eBGP peer outside the confed? Alex. > with the receiver-side filtering, the current modification > rules are probably fine. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01005 for ; Mon, 2 Jul 2001 15:58:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E4669127E; Mon, 2 Jul 2001 15:56:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2218A9127F; Mon, 2 Jul 2001 15:56:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD3299127E for ; Mon, 2 Jul 2001 15:56:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E2B55DD96; Mon, 2 Jul 2001 15:57:53 -0400 (EDT) Delivered-To: idr@merit.edu Received: from login01.snv3.gctr.net (login01.snv3.gctr.net [64.210.184.228]) by segue.merit.edu (Postfix) with ESMTP id 23AC45DD93 for ; Mon, 2 Jul 2001 15:57:53 -0400 (EDT) Received: (from andrewl@localhost) by login01.snv3.gctr.net (8.11.2/8.11.0) id f62Jutb11559; Mon, 2 Jul 2001 19:56:55 GMT Date: Mon, 2 Jul 2001 19:56:55 +0000 From: Andrew Lange To: Jeffrey Haas Cc: John Engelhart , idr@merit.edu Subject: Re: RFC 3065, confeds.. Message-ID: <20010702195655.B10577@exodus.net> References: <20010627105343.A7138@nexthop.com> <20010702130805.B246@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: Jeffrey Haas's message from Mon, Jul 02, 2001 at 01:08:05PM - ID <20010702130805.B246@nexthop.com> Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jul 02, 2001 at 01:08:05PM -0400, Jeffrey Haas wrote: > On Thu, Jun 28, 2001 at 01:21:50AM -0700, John Engelhart wrote: > > Specifically, the above quoted section from the RFC is being interpreted > > by Cisco and Juniper to mean that even if confederations aren't enabled > > and configured, it's still valid to accept and pass them on to other IBGP > > peers. > > As noted by others, the issue is not the AS_PATH modification rules > when re-advertising/originating routes, its the operational behavior > on receipt. > > IMO, the AS_PATH modification rules in the current RFC are fine. > What we probably want is something along the lines of the following > modification: > > 6. Operation > [...] > A BGP speaker receiving an AS_PATH attribute containing an > AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS > Number shall treat the path in the same fashion as if it had received > a path containing its own AS number. > > Add: > > A BGP speaker receiving an AS_PATH attribute containing an > AS_CONFED_SEQUENCE or AS_CONFED_SET from a peer which is not > configured to be a member of its confederation SHALL . > > Where could either be: > generate a > notification message specifying an "UPDATE Message Error" and a sub- > code of "Malformed AS_PATH". > > Or: > silently discard the BGP route. > > The first case is what I would prefer given the current design of > the BGP protocol. The second case would possibly please the operational > community. Please see the most recent discussion on RFC-1771 on > the NANOG list if you don't know what I'm talking about. A polite > summary is, IDR should consider the implications of soft-failure > in the presence of "Bad Routing Data". I agree that the proper behavior is to drop the BGP session. If the session dampening specified in RFC-1771 is implemented, the impact of the flapping would be progressively lessened. I would also like to see a toggle from the vendors that says "if session has flapped n times, errdisable the session", but that is an implementation detail. Silently discarding the route might work to remedy the problems of this specific bug, but it doesn't provide a good paradigm for generic handling of malformed AS paths. There is the general issue of not breaking the protocol to fix the bugs. Then there is the troubleshooting aspect: Customer: "Why can't I get to www.foo.com? It resolves to x.x.x.x/x." NOC Engineer: "I doesn't seem to be advertized anywhere." With silent discard, reachiblity problems could be missed for long periods. And, perhaps most importantly, we are already trusting our peers to an amazing extent (insert rant about the radb being sufficently unused to make filtering major peers impossible), if the peer sends us one bad route, the probablity that they are going to send us more than one goes up enough to warrent not trusting them at all. > Alex Z. suggested similar text using the latter behavior. > > Alex also made additional suggestions about rules for modification > of the AS_PATH. Without a mechanism to know the configuration of > your peer's confederation settings, these additions wouldn't work. > IMO, with the receiver-side filtering, the current modification > rules are probably fine. Yes, the only viable options are dropping the session, or dropping the route. Andrew Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA26908 for ; Mon, 2 Jul 2001 13:21:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A168691270; Mon, 2 Jul 2001 13:19:53 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 734BD91271; Mon, 2 Jul 2001 13:19:53 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F6DC91270 for ; Mon, 2 Jul 2001 13:19:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B9EA5DDA5; Mon, 2 Jul 2001 13:21:06 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id CBD975DD93 for ; Mon, 2 Jul 2001 13:21:05 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f62HKCZ96177 for ; Mon, 2 Jul 2001 13:20:12 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f62HKAJ00644 for idr@merit.edu; Mon, 2 Jul 2001 13:20:10 -0400 (EDT) Date: Mon, 2 Jul 2001 13:20:10 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: Previous work on TTL on bgp routes? Message-ID: <20010702132010.D246@nexthop.com> References: <94B9091E1149D411A45C00508BACEB359CDBEB@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBEB@entmail.gnilink.com>; from cmartin@gnilink.net on Mon, Jun 18, 2001 at 02:39:47PM -0400 Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jun 18, 2001 at 02:39:47PM -0400, Martin, Christian wrote: > This is exactly what I was thinking of. Is there interest in putting this > in BGP? This could significantly localize route table bloat in the > Internet, but still allows for efficient TE in multihomed environments. Someone has beaten us to it: Controlling the redistribution of BGP routes Initial comments, already made to the author: o The "append N-AS's by proxy" mechanism is nice, but it would be nicer if it was generic. o The format of "cidr prefix/length" ebgp speakers field mechanism seems a little awkward, especially in the cases where the peering session is done over loopback interfaces or multi-hopped in some other fashion. > -chris -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA26765 for ; Mon, 2 Jul 2001 13:14:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 896289126F; Mon, 2 Jul 2001 13:12:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F07791270; Mon, 2 Jul 2001 13:12:18 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 572799126F for ; Mon, 2 Jul 2001 13:12:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7DB85DD96; Mon, 2 Jul 2001 13:13:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id BDD1E5DD93 for ; Mon, 2 Jul 2001 13:13:29 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f62HBlZ95619 for ; Mon, 2 Jul 2001 13:12:22 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f62HBZi00623 for idr@merit.edu; Mon, 2 Jul 2001 13:11:35 -0400 (EDT) Date: Mon, 2 Jul 2001 13:11:35 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Re: route reflection language change suggestion Message-ID: <20010702131135.C246@nexthop.com> References: <313895461.20010626125202@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <313895461.20010626125202@nexsi.com>; from azinin@nexsi.com on Tue, Jun 26, 2001 at 12:52:02PM -0700 Sender: owner-idr@merit.edu Precedence: bulk On Tue, Jun 26, 2001 at 12:52:02PM -0700, Alex Zinin wrote: > Something like the text below is what I meant. :) > We definitely don't want to make the spec a deployment > guidelines doc, but a small note is good. Its not unreasonable to put together a deployment guidelines document if the protocol gives you too much rope to hang yourself. RFC 177[234] provide examples about talking about the uses of BGP. If we feel the need for a document on deployment of hierarchical scaling solutions for BGP, a deployment document may be helpful. I'd suggest coming to closure on the MED churn issue before such a document is drafted. > Alex Zinin -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA26668 for ; Mon, 2 Jul 2001 13:09:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D95949126C; Mon, 2 Jul 2001 13:07:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A72DF9126F; Mon, 2 Jul 2001 13:07:55 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF3EA9126C for ; Mon, 2 Jul 2001 13:07:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CD725DD96; Mon, 2 Jul 2001 13:09:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 073535DD93 for ; Mon, 2 Jul 2001 13:09:08 -0400 (EDT) Received: from jhaas.nexthop.com ([141.211.130.148]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f62H85Z95179; Mon, 2 Jul 2001 13:08:05 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id f62H85g00611; Mon, 2 Jul 2001 13:08:05 -0400 (EDT) Date: Mon, 2 Jul 2001 13:08:05 -0400 From: Jeffrey Haas To: John Engelhart Cc: idr@merit.edu Subject: Re: RFC 3065, confeds.. Message-ID: <20010702130805.B246@nexthop.com> References: <20010627105343.A7138@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from johne@exodus.net on Thu, Jun 28, 2001 at 01:21:50AM -0700 Sender: owner-idr@merit.edu Precedence: bulk My apologies for making comments initially on this thread and not having the time to follow up promptly. On Thu, Jun 28, 2001 at 01:21:50AM -0700, John Engelhart wrote: > Specifically, the above quoted section from the RFC is being interpreted > by Cisco and Juniper to mean that even if confederations aren't enabled > and configured, it's still valid to accept and pass them on to other IBGP > peers. As noted by others, the issue is not the AS_PATH modification rules when re-advertising/originating routes, its the operational behavior on receipt. IMO, the AS_PATH modification rules in the current RFC are fine. What we probably want is something along the lines of the following modification: 6. Operation [...] A BGP speaker receiving an AS_PATH attribute containing an AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS Number shall treat the path in the same fashion as if it had received a path containing its own AS number. Add: A BGP speaker receiving an AS_PATH attribute containing an AS_CONFED_SEQUENCE or AS_CONFED_SET from a peer which is not configured to be a member of its confederation SHALL . Where could either be: generate a notification message specifying an "UPDATE Message Error" and a sub- code of "Malformed AS_PATH". Or: silently discard the BGP route. The first case is what I would prefer given the current design of the BGP protocol. The second case would possibly please the operational community. Please see the most recent discussion on RFC-1771 on the NANOG list if you don't know what I'm talking about. A polite summary is, IDR should consider the implications of soft-failure in the presence of "Bad Routing Data". Alex Z. suggested similar text using the latter behavior. Alex also made additional suggestions about rules for modification of the AS_PATH. Without a mechanism to know the configuration of your peer's confederation settings, these additions wouldn't work. IMO, with the receiver-side filtering, the current modification rules are probably fine. -- Jeff Haas NextHop Technologies