From owner-idr@merit.edu Sat Jun 1 15:18:00 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26491 for ; Sat, 1 Jun 2002 15:17:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0D139120D; Sat, 1 Jun 2002 15:17:51 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90AEE9121F; Sat, 1 Jun 2002 15:17:51 -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 7A4C59120D for ; Sat, 1 Jun 2002 15:17:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74A9B5DE12; Sat, 1 Jun 2002 15:17:44 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id B42755DD8D for ; Sat, 1 Jun 2002 15:17:43 -0400 (EDT) Received: from [171.69.182.155] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA20755; Sat, 1 Jun 2002 15:17:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <20020531183559.0648E7E6C1@popserv3.redback.com> References: <20020531183559.0648E7E6C1@popserv3.redback.com> Date: Sat, 1 Jun 2002 15:17:34 -0400 To: Enke Chen From: "John G. Scudder" Subject: Re: Comments on draft-walton-bgp-add-paths-00.txt Cc: Alvaro Retana , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, enke@redback.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 11:35 AM -0700 5/31/02, Enke Chen wrote: >The draft specifies a way to advertise and withdraw a path for a prefix. IMO >per-path based update would require significant additional state >(i.e., per-path >instead of per prefix) and memory in order to avoid spurious withdraws that we >experienced in the past. > >We could avoid the additional state and simplify implementation if we treat >all the paths of a prefix as one unit in advertisement and withdraw. By "one >Unit" I mean that all paths are advertised (could be in multiple messages) >together, and are withdrawn by the NLRI. > >This can be accomplished by introducing two additional bit flags for the >reachable NLRIs: > > o First Path Bit: When set, this indicates this is the first path for > the prefix, and any existing paths should be removed. > (This is similar to the current implicit replacement.) > When clear, there is no implicit replacement. > > o Last Path Bit: When set, this indicates this is the last path, and > bestpath selection should be done immediately. When > clear, the bestpath selection may be deferred. > This would help avoid FIB churn. > >Please note that with this approach there is no need to change the encoding >of unreachable NLRIs, and the path "Identifier" field in the draft is no >longer needed. Enke, This is slightly different from my earlier understanding of your suggestion. I had understood that you were suggesting that the first/last path bits be optional. I'm fine with them in that context. However, it seems you are suggesting that the proposal be further modified so that use of first/last path would be the ONLY way to replace routes (this is implied by the suggestion that the ID field be dropped). This could cause substantial inefficiency due to the need to re-advertise unchanged paths. I'm not in favor of dropping the ID field. Regards, --John From owner-idr@merit.edu Sat Jun 1 16:17:45 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27043 for ; Sat, 1 Jun 2002 16:17:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B43019121F; Sat, 1 Jun 2002 16:17:36 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862C6912C0; Sat, 1 Jun 2002 16:17:36 -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 618559121F for ; Sat, 1 Jun 2002 16:17:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C1625DE2E; Sat, 1 Jun 2002 16:17:29 -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 DCE2B5DD8D for ; Sat, 1 Jun 2002 16:17:28 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 05C924BA213; Sat, 1 Jun 2002 13:17:35 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id C1A8E15D3C1; Sat, 1 Jun 2002 13:17:32 -0700 (PDT) To: "John G. Scudder" Cc: Alvaro Retana , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, enke@redback.com Subject: Re: Comments on draft-walton-bgp-add-paths-00.txt In-Reply-To: Message from "John G. Scudder" of "Sat, 01 Jun 2002 15:17:34 EDT." Date: Sat, 01 Jun 2002 13:17:31 -0700 From: Enke Chen Message-Id: <20020601201732.C1A8E15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, John: > Date: Sat, 1 Jun 2002 15:17:34 -0400 > To: Enke Chen > From: "John G. Scudder" > Subject: Re: Comments on draft-walton-bgp-add-paths-00.txt > Cc: Alvaro Retana , idr@merit.edu, > dwalton@cisco.com, dacook@cisco.com, enke@redback.com > > At 11:35 AM -0700 5/31/02, Enke Chen wrote: > >The draft specifies a way to advertise and withdraw a path for a prefix. IMO > >per-path based update would require significant additional state > >(i.e., per-path > >instead of per prefix) and memory in order to avoid spurious withdraws that we > >experienced in the past. > > > >We could avoid the additional state and simplify implementation if we treat > >all the paths of a prefix as one unit in advertisement and withdraw. By "one > >Unit" I mean that all paths are advertised (could be in multiple messages) > >together, and are withdrawn by the NLRI. > > > >This can be accomplished by introducing two additional bit flags for the > >reachable NLRIs: > > > > o First Path Bit: When set, this indicates this is the first path for > > the prefix, and any existing paths should be removed. > > (This is similar to the current implicit replacement.) > > When clear, there is no implicit replacement. > > > > o Last Path Bit: When set, this indicates this is the last path, and > > bestpath selection should be done immediately. When > > clear, the bestpath selection may be deferred. > > This would help avoid FIB churn. > > > >Please note that with this approach there is no need to change the encoding > >of unreachable NLRIs, and the path "Identifier" field in the draft is no > >longer needed. > > Enke, > > This is slightly different from my earlier understanding of your > suggestion. I had understood that you were suggesting that the > first/last path bits be optional. I'm fine with them in that context. > > However, it seems you are suggesting that the proposal be further > modified so that use of first/last path would be the ONLY way to > replace routes (this is implied by the suggestion that the ID field > be dropped). This could cause substantial inefficiency due to the > need to re-advertise unchanged paths. I'm not in favor of dropping > the ID field. There is a tradeoff between maintaing additional state with the per-path based update and the duplicate path update with per-prefix based approach. The suggestion I posted in the previous message is for "per-prefix" based update. Actually it seems to be mainly an implementation decision whether to use per-path based update or per-prefix based update. The protocol could be made flexiable to accomodate both implementations. For that purpose, we will need to define a mechanism to withdraw all paths of a prefix (w/o replacement path). This could be a via flag, or by using a special ID number (e.g., the largest). Thanks. -- Enke From owner-idr@merit.edu Wed Jun 5 10:28:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02188 for ; Wed, 5 Jun 2002 10:28:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0C8691270; Wed, 5 Jun 2002 10:28:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A07B391271; Wed, 5 Jun 2002 10:28:28 -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 967C791270 for ; Wed, 5 Jun 2002 10:28:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55F365DE7D; Wed, 5 Jun 2002 10:28:22 -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 1A9275DE64 for ; Wed, 5 Jun 2002 10:28:22 -0400 (EDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id D9C11FC05E; Wed, 5 Jun 2002 07:28:28 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 050FD979C1; Wed, 5 Jun 2002 07:28:17 -0700 (PDT) To: idr@merit.edu Cc: enke@redback.com Subject: draft-chen-rr-oscillation-reduce-00.txt Date: Wed, 05 Jun 2002 07:28:17 -0700 From: Enke Chen Message-Id: <20020605142818.050FD979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: Two drafts are posted: o draft-chen-rr-oscillation-reduce-00.txt o draft-chen-confed-oscillation-reduce-00.txt A simple proposal for Route Reflection and one for Confederration are presented for presistent route oscillation reduction. Based on our computation, they resolve all the persisitent route oscillation cases documented. If you have a persistent route oscillatin case that can not be resolved by these proposals, we will appreciate greatly if you let us know. Comments? Regards, -- Enke ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt Date: Wed, 05 Jun 2002 07:33:23 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Route Oscillation Reduction with Route Reflection Author(s) : E. Chen Filename : draft-chen-rr-oscillation-reduce-00.txt Pages : 4 Date : 04-Jun-02 This document proposes a simple revision to Route Reflection that allows a Route Reflector to advertise the best path from its clients to other clusters when the overall best path for the RR differs. The availability of the routing information to other clusters helps achieve stable route selection, and moves route reflection closer to IBGP full-mesh equivalence in terms of routing information. It has been shown that the proposed mechanism eliminates a number of persistent route oscillation cases involving Route Reflection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt ------- End of Forwarded Message From owner-idr@merit.edu Wed Jun 5 16:13:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16806 for ; Wed, 5 Jun 2002 16:13:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7FF9D9127D; Wed, 5 Jun 2002 16:13:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CCB791253; Wed, 5 Jun 2002 16:13: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 379769127E for ; Wed, 5 Jun 2002 16:13:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E729A5DDB7; Wed, 5 Jun 2002 16:13:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id ADCE05DE96 for ; Wed, 5 Jun 2002 16:13:40 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g55KDmEF043538; Wed, 5 Jun 2002 16:13:48 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g55KDfo41198; Wed, 5 Jun 2002 16:13:41 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id QAA1892716; Wed, 5 Jun 2002 16:13:41 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id QAA06628; Wed, 5 Jun 2002 16:13:40 -0400 (EDT) Message-ID: <3CFE70F4.63DE@research.bell-labs.com> Date: Wed, 05 Jun 2002 16:13:40 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <20020605142818.050FD979C1@popserv2.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Unfortunately, this method can fail to prevent persistent oscillations. Consider the example below that appears in a work in progress by Tim Griffin and Gordon Wilfong. There is a single cluster with one route reflector [RR1] and two client routers [C1] and [C2]. The client routers get routes from outside their AS from [AS1] and [AS2]. The numbers in parentheses represent the MED values. The unadorned numbers on the links between [RR1] and its clients are the IGP metric values. The unadorned numbers on the links from the client [C1] to the two outside ASes represent [C1]'s preference according to BGP tie breaking (with lower number representing the more preferred route). The example has the property that it suffers from persistent route oscillations. However the method discussed in draft-chen-rr-oscillation-reduce-00.txt will not prevent this oscillation since the route reflector's best route is always a client's route and so the method's behavior will be unchanged from unmodified I-BGP. 4 [RR1] ************* * * 1 * * * * * * * * [C1] [C2] *** * 2 * * 1 * * * * (2) * (1) * * (0) * * * [AS1] **[AS2] - Gordon Enke Chen wrote: > > Hi, folks: > Two drafts are posted: > > o draft-chen-rr-oscillation-reduce-00.txt > o draft-chen-confed-oscillation-reduce-00.txt > > A simple proposal for Route Reflection and one for Confederration > are presented for presistent route oscillation reduction. Based > on our computation, they resolve all the persisitent route oscillation > cases documented. > > If you have a persistent route oscillatin case that can not be resolved > by these proposals, we will appreciate greatly if you let us know. > > Comments? > > Regards, -- Enke > > ------- Forwarded Message > > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt > Date: Wed, 05 Jun 2002 07:33:23 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : BGP Route Oscillation Reduction with Route Reflection > Author(s) : E. Chen > Filename : draft-chen-rr-oscillation-reduce-00.txt > Pages : 4 > Date : 04-Jun-02 > > This document proposes a simple revision to Route Reflection that > allows a Route Reflector to advertise the best path from its clients > to other clusters when the overall best path for the RR differs. The > availability of the routing information to other clusters helps > achieve stable route selection, and moves route reflection closer to > IBGP full-mesh equivalence in terms of routing information. It has > been shown that the proposed mechanism eliminates a number of > persistent route oscillation cases involving Route Reflection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt > > ------- End of Forwarded Message From owner-idr@merit.edu Wed Jun 5 17:42:28 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21560 for ; Wed, 5 Jun 2002 17:42:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31D4F9127D; Wed, 5 Jun 2002 17:42:14 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03A3A9127E; Wed, 5 Jun 2002 17:42:13 -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 E188B9127D for ; Wed, 5 Jun 2002 17:42:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B76885DE8E; Wed, 5 Jun 2002 17:42:07 -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 31CAA5DE88 for ; Wed, 5 Jun 2002 17:42:07 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id C4F3E1DCC77; Wed, 5 Jun 2002 14:42:13 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 677367E6C1; Wed, 5 Jun 2002 14:42:13 -0700 (PDT) To: Gordon Wilfong Cc: idr@merit.edu, enke@redback.com Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: Message from Gordon Wilfong of "Wed, 05 Jun 2002 16:13:40 EDT." <3CFE70F4.63DE@research.bell-labs.com> Date: Wed, 05 Jun 2002 14:42:13 -0700 From: Enke Chen Message-Id: <20020605214213.677367E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Gordon: As you correctly pointed out: > However the method discussed in draft-chen-rr-oscillation-reduce-00.txt > will not prevent this oscillation since the route reflector's best route > is always a client's route and so the method's behavior will be unchanged > from unmodified I-BGP. > The proposal presented in draft-chen-rr-oscillation-reduce-00.txt does not impact this case. However, a couple comments on this case: o In general a route oscillation within a cluster can be resolved easily by full-mesh the clients within the cluster, which does not have a scalability issue, and is a better operational model. This is one way to resolve this case. o The code has been deployment for almost 3 years that (by default) avoid the switch between two EBGP paths when the route selection goes to the "random" steps (e.g., router-id comparison). As a result, C1 would converge to AS1 as the best. This is another way to resolve this case. Now you know the real reason why that step was introduced in the route selection :-) Regards, -- Enke > Message-ID: <3CFE70F4.63DE@research.bell-labs.com> > Date: Wed, 05 Jun 2002 16:13:40 -0400 > From: Gordon Wilfong > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > References: <20020605142818.050FD979C1@popserv2.redback.com> > > Unfortunately, this method can fail to > prevent persistent oscillations. > > Consider the example below that appears in a work > in progress by Tim Griffin and Gordon Wilfong. > There is a single cluster with one route reflector [RR1] and two > client routers [C1] and [C2]. The client routers > get routes from outside their AS from [AS1] and > [AS2]. The numbers in parentheses represent the > MED values. The unadorned numbers on the links between > [RR1] and its clients are the IGP metric values. > The unadorned numbers on the links from the client [C1] > to the two outside ASes represent [C1]'s preference > according to BGP tie breaking (with lower number representing > the more preferred route). > The example has the property that it suffers from persistent > route oscillations. However the method discussed in > draft-chen-rr-oscillation-reduce-00.txt will not prevent this > oscillation since the route reflector's best route is always > a client's route and so the method's behavior will be unchanged > from unmodified I-BGP. > > 4 > [RR1] ************* > * * > 1 * * > * * > * * > * * > [C1] [C2] > *** * > 2 * * 1 * > * * * > (2) * (1) * * (0) > * * * > [AS1] **[AS2] > > > > > - Gordon > > > > > > > > > > Enke Chen wrote: > > > > Hi, folks: > > Two drafts are posted: > > > > o draft-chen-rr-oscillation-reduce-00.txt > > o draft-chen-confed-oscillation-reduce-00.txt > > > > A simple proposal for Route Reflection and one for Confederration > > are presented for presistent route oscillation reduction. Based > > on our computation, they resolve all the persisitent route oscillation > > cases documented. > > > > If you have a persistent route oscillatin case that can not be resolved > > by these proposals, we will appreciate greatly if you let us know. > > > > Comments? > > > > Regards, -- Enke > > > > ------- Forwarded Message > > > > To: IETF-Announce: ; > > From: Internet-Drafts@ietf.org > > Reply-To: Internet-Drafts@ietf.org > > Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt > > Date: Wed, 05 Jun 2002 07:33:23 -0400 > > Sender: nsyracus@cnri.reston.va.us > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : BGP Route Oscillation Reduction with Route Reflection > > Author(s) : E. Chen > > Filename : draft-chen-rr-oscillation-reduce-00.txt > > Pages : 4 > > Date : 04-Jun-02 > > > > This document proposes a simple revision to Route Reflection that > > allows a Route Reflector to advertise the best path from its clients > > to other clusters when the overall best path for the RR differs. The > > availability of the routing information to other clusters helps > > achieve stable route selection, and moves route reflection closer to > > IBGP full-mesh equivalence in terms of routing information. It has > > been shown that the proposed mechanism eliminates a number of > > persistent route oscillation cases involving Route Reflection. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt > > > > ------- End of Forwarded Message From owner-idr@merit.edu Wed Jun 5 19:01:11 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26001 for ; Wed, 5 Jun 2002 19:01:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9532C9128D; Wed, 5 Jun 2002 18:59:27 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70A5F9128B; Wed, 5 Jun 2002 18:59:27 -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 0C83591283 for ; Wed, 5 Jun 2002 18:59:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9CDB5DEC8; Wed, 5 Jun 2002 18:59:15 -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 82C005DEC6 for ; Wed, 5 Jun 2002 18:59:15 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g55MxKm91920; Wed, 5 Jun 2002 15:59:20 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g55MxJD84331; Wed, 5 Jun 2002 15:59:20 -0700 (PDT) (envelope-from roque) Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: Gordon Wilfong , idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: <20020605214213.677367E6C1@popserv3.redback.com> References: <3CFE70F4.63DE@research.bell-labs.com> <20020605214213.677367E6C1@popserv3.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Enke Chen writes: > Hi, Gordon: As you correctly pointed out: > o The code has been deployment for almost 3 years that (by > default) avoid the switch between two EBGP paths when the route > selection goes to the "random" steps (e.g., router-id > comparison). As a result, C1 would converge to AS1 as the best. This > is another way to resolve this case. > Now you know the real reason why that step was introduced in the > route selection :-) Avoiding the switch between paths doesn't avoid 'random' steps. It is itself a 'random' step in which the factor is arrival time of the route making it random and non-deterministic. If there are cases where this seems a good idea there is an equal number of cases where it makes things worse. I was under the impression that the "real reason" is much more related to certain implementation choices a vendor we used to work for has in their implementation that make it really hard for said implementation to suppress duplicate updates ;-) regards, Pedro. From owner-idr@merit.edu Wed Jun 5 19:17:18 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26707 for ; Wed, 5 Jun 2002 19:17:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8C3691284; Wed, 5 Jun 2002 19:14:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7856A91287; Wed, 5 Jun 2002 19:14:58 -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 F129D91284 for ; Wed, 5 Jun 2002 19:14:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C29F75DEC8; Wed, 5 Jun 2002 19:14:47 -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 885995DEC7 for ; Wed, 5 Jun 2002 19:14:47 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id D449E262804; Wed, 5 Jun 2002 16:14:54 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id C38A17E6C1; Wed, 5 Jun 2002 16:14:54 -0700 (PDT) To: Pedro Roque Marques Cc: Gordon Wilfong , idr@merit.edu, enke@redback.com Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: Message from Pedro Roque Marques of "Wed, 05 Jun 2002 15:59:20 PDT." <200206052259.g55MxJD84331@roque-bsd.juniper.net> Date: Wed, 05 Jun 2002 16:14:54 -0700 From: Enke Chen Message-Id: <20020605231454.C38A17E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) > Message-Id: <200206052259.g55MxJD84331@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: Enke Chen > Cc: Gordon Wilfong , idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > In-Reply-To: <20020605214213.677367E6C1@popserv3.redback.com> > > Enke Chen writes: > > > Hi, Gordon: As you correctly pointed out: > > > > o The code has been deployment for almost 3 years that (by > > default) avoid the switch between two EBGP paths when the route > > selection goes to the "random" steps (e.g., router-id > > comparison). As a result, C1 would converge to AS1 as the best. This > > is another way to resolve this case. > > > Now you know the real reason why that step was introduced in the > > route selection :-) > > Avoiding the switch between paths doesn't avoid 'random' steps. It is > itself a 'random' step in which the factor is arrival time of the > route making it random and non-deterministic. Let me clarify: I did not mean the step is "random" (sorry). I mean the result of the step is random. For example, a BGP speaker does not have any control over what router-id an EBGP peer will use (or change). In that case, it really does not matter to the speaker which EBGP path to choose when the route selection goes all the way to comparing router-id. > > If there are cases where this seems a good idea there is an equal > number of cases where it makes things worse. Is there a specific example that avoid EBGP switch (based on router-id) makes things worse? > > I was under the impression that the "real reason" is much more related > to certain implementation choices a vendor we used to work for has in > their implementation that make it really hard for said implementation > to suppress duplicate updates ;-) No, it was not the duplicate update. It was a real churn (involving RR) seen on one of the large ISP networks in the US three years ago. Srihari was the one that logged into the routers and first identified the churn. Regards, -- Enke From owner-idr@merit.edu Wed Jun 5 19:31:28 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27434 for ; Wed, 5 Jun 2002 19:31:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E309391285; Wed, 5 Jun 2002 19:30:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B086791286; Wed, 5 Jun 2002 19:30: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 4744F91285 for ; Wed, 5 Jun 2002 19:30:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F5A85DEB5; Wed, 5 Jun 2002 19:30:53 -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 6AF5A5DDBC for ; Wed, 5 Jun 2002 19:30:52 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g55NV0m94210; Wed, 5 Jun 2002 16:31:00 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g55NUxC84403; Wed, 5 Jun 2002 16:30:59 -0700 (PDT) (envelope-from roque) Date: Wed, 5 Jun 2002 16:30:59 -0700 (PDT) Message-Id: <200206052330.g55NUxC84403@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: <20020605231454.C38A17E6C1@popserv3.redback.com> References: <200206052259.g55MxJD84331@roque-bsd.juniper.net> <20020605231454.C38A17E6C1@popserv3.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Enke Chen writes: >> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: >> <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque >> Marques To: Enke Chen Cc: >> Gordon Wilfong , idr@merit.edu Subject: >> Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: >> <20020605214213.677367E6C1@popserv3.redback.com> >> >> Enke Chen writes: >> >> > Hi, Gordon: As you correctly pointed out: >> >> >> > o The code has been deployment for almost 3 years that (by > >> default) avoid the switch between two EBGP paths when the route > >> selection goes to the "random" steps (e.g., router-id > >> comparison). As a result, C1 would converge to AS1 as the >> best. This > is another way to resolve this case. >> >> > Now you know the real reason why that step was introduced in the >> > route selection :-) >> >> Avoiding the switch between paths doesn't avoid 'random' steps. It >> is itself a 'random' step in which the factor is arrival time of >> the route making it random and non-deterministic. > Let me clarify: I did not mean the step is "random" (sorry). I mean > the result of the step is random. For example, a BGP speaker does > not have any control over what router-id an EBGP peer will use (or > change). In that case, it really does not matter to the speaker > which EBGP path to choose when the route selection goes all the way > to comparing router-id. It matters that the router-id test is deterministic, i.e. predictable, while arrival order isn't. >> If there are cases where this seems a good idea there is an equal >> number of cases where it makes things worse. > Is there a specific example that avoid EBGP switch (based on > router-id) makes things worse? The main problem, imho, is that given a set of offered paths you cannot predict the behaviour, i.e. which path will be selected since it is not possible to predict the arrival order of the paths in a system. Personally i think that is a significant operational problem by itself. In this discussion, for instance, people attempt to given a set of paths predict the behaviour to check if it is stable or not and assume a deterministic behaviour in order to do so. In certain implementations that assumption is actually not correct. Although the IDR WG typically attempts to have a 'pratical' prespective on things, "theoretical" models are important in that they allow you to understand pratical behaviour. Let me put things in another way... even if i can't from the top of my head present you an example of what problems it causes, it doesn't mean that one can assert that it doesn't introduce new issues. i.e. lack of negative proof doesn't prove something. Pedro. From owner-idr@merit.edu Thu Jun 6 08:03:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08918 for ; Thu, 6 Jun 2002 08:03:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 577E19128B; Thu, 6 Jun 2002 08:03:29 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CEBB9128D; Thu, 6 Jun 2002 08:03:29 -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 B5FD49128B for ; Thu, 6 Jun 2002 08:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D7EE5DD9C; Thu, 6 Jun 2002 08:03:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 9B5A45DEB4 for ; Thu, 6 Jun 2002 08:03:17 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56C3OEF049134; Thu, 6 Jun 2002 08:03:24 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56C3Hk44884; Thu, 6 Jun 2002 08:03:18 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id IAA1926515; Thu, 6 Jun 2002 08:03:17 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id IAA16306; Thu, 6 Jun 2002 08:03:18 -0400 (EDT) Message-ID: <3CFF4F85.7566@research.bell-labs.com> Date: Thu, 06 Jun 2002 08:03:17 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: Pedro Roque Marques Cc: Enke Chen , idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <200206052259.g55MxJD84331@roque-bsd.juniper.net> <20020605231454.C38A17E6C1@popserv3.redback.com> <200206052330.g55NUxC84403@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pedro, I completely agree with your statement that theoretical models are essential in permitting a thorough understanding of the behavior of systems. I also agree with you when you say that nondeterministic behavior is a significant operational problem in that it makes reasoning about your network, and hence debugging your network, difficult. One aspect of nondeterministic behavior is something we called "transient oscillations" in our sigcomm 2002 paper. These are instances where extreme timing coincidences could cause route oscillations but such coincidences are very unlikely. The more significant aspect is that they indicate that there are more than one stable routing states that the system could fall into. That is, the behavior, while convergent, is nondeterministic. So for instance, the following example has two solutions. Given very unlikely timing coincidences it could exhibit route oscillations. ................................. . AS0 . . . . . . [R1]***************[R2] . . * * * * . . 2 * *1 1 * *2 . .....*....* .....* .....*....... * * * * * * * * (0) * * * * * *(1) (1) * * (0) * * * * [AS1] [AS2] This example comes from a paper Tim Griffin and I are working on. The numbers in parens are the MED values and the unadorned numbers indicate BGP tie breaking rules (the lower the number the more preferred the route). R1 and R2 are just two (fully-meshed) routers, not necessarily route reflectors in AS0. So one solution is where R1 chooses to go through AS1 and R2 chooses to go through AS2. Another solution is where R1 goes through AS2 and R2 goes through AS1. It all depends on timing which routing gets established. And the 2nd solution actually has the property that it violates the semantics of MEDs in that both routers end up with routes with higher MED values than other available routes through the same neighboring AS. Since the modification to IBGP that we describe in draft-wilfong-IBGP-oscillations-00.txt is guaranteed to eliminate such transient oscillations (as well as persistent oscillations), it guarantees not only will any system converge, but it will converge deterministically to the same solution irrespective of timing issues. (The solution our method would result in would be the first one with each Ri choosing the route through ASi.) - Gordon Pedro Roque Marques wrote: > > Enke Chen writes: > > >> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: > >> <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque > >> Marques To: Enke Chen Cc: > >> Gordon Wilfong , idr@merit.edu Subject: > >> Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: > >> <20020605214213.677367E6C1@popserv3.redback.com> > >> > >> Enke Chen writes: > >> > >> > Hi, Gordon: As you correctly pointed out: > >> > >> > >> > o The code has been deployment for almost 3 years that (by > > >> default) avoid the switch between two EBGP paths when the route > > >> selection goes to the "random" steps (e.g., router-id > > >> comparison). As a result, C1 would converge to AS1 as the > >> best. This > is another way to resolve this case. > >> > >> > Now you know the real reason why that step was introduced in the > >> > route selection :-) > >> > >> Avoiding the switch between paths doesn't avoid 'random' steps. It > >> is itself a 'random' step in which the factor is arrival time of > >> the route making it random and non-deterministic. > > > Let me clarify: I did not mean the step is "random" (sorry). I mean > > the result of the step is random. For example, a BGP speaker does > > not have any control over what router-id an EBGP peer will use (or > > change). In that case, it really does not matter to the speaker > > which EBGP path to choose when the route selection goes all the way > > to comparing router-id. > > It matters that the router-id test is deterministic, i.e. predictable, > while arrival order isn't. > > >> If there are cases where this seems a good idea there is an equal > >> number of cases where it makes things worse. > > > Is there a specific example that avoid EBGP switch (based on > > router-id) makes things worse? > > The main problem, imho, is that given a set of offered paths you > cannot predict the behaviour, i.e. which path will be selected since > it is not possible to predict the arrival order of the paths in a > system. Personally i think that is a significant operational problem > by itself. > > In this discussion, for instance, people attempt to given a set of > paths predict the behaviour to check if it is stable or not and assume > a deterministic behaviour in order to do so. In certain > implementations that assumption is actually not correct. > > Although the IDR WG typically attempts to have a 'pratical' > prespective on things, "theoretical" models are important in that they > allow you to understand pratical behaviour. > > Let me put things in another way... even if i can't from the top of my > head present you an example of what problems it causes, it doesn't > mean that one can assert that it doesn't introduce new > issues. i.e. lack of negative proof doesn't prove something. > > Pedro. From owner-idr@merit.edu Thu Jun 6 12:17:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19092 for ; Thu, 6 Jun 2002 12:17:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86FE3912A5; Thu, 6 Jun 2002 12:17:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A92E912A6; Thu, 6 Jun 2002 12:17: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 4492B912A5 for ; Thu, 6 Jun 2002 12:17:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4485C5DDA1; Thu, 6 Jun 2002 12:17:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id BE6865DD9C for ; Thu, 6 Jun 2002 12:17:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18009; Thu, 6 Jun 2002 12:17:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28643; Thu, 6 Jun 2002 12:17:46 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 12:17:46 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271A@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Gordon Wilfong'" , Enke Chen Cc: idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 6 Jun 2002 12:17: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 Sounds to me like all the proposals so far attempt to reduce the probability of route oscillations, but do not control or stop it totally. So I think another approach is warranted. Ben -----Original Message----- From: Gordon Wilfong [mailto:gtw@research.bell-labs.com] Sent: Wednesday, June 05, 2002 4:14 PM To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Unfortunately, this method can fail to prevent persistent oscillations. Consider the example below that appears in a work in progress by Tim Griffin and Gordon Wilfong. There is a single cluster with one route reflector [RR1] and two client routers [C1] and [C2]. The client routers get routes from outside their AS from [AS1] and [AS2]. The numbers in parentheses represent the MED values. The unadorned numbers on the links between [RR1] and its clients are the IGP metric values. The unadorned numbers on the links from the client [C1] to the two outside ASes represent [C1]'s preference according to BGP tie breaking (with lower number representing the more preferred route). The example has the property that it suffers from persistent route oscillations. However the method discussed in draft-chen-rr-oscillation-reduce-00.txt will not prevent this oscillation since the route reflector's best route is always a client's route and so the method's behavior will be unchanged from unmodified I-BGP. 4 [RR1] ************* * * 1 * * * * * * * * [C1] [C2] *** * 2 * * 1 * * * * (2) * (1) * * (0) * * * [AS1] **[AS2] - Gordon Enke Chen wrote: > > Hi, folks: > Two drafts are posted: > > o draft-chen-rr-oscillation-reduce-00.txt > o draft-chen-confed-oscillation-reduce-00.txt > > A simple proposal for Route Reflection and one for Confederration > are presented for presistent route oscillation reduction. Based > on our computation, they resolve all the persisitent route oscillation > cases documented. > > If you have a persistent route oscillatin case that can not be resolved > by these proposals, we will appreciate greatly if you let us know. > > Comments? > > Regards, -- Enke > > ------- Forwarded Message > > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt > Date: Wed, 05 Jun 2002 07:33:23 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : BGP Route Oscillation Reduction with Route Reflection > Author(s) : E. Chen > Filename : draft-chen-rr-oscillation-reduce-00.txt > Pages : 4 > Date : 04-Jun-02 > > This document proposes a simple revision to Route Reflection that > allows a Route Reflector to advertise the best path from its clients > to other clusters when the overall best path for the RR differs. The > availability of the routing information to other clusters helps > achieve stable route selection, and moves route reflection closer to > IBGP full-mesh equivalence in terms of routing information. It has > been shown that the proposed mechanism eliminates a number of > persistent route oscillation cases involving Route Reflection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt > > ------- End of Forwarded Message From owner-idr@merit.edu Thu Jun 6 12:24:28 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19265 for ; Thu, 6 Jun 2002 12:24:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A0F8912A6; Thu, 6 Jun 2002 12:24:14 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D6D0912A8; Thu, 6 Jun 2002 12:24:14 -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 02D36912A6 for ; Thu, 6 Jun 2002 12:24:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC8275DDA1; Thu, 6 Jun 2002 12:24:07 -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 AE4F45DD9C for ; Thu, 6 Jun 2002 12:24:07 -0400 (EDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 8B590449A30; Thu, 6 Jun 2002 09:24:14 -0700 (PDT) To: Gordon Wilfong Cc: Pedro Roque Marques , idr@merit.edu, enke@redback.com Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: Message from Gordon Wilfong of "Thu, 06 Jun 2002 08:03:17 EDT." <3CFF4F85.7566@research.bell-labs.com> Date: Thu, 06 Jun 2002 09:24:14 -0700 From: Enke Chen Message-Id: <20020606162414.8B590449A30@prattle.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Gordon: As I posted in the previous message, the local speaker does not have any control over the router-id allocation of the remote speaker. In addition, the router-id of the remote speaker can change without the prior knowledge of the local speaker. In that sense, the two external paths are equally good for the local speaker when the router-id has to be compared in route selection. We obvious are of different opinions on how big an issue the "non-deterministic behavior" (which one to select) is for a customer. Our opinions may not matter that much as compared to customers'. As we seem to be getting philosophical in the discussion thread, let me add some of my own. A "zero-cost" optimization is the the best thing, however, most of the time that is not possible. The next best thing is the "near-zero-cost" optimization, which IMO the approach of avoiding EBGP path switch (base on router-id) achieves. -- Enke > Message-ID: <3CFF4F85.7566@research.bell-labs.com> > Date: Thu, 06 Jun 2002 08:03:17 -0400 > To: Pedro Roque Marques > Cc: Enke Chen , idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > References: > <200206052259.g55MxJD84331@roque-bsd.juniper.net> > <20020605231454.C38A17E6C1@popserv3.redback.com> <200206052330.g55NUxC84403@roque-bsd.juniper.net> > > Hi Pedro, > > I completely agree with your statement that theoretical models > are essential in permitting a thorough understanding of > the behavior of systems. > > I also agree with you when you say that nondeterministic behavior > is a significant operational problem in that it makes reasoning > about your network, and hence debugging your network, difficult. > > One aspect of nondeterministic behavior is something we called > "transient oscillations" in our sigcomm 2002 paper. These > are instances where extreme timing coincidences could cause > route oscillations but such coincidences are > very unlikely. The more > significant aspect is that they indicate that there are more > than one stable routing states that the system could fall into. > That is, the behavior, while convergent, is nondeterministic. > > So for instance, the following example has two solutions. Given > very unlikely timing coincidences it could exhibit route oscillations. > > > ................................. > . AS0 . > . > . > . . > . [R1]***************[R2] > . > . * * * * > . > . 2 * *1 1 * *2 > . > .....*....* .....* > .....*....... > * * * > * > * * * > * > (0) * * * > * > * *(1) (1) * * > (0) > * * * > * > [AS1] [AS2] > > This example comes from a paper Tim Griffin and I are working > on. The numbers in parens are the MED values and the unadorned > numbers indicate BGP tie breaking rules (the lower the number > the more preferred the route). R1 and R2 are just > two (fully-meshed) routers, not necessarily route reflectors > in AS0. So one solution is where > R1 chooses to go through AS1 and R2 chooses to go through AS2. > Another solution is where R1 goes through AS2 and R2 goes through > AS1. It all depends on timing which routing gets established. > And the 2nd solution actually has the property that it violates > the semantics of MEDs in that both routers end up with routes > with higher MED values than other available routes through > the same neighboring AS. > > Since the modification to IBGP that we describe in > draft-wilfong-IBGP-oscillations-00.txt is guaranteed > to eliminate such transient oscillations (as well as > persistent oscillations), it guarantees not only will > any system converge, but it will converge deterministically > to the same solution irrespective of timing issues. > (The solution our method would result in would be the > first one with each Ri choosing the route through ASi.) > > - Gordon > > > Pedro Roque Marques wrote: > > > > Enke Chen writes: > > > > >> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: > > >> <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque > > >> Marques To: Enke Chen Cc: > > >> Gordon Wilfong , idr@merit.edu Subject: > > >> Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: > > >> <20020605214213.677367E6C1@popserv3.redback.com> > > >> > > >> Enke Chen writes: > > >> > > >> > Hi, Gordon: As you correctly pointed out: > > >> > > >> > > >> > o The code has been deployment for almost 3 years that (by > > > >> default) avoid the switch between two EBGP paths when the route > > > >> selection goes to the "random" steps (e.g., router-id > > > >> comparison). As a result, C1 would converge to AS1 as the > > >> best. This > is another way to resolve this case. > > >> > > >> > Now you know the real reason why that step was introduced in the > > >> > route selection :-) > > >> > > >> Avoiding the switch between paths doesn't avoid 'random' steps. It > > >> is itself a 'random' step in which the factor is arrival time of > > >> the route making it random and non-deterministic. > > > > > Let me clarify: I did not mean the step is "random" (sorry). I mean > > > the result of the step is random. For example, a BGP speaker does > > > not have any control over what router-id an EBGP peer will use (or > > > change). In that case, it really does not matter to the speaker > > > which EBGP path to choose when the route selection goes all the way > > > to comparing router-id. > > > > It matters that the router-id test is deterministic, i.e. predictable, > > while arrival order isn't. > > > > >> If there are cases where this seems a good idea there is an equal > > >> number of cases where it makes things worse. > > > > > Is there a specific example that avoid EBGP switch (based on > > > router-id) makes things worse? > > > > The main problem, imho, is that given a set of offered paths you > > cannot predict the behaviour, i.e. which path will be selected since > > it is not possible to predict the arrival order of the paths in a > > system. Personally i think that is a significant operational problem > > by itself. > > > > In this discussion, for instance, people attempt to given a set of > > paths predict the behaviour to check if it is stable or not and assume > > a deterministic behaviour in order to do so. In certain > > implementations that assumption is actually not correct. > > > > Although the IDR WG typically attempts to have a 'pratical' > > prespective on things, "theoretical" models are important in that they > > allow you to understand pratical behaviour. > > > > Let me put things in another way... even if i can't from the top of my > > head present you an example of what problems it causes, it doesn't > > mean that one can assert that it doesn't introduce new > > issues. i.e. lack of negative proof doesn't prove something. > > > > Pedro. From owner-idr@merit.edu Thu Jun 6 12:42:02 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19912 for ; Thu, 6 Jun 2002 12:42:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABAE1912BA; Thu, 6 Jun 2002 12:40:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C63E912B9; Thu, 6 Jun 2002 12:40: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 33393912AC for ; Thu, 6 Jun 2002 12:40:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28AB25DEB4; Thu, 6 Jun 2002 12:40:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with ESMTP id EFB555DDAB for ; Thu, 6 Jun 2002 12:40:48 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56GfCUL002688; Thu, 6 Jun 2002 12:41:12 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56Gejk69049; Thu, 6 Jun 2002 12:40:45 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56Gejjq62368057; Thu, 6 Jun 2002 12:40:45 -0400 (EDT) Message-ID: <3CFF908D.58DC1F16@research.bell-labs.com> Date: Thu, 06 Jun 2002 12:40:45 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Abarbanel, Benjamin" Cc: "'Gordon Wilfong'" , Enke Chen , idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <39469E08BD83D411A3D900204840EC5582271A@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Abarbanel, Benjamin" wrote: > > Sounds to me like all the proposals so far attempt to reduce the > probability of route oscillations, but do not control or stop it > totally. So I think another approach is warranted. > > Ben > not quite, the proposal by wilfong et. al. actually stops it totally and we can prove it. -anindya From owner-idr@merit.edu Thu Jun 6 18:44:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01516 for ; Thu, 6 Jun 2002 18:44:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF919912D8; Thu, 6 Jun 2002 16:45:39 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 809B7912DC; Thu, 6 Jun 2002 16:45:39 -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 4A50B912D8 for ; Thu, 6 Jun 2002 16:45:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FFC55DE02; Thu, 6 Jun 2002 16:45:33 -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 F24535DD9C for ; Thu, 6 Jun 2002 16:45:32 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56Kjem49771; Thu, 6 Jun 2002 13:45:40 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56Kjep87049; Thu, 6 Jun 2002 13:45:40 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 13:45:40 -0700 (PDT) Message-Id: <200206062045.g56Kjep87049@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: In-Reply-To: <39469E08BD83D411A3D900204840EC5582271F@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC5582271F@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Abarbanel, Benjamin writes: >>> What is being dampened is not the route but whether we use the MED >>> for this route in the BRSC calculations when we detect a route has >>> been oscillating. Once, the route exits its oscillation state MED >>> is automatically reapplied. >>> >>> General IBGP dampening can be done as was done in EBGP but for the problem >>> we have been exposed to, the MED dampening should suffice. >>> >>> Yes, we would need to keep track of the routes previous history in >>> order to know that it has entered oscillation state. This >>> mechanism can be described in detail in a draft. >>> While i would encorage you to describe the proposal in detail, your brief synopsis gives me the impression that you propose to ignore certain attributes on different members of the ibgp mesh. ibgp route decision mush be consistent enought to ensure that loops are not formed. I don't think you can gurantee that if different members of the mesh use different attributes. Pedro. From owner-idr@merit.edu Thu Jun 6 18:44:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01564 for ; Thu, 6 Jun 2002 18:44:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF508912DA; Thu, 6 Jun 2002 16:48:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71EB5912DC; Thu, 6 Jun 2002 16: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 A5FA0912DA for ; Thu, 6 Jun 2002 16:48:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B21075DEB3; Thu, 6 Jun 2002 16:48:34 -0400 (EDT) Delivered-To: idr@merit.edu Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with ESMTP id 51C6A5DD9C for ; Thu, 6 Jun 2002 16:48:34 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KmvUL005395; Thu, 6 Jun 2002 16:48:57 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56KmVo42784; Thu, 6 Jun 2002 16:48:31 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KmUjq63555044; Thu, 6 Jun 2002 16:48:30 -0400 (EDT) Message-ID: <3CFFCA9E.AE839554@research.bell-labs.com> Date: Thu, 06 Jun 2002 16:48:30 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Abarbanel, Benjamin" Cc: danny@tcb.net, idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <39469E08BD83D411A3D900204840EC55822721@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes, we are aware of this -- it turns out that there may be transient black hole routing while the system is converging, but once the system converges, everybody will agree on a single, stable set of routes. There is a proof that actually shows this. Of course, you can be concerned about black hole routing before the system converges, but then, in any system undergoing transition, there *will be* some black hole routing for short periods. -Anindya "Abarbanel, Benjamin" wrote: > > Basu: > I have a problem with your solution of advertising routes that are not > best routes to IBGP peers. This in itself can lead to black holes or routing > loops. > Even if we can keep the number of routes to a small group, I dont like the > idea > of sending suboptimal routes to a peer. > > Ben > > -----Original Message----- > From: Anindya Basu [mailto:basu@research.bell-labs.com] > Sent: Thursday, June 06, 2002 4:11 PM > To: danny@tcb.net > Cc: idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > > I am actually curious -- have any of you out there with access to real > routing tables applied any of these algorithms (that purport to send > extra routes) and seen how many extra routes are generated? Two > datapoints would be of interest: > (a) For what percentage of routing prefixes are extra routes generated? > (b) For those prefixes for which extra routes are generated, how many > extra routes (on an average) are generated per prefix? > This would provide some ideas about extra memory requirements. Maybe we > should actually have some numbers before completely dissing a perfectly > good solution. > -Anindya > > Danny McPherson wrote: > > > > > >not quite, the proposal by wilfong et. al. actually stops it totally > and > > > >we can prove it. > > > > > > I know it's been said before (and recently) but a reminder just in > > > case: scaling matters. > > > > Right! A full IBGP mesh with no heirarchy, or heck, putting the > > routes in an IGP -- would fix it as well, but please, lets not > > forget that the solution has to be deployable and the several > > vendors in my network today aren't exactly begging for more > > BGP paths. > > > > -danny From owner-idr@merit.edu Thu Jun 6 18:44:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01662 for ; Thu, 6 Jun 2002 18:44:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9BF2912C8; Thu, 6 Jun 2002 15:13:25 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7522B912C9; Thu, 6 Jun 2002 15:13:25 -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 D376A912C8 for ; Thu, 6 Jun 2002 15:13:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D946A5DEB3; Thu, 6 Jun 2002 15:13:18 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 770CF5DDC2 for ; Thu, 6 Jun 2002 15:13:18 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56JDOEF052912; Thu, 6 Jun 2002 15:13:24 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56JDIk81930; Thu, 6 Jun 2002 15:13:18 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56JDHjq46830459; Thu, 6 Jun 2002 15:13:17 -0400 (EDT) Message-ID: <3CFFB44D.F8D020BD@research.bell-labs.com> Date: Thu, 06 Jun 2002 15:13:17 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: idr@merit.edu Cc: f b shepherd , Benjamin.Abarbanel@Marconi.com, gtw@research.bell-labs.com, enke@redback.com Subject: I-BGP Oscillations References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have been following the responses to various proposals for eliminating I-BGP oscillations with some interest and it appears that there are roughly two main approaches. 1. Try to solve the problem using a solution that fixes the current manifestation of the problem, without changing the protocol too much. draft-walton and draft-chen fall in this category. The main advantage to both these solutions is that they do not involve major changes to the protocol and they have reasonably good scaling properties. On the other hand, such solutions may not address all possible manifestations of the oscillation problem, as evidenced by some of the counter examples that Gordon has suggested. One way to resolve this is to restrict the kind of router configurations that are permitted (as suggested by Chen, as well as Scudder, under the class of real configurations). This approach has two drawbacks: (1) It may make the configuration process too restrictive, i.e., disallow many configurations that may be safe. (2) Fixing the current manifestation of the problem with a solution that appears to make it go away may be risky. It could produce other problems that did not manifest themselves before, as well as not address the entire existing class of problems. Obviously, as newer problems manifest themselves, further and further revisions to the protocol need to be made. 2. The second approach is to actually analyze the protocol and figure out which feature(s) that are inherent in the protocol are causing oscillations. Then redesign the protocol in a manner that is provably correct under all circumstances. This approach obviously addresses the two drawbacks outlined above. draft-wilfong and Pedro have been arguing for such an approach (in my opinion). However, this approach has one distinct disadvantage --- as pointed out by many of you (notably, John Scudder and Ben Abarbanel), there are some scalability issues that need to be addressed. The proposal in draft-wilfong (as well as in draft-walton) advocate sending some extra information to suppress oscillations. However, it is not clear how much extra information may need to get sent out (especially in the case of draft-wilfong). Given the memory constraints for today's routers, it may be hard to store all these extra routes in memory. One way to address this issue would be to *only* send out extra routes when necessary. In other words, if an oscillation involving I-BGP routes is detected, extra information for only that route could be sent out. This way, routers behave normally as usual, and when a particular route (or set of routes) begin to flap, the extra information corresponding to those routes could be computed and sent out. Thus, extra storage is *only* required when something bad happens. Hopefully, this provides a reasonable solution to the scalability problem. Thanks, -Anindya From owner-idr@merit.edu Thu Jun 6 18:45:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01988 for ; Thu, 6 Jun 2002 18:45:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0366912D1; Thu, 6 Jun 2002 16:02:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DA06912D2; Thu, 6 Jun 2002 16:02:58 -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 90551912D1 for ; Thu, 6 Jun 2002 16:02:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 895E15DE02; Thu, 6 Jun 2002 16:02:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 118B45DD9C for ; Thu, 6 Jun 2002 16:02:30 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56K25W19519 for ; Thu, 6 Jun 2002 14:02:05 -0600 Message-Id: <200206062002.g56K25W19519@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 06 Jun 2002 14:02:05 -0600 Sender: owner-idr@merit.edu Precedence: bulk > >not quite, the proposal by wilfong et. al. actually stops it totally and > >we can prove it. > > I know it's been said before (and recently) but a reminder just in > case: scaling matters. Right! A full IBGP mesh with no heirarchy, or heck, putting the routes in an IGP -- would fix it as well, but please, lets not forget that the solution has to be deployable and the several vendors in my network today aren't exactly begging for more BGP paths. -danny From owner-idr@merit.edu Thu Jun 6 18:45:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02071 for ; Thu, 6 Jun 2002 18:45:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7768E912C2; Thu, 6 Jun 2002 14:44:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A5CB912C3; Thu, 6 Jun 2002 14:44: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 0A1C7912C2 for ; Thu, 6 Jun 2002 14:44:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1B4B5DD9C; Thu, 6 Jun 2002 14:44:08 -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 9DD615DEB3 for ; Thu, 6 Jun 2002 14:44:08 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56IiGm42045; Thu, 6 Jun 2002 11:44:16 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56IiGr86811; Thu, 6 Jun 2002 11:44:16 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) Message-Id: <200206061844.g56IiGr86811@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: enke@redback.com Cc: idr@merit.edu Subject: rr-oscillation-reduce X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Enke, A few questions/comments on your proposal... The gist of it is to advertise 'the best external' (i.e. route from rr-clients) to the rest of the mesh when the best path is internal (i.e. received from a ibgp mesh router). 1) Why do you limit this procedure to RRs/Confeds... ? 2) Advertising the 'best external' route as always had the issue of traffic loops (i believe the reason it hasn't been implemented as specified in 1771 originally). You don't seem to address this in your draft... do you believe it is not relevant... or is there some other solution to this problem... To be more specific, if you have rtrs A, B, such that B has the best path at t0, and A a valid external path, when at t1 B's external path gets withrawn, traffic is almost guaranteed to loop until B's advertisement reaches A. This can be potentially exacerbated by mechanisms such as min advertisement interval. Whereas today such traffic would be blackholed by B... while it is true that current routers are not as susceptible to rollover and die when presented with looping traffic as opposed to software forwarding based boxes of 5+ years ago it is likely that the resulting link congestion is still a relevant factor.... comments ? Pedro. From owner-idr@merit.edu Thu Jun 6 18:45:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02102 for ; Thu, 6 Jun 2002 18:45:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 764EE912D2; Thu, 6 Jun 2002 16:11:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D83D912D3; Thu, 6 Jun 2002 16:11: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 E0FE6912D2 for ; Thu, 6 Jun 2002 16:11:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0C1D5DE02; Thu, 6 Jun 2002 16:11:11 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id B498F5DD9C for ; Thu, 6 Jun 2002 16:11:11 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KBJEF053372; Thu, 6 Jun 2002 16:11:19 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56KBCo39332; Thu, 6 Jun 2002 16:11:13 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KBCjq62055109; Thu, 6 Jun 2002 16:11:12 -0400 (EDT) Message-ID: <3CFFC1E0.49EEF147@research.bell-labs.com> Date: Thu, 06 Jun 2002 16:11:12 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: danny@tcb.net Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <200206062002.g56K25W19519@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am actually curious -- have any of you out there with access to real routing tables applied any of these algorithms (that purport to send extra routes) and seen how many extra routes are generated? Two datapoints would be of interest: (a) For what percentage of routing prefixes are extra routes generated? (b) For those prefixes for which extra routes are generated, how many extra routes (on an average) are generated per prefix? This would provide some ideas about extra memory requirements. Maybe we should actually have some numbers before completely dissing a perfectly good solution. -Anindya Danny McPherson wrote: > > > >not quite, the proposal by wilfong et. al. actually stops it totally and > > >we can prove it. > > > > I know it's been said before (and recently) but a reminder just in > > case: scaling matters. > > Right! A full IBGP mesh with no heirarchy, or heck, putting the > routes in an IGP -- would fix it as well, but please, lets not > forget that the solution has to be deployable and the several > vendors in my network today aren't exactly begging for more > BGP paths. > > -danny From owner-idr@merit.edu Thu Jun 6 18:46:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02124 for ; Thu, 6 Jun 2002 18:45:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A175912CC; Thu, 6 Jun 2002 15:31:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 314CF912D8; Thu, 6 Jun 2002 15:31: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 3DFF6912CC for ; Thu, 6 Jun 2002 15:31:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 405625DEA6; Thu, 6 Jun 2002 15:31:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B3C6B5DD9C for ; Thu, 6 Jun 2002 15:31:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10515; Thu, 6 Jun 2002 15:31:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22568; Thu, 6 Jun 2002 15:31:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 15:31:46 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , Anindya Basu Cc: idr@merit.edu Subject: RE: I-BGP Oscillations Date: Thu, 6 Jun 2002 15:31:43 -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 Pedro: Why not, IBGP Dampening is what I have been thinking aboute since this problem was first exposed to IETF. I have started a draft but never finished it, got talked out of it by one other gentlemen who wrote the original draft on route oscillations. Maybe its time to get serious on this. Ben -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 3:28 PM To: Anindya Basu Cc: idr@merit.edu Subject: I-BGP Oscillations Anindya Basu writes: > One way to address this issue would be to *only* send out extra > routes when necessary. In other words, if an oscillation involving > I-BGP routes is detected, extra information for only that route > could be sent out. If we come up with a decent detection mechanism it would be so much simpler just to reduce the rate of oscilation. Regardless a decent detection mechanism needs to be proposed... 'Decency' criteria includes state that one needs to hold, etc... In other words, the ammount of state required to detect such events shouldn't be greater than the state necessary to advertise the best external MED winner paths from all mesh participants. Note that the answer 'ibgp dampening' that is certain to pop up in peoples minds by association is a bit misleading. When you start thinking about it is quite a different beast... it is not suficient to say that you just apply the procedures applied to ebgp dampening since the problem is quite different. Pedro. From owner-idr@merit.edu Thu Jun 6 18:46:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02150 for ; Thu, 6 Jun 2002 18:46:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AAD8912B5; Thu, 6 Jun 2002 13:34:31 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3656912D7; Thu, 6 Jun 2002 13:34:30 -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 67DA2912B5 for ; Thu, 6 Jun 2002 13:33:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E7FA5DDF4; Thu, 6 Jun 2002 13:33:04 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id ADCEB5DDAB for ; Thu, 6 Jun 2002 13:33:03 -0400 (EDT) Received: from [171.69.182.155] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA17513 for ; Thu, 6 Jun 2002 13:33:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <3CFF908D.58DC1F16@research.bell-labs.com> References: <39469E08BD83D411A3D900204840EC5582271A@vie-msgusr-01.dc.fore.com> <3CFF908D.58DC1F16@research.bell-labs.com> Date: Thu, 6 Jun 2002 13:33:03 -0400 To: idr@merit.edu From: "John G. Scudder" Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 12:40 PM -0400 6/6/02, Anindya Basu wrote: >"Abarbanel, Benjamin" wrote: > > Sounds to me like all the proposals so far attempt to reduce the >> probability of route oscillations, but do not control or stop it > > totally. So I think another approach is warranted. > >not quite, the proposal by wilfong et. al. actually stops it totally and >we can prove it. I know it's been said before (and recently) but a reminder just in case: scaling matters. Regards, --John From owner-idr@merit.edu Thu Jun 6 18:46:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02160 for ; Thu, 6 Jun 2002 18:46:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06FFF912CD; Thu, 6 Jun 2002 15:35:17 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2780912CE; Thu, 6 Jun 2002 15:35:16 -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 8E176912CD for ; Thu, 6 Jun 2002 15:35:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39D065DDF4; Thu, 6 Jun 2002 15:35:09 -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 DCB415DDC2 for ; Thu, 6 Jun 2002 15:35:08 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56JZGm45132; Thu, 6 Jun 2002 12:35:16 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56JZGa86921; Thu, 6 Jun 2002 12:35:16 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 12:35:16 -0700 (PDT) Message-Id: <200206061935.g56JZGa86921@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: In-Reply-To: <39469E08BD83D411A3D900204840EC5582271D@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC5582271D@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Abarbanel, Benjamin writes: > I have a third solution to propose to the list. Why not dampen the > MED from the BGP Route Selection Criteria during conditions when a > route is oscillating As i mentioned in my previous e-mail to the list, the devil is in the details... Someone needs to specify the behaviour and do an analysis to see if it is feasible... without some detailed analysis i don't think it is possible to know if that is a feasible solution. Keep in mind the following scenario: You have N peering points with AS 1 in your ibgp mesh. Each of those N points receives a route with an MED. When the best external route changes, all of those N peering points advertise their external route to the mesh and then withraw it as they converge to the second best MED. In this case are you going to hold dampening history for all these paths ? Are you going to apply penalties to individual paths (as in the ebgp case) or routes... don't forget that you need to dampen things in a coverged state (i.e. no routing loops in the mesh). Pedro. From owner-idr@merit.edu Thu Jun 6 18:46:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02175 for ; Thu, 6 Jun 2002 18:46:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F8BE912BE; Thu, 6 Jun 2002 14:24:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14EB5912C0; Thu, 6 Jun 2002 14:24: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 CA745912BE for ; Thu, 6 Jun 2002 14:24:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C89915DEB3; Thu, 6 Jun 2002 14:24:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 661435DD9C for ; Thu, 6 Jun 2002 14:24:39 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56IOkEF052517; Thu, 6 Jun 2002 14:24:46 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56IOdk78190; Thu, 6 Jun 2002 14:24:40 -0400 (EDT) Received: from jessie.research.bell-labs.com (localhost [127.0.0.1]) by jessie.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56IOc0J016047; Thu, 6 Jun 2002 14:24:38 -0400 (EDT) Message-Id: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> To: idr@merit.edu, Benjamin.Abarbanel@Marconi.com Cc: basu@research.bell-labs.com, gtw@research.bell-labs.com, enke@redback.com Date: Thu, 06 Jun 2002 14:24:38 -0400 From: f b shepherd Sender: owner-idr@merit.edu Precedence: bulk Content-Length: 1650 Anindya: The solution in draft-wilfong-ibgp-oscillations-00.txt is to merely dump all the routes that were not resolved by BGP Route Selection Criteria (BRSC) to all its peers, is a major disaster to the network. We are already pushing the limits of capacities in routers with 200,000 routes, now to solve a potential route oscillations problem, you dump all unresolved routes to all the peers. What will that do to the routing tables for routers not able to handle such a massive increase of routes? ==> Correct, as you put it, we dump a lot of extra routes. This was the only approach we could see at that time to a) allow MED to maintain some semblance of its intended meaning and b) eliminate any route oscillations (and nondeterminism in the adopted routing). In general, we have not peformed any analysis on the actual number of routes which would be passed. Presumably, quite often it could still only be the best route passed on by a RR. What if some routers are situated in the topology such that they will never get into route oscillations, why should they see a ton of useless routes coming at them from routers that are potentially prone to form or pass oscillating routes? ==> Good point. I also thought, one fundamental rule of BGP is to "Only propagate BGP routes that the router actually uses in its forwarding plain, meaning the route made it to its local-RIB". Are you saying we should pass BRSC unresolved routes to the Local-RIB with your proposal since you are propagating them to the peers? ==> It seems to me impossible to adhere to only propogating best-path and yet to eliminate all oscillations which were considering (or maybe even to only eleiminate types I and II churn). At least not without some other radical change to the protocol. As you mentioned above, the impact on router capacities may make the extra route dumping infeasible. As John also said, scalability is a key issue. As I had previously said - take our work then as hinting that a "total solution" to oscillations may actually require such a larger collection of passed messages. Regards - and apologies for my indentations. Bruce Ben From owner-idr@merit.edu Thu Jun 6 18:46:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02184 for ; Thu, 6 Jun 2002 18:46:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00F09912B8; Thu, 6 Jun 2002 13:57:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC9DE912B9; Thu, 6 Jun 2002 13:57:03 -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 84331912B8 for ; Thu, 6 Jun 2002 13:57:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88E8F5DEBE; Thu, 6 Jun 2002 13:56:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0B52F5DEB4 for ; Thu, 6 Jun 2002 13:56:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28815; Thu, 6 Jun 2002 13:57:02 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21975; Thu, 6 Jun 2002 13:57:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 13:57:03 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271B@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Anindya Basu'" , "Abarbanel, Benjamin" Cc: "'Gordon Wilfong'" , Enke Chen , idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 6 Jun 2002 13:57:00 -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 Anindya: The solution in draft-wilfong-ibgp-oscillations-00.txt is to merely dump all the routes that were not resolved by BGP Route Selection Criteria (BRSC) to all its peers, is a major disaster to the network. We are already pushing the limits of capacities in routers with 200,000 routes, now to solve a potential route oscillations problem, you dump all unresolved routes to all the peers. What will that do to the routing tables for routers not able to handle such a massive increase of routes? What if some routers are situated in the topology such that they will never get into route oscillations, why should they see a ton of useless routes coming at them from routers that are potentially prone to form or pass oscillating routes? I also thought, one fundamental rule of BGP is to "Only propagate BGP routes that the router actually uses in its forwarding plain, meaning the route made it to its local-RIB". Are you saying we should pass BRSC unresolved routes to the Local-RIB with your proposal since you are propagating them to the peers? Ben -----Original Message----- From: Anindya Basu [mailto:basu@research.bell-labs.com] Sent: Thursday, June 06, 2002 12:41 PM To: Abarbanel, Benjamin Cc: 'Gordon Wilfong'; Enke Chen; idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt "Abarbanel, Benjamin" wrote: > > Sounds to me like all the proposals so far attempt to reduce the > probability of route oscillations, but do not control or stop it > totally. So I think another approach is warranted. > > Ben > not quite, the proposal by wilfong et. al. actually stops it totally and we can prove it. -anindya From owner-idr@merit.edu Thu Jun 6 18:46:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02214 for ; Thu, 6 Jun 2002 18:46:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F504912CA; Thu, 6 Jun 2002 15:27:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C9CC912CB; Thu, 6 Jun 2002 15:27: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 E8727912CA for ; Thu, 6 Jun 2002 15:27:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC40C5DEA6; Thu, 6 Jun 2002 15:27:38 -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 69A7F5DDC2 for ; Thu, 6 Jun 2002 15:27:38 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56JRkm44637; Thu, 6 Jun 2002 12:27:46 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56JRkf86900; Thu, 6 Jun 2002 12:27:46 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 12:27:46 -0700 (PDT) Message-Id: <200206061927.g56JRkf86900@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Anindya Basu Cc: idr@merit.edu Subject: I-BGP Oscillations In-Reply-To: <3CFFB44D.F8D020BD@research.bell-labs.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <3CFFB44D.F8D020BD@research.bell-labs.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Anindya Basu writes: > One way to address this issue would be to *only* send out extra > routes when necessary. In other words, if an oscillation involving > I-BGP routes is detected, extra information for only that route > could be sent out. If we come up with a decent detection mechanism it would be so much simpler just to reduce the rate of oscilation. Regardless a decent detection mechanism needs to be proposed... 'Decency' criteria includes state that one needs to hold, etc... In other words, the ammount of state required to detect such events shouldn't be greater than the state necessary to advertise the best external MED winner paths from all mesh participants. Note that the answer 'ibgp dampening' that is certain to pop up in peoples minds by association is a bit misleading. When you start thinking about it is quite a different beast... it is not suficient to say that you just apply the procedures applied to ebgp dampening since the problem is quite different. Pedro. From owner-idr@merit.edu Thu Jun 6 18:46:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02284 for ; Thu, 6 Jun 2002 18:46:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAF77912D6; Thu, 6 Jun 2002 16:43:27 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B226D912D8; Thu, 6 Jun 2002 16:43:27 -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 D7ED8912D6 for ; Thu, 6 Jun 2002 16:43:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E49FB5DE02; Thu, 6 Jun 2002 16:43:20 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 705865DD9C for ; Thu, 6 Jun 2002 16:43:20 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA18499; Thu, 6 Jun 2002 16:43:25 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09456; Thu, 6 Jun 2002 16:43:22 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 16:43:22 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822721@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Anindya Basu'" , danny@tcb.net Cc: idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 6 Jun 2002 16:43:21 -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 Basu: I have a problem with your solution of advertising routes that are not best routes to IBGP peers. This in itself can lead to black holes or routing loops. Even if we can keep the number of routes to a small group, I dont like the idea of sending suboptimal routes to a peer. Ben -----Original Message----- From: Anindya Basu [mailto:basu@research.bell-labs.com] Sent: Thursday, June 06, 2002 4:11 PM To: danny@tcb.net Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt I am actually curious -- have any of you out there with access to real routing tables applied any of these algorithms (that purport to send extra routes) and seen how many extra routes are generated? Two datapoints would be of interest: (a) For what percentage of routing prefixes are extra routes generated? (b) For those prefixes for which extra routes are generated, how many extra routes (on an average) are generated per prefix? This would provide some ideas about extra memory requirements. Maybe we should actually have some numbers before completely dissing a perfectly good solution. -Anindya Danny McPherson wrote: > > > >not quite, the proposal by wilfong et. al. actually stops it totally and > > >we can prove it. > > > > I know it's been said before (and recently) but a reminder just in > > case: scaling matters. > > Right! A full IBGP mesh with no heirarchy, or heck, putting the > routes in an IGP -- would fix it as well, but please, lets not > forget that the solution has to be deployable and the several > vendors in my network today aren't exactly begging for more > BGP paths. > > -danny From owner-idr@merit.edu Thu Jun 6 18:46:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02276 for ; Thu, 6 Jun 2002 18:46:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50C6C912BF; Thu, 6 Jun 2002 14:16:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22679912BE; Thu, 6 Jun 2002 14:16: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 0700E912BF for ; Thu, 6 Jun 2002 14:16:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BA945DEB3; Thu, 6 Jun 2002 14:16:07 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BCBD15DD9C for ; Thu, 6 Jun 2002 14:16:06 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 14:16:14 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7A8@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: AS_CONFED_SET Date: Thu, 6 Jun 2002 14:16:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk How is an AS_CONFED_SET displayed in the show ip bgp command output? thnx From owner-idr@merit.edu Thu Jun 6 18:46:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02306 for ; Thu, 6 Jun 2002 18:46:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 840B4912E1; Thu, 6 Jun 2002 17:27:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59359912E2; Thu, 6 Jun 2002 17:27:05 -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 2D6F0912E1 for ; Thu, 6 Jun 2002 17:27:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CF145DDA0; Thu, 6 Jun 2002 17:26:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 084B35DD9C for ; Thu, 6 Jun 2002 17:26:59 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 17:27:06 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7AD@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'Gargi Nalawade'" Cc: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: RE: AS_CONFED_SET Date: Thu, 6 Jun 2002 17:26:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk Thanks! So will a _ in a regexp match it? I'll just try anyway. Halabi's book does not mention it (then again he does not mention the \ -- which we might need to match the [ and ] if the _ does not work. -----Original Message----- From: Gargi Nalawade [mailto:gargi@cisco.com] Sent: Thursday, June 06, 2002 5:22 PM To: Natale, Jonathan Cc: 'idr@merit.edu'; 'isp-bgp@isp-bgp.com'; 'isp-routing@isp-routing.com' Subject: Re: AS_CONFED_SET [] -gargi "Natale, Jonathan" wrote: > > How is an AS_CONFED_SET displayed in the show ip bgp command output? > > thnx From owner-idr@merit.edu Thu Jun 6 18:46:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02377 for ; Thu, 6 Jun 2002 18:46:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18C72912D3; Thu, 6 Jun 2002 16:14:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA2BF912D4; Thu, 6 Jun 2002 16:14: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 CCD5C912D3 for ; Thu, 6 Jun 2002 16:14:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D36A65DE02; Thu, 6 Jun 2002 16:14:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (unknown [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 479475DD9C for ; Thu, 6 Jun 2002 16:14:09 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g56KEF596980; Thu, 6 Jun 2002 16:14:15 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g56KEC996969; Thu, 6 Jun 2002 16:14:12 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g56KECG02361; Thu, 6 Jun 2002 16:14:12 -0400 (EDT) Date: Thu, 6 Jun 2002 16:14:12 -0400 From: Jeffrey Haas To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: your mail Message-ID: <20020606161412.C27447@nexthop.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <200206061855.g56Itda86837@roque-bsd.juniper.net> <20020606150051.B27447@nexthop.com> <200206061918.g56JIUM86879@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206061918.g56JIUM86879@roque-bsd.juniper.net>; from roque@juniper.net on Thu, Jun 06, 2002 at 12:18:30PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jun 06, 2002 at 12:18:30PM -0700, Pedro Roque Marques wrote: > Can you elaborate please... i don't quite get the scenario where > different behaviour is introduced. The simplest one I can think of is that when "always-compare-med" is on, if you have some ISP that is injecting better MEDs than yours, it removes your routes from being used even when they should be used as the closest exit router. Example: Ra Rb *-----* Routers a and b are AS-BR's and iBGP between each other. ISPs 1 and 2 peer at Ra and Rb respectively. Some destination, D is injected by both. ISP-1 injects it with a MED of 2 and ISP-2 injects it with an MED of 1. With always-compare-med, if the LocalPref, AS_Path length, and origin are the same, then ISP-2's route will win in both routers because ISP-1's route is suppressed. Without always-compare-med, each ISP wins at the their respective BR. If you add a Rc that peers with Ra, Rb (fully-meshed), then: With always-compare-med: ISP-1's D is suppressed and never gets used. Without always-compare-med: Rc has the choice of ISP-1's and ISP-2's D and will continue through route selection, choosing IGP distance or routerid. Without taking this to the more complicated cases, the argument that the operational community makes is that "always-compare-med" is a form of denial of service. Of course, I don't speak for the operational community - I haven't had a login on a router that actually affects customer's routing for a few years. :-) > Only for prefixes that they both announce... i don't have access to > meaningful data myself but a point made several times in this > discussion is that the number of prefixes which end up with a decision > with same length as-paths from different neighbor ASes where between > the same AS you pick best MED and between different AS you pick best > IGP, etc... is said to be quite small. For particular topologies. It is possible that many ISPs just don't implement topologies that are affected by these issues. > Pedro. -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Thu Jun 6 19:56:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02190 for ; Thu, 6 Jun 2002 18:46:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B6C8912DF; Thu, 6 Jun 2002 17:22:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64A93912E0; Thu, 6 Jun 2002 17:22:05 -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 6D4EE912DF for ; Thu, 6 Jun 2002 17:22:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D5335DDA0; Thu, 6 Jun 2002 17:21:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by segue.merit.edu (Postfix) with ESMTP id 00C6D5DD9C for ; Thu, 6 Jun 2002 17:21:58 -0400 (EDT) Received: from gargi-u5.cisco.com (gargi-u5.cisco.com [128.107.162.118]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g56LM4PI005021; Thu, 6 Jun 2002 14:22:04 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by gargi-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA24987; Thu, 6 Jun 2002 14:22:04 -0700 (PDT) Message-ID: <3CFFD27C.F5BCC2DF@cisco.com> Date: Thu, 06 Jun 2002 14:22:04 -0700 From: Gargi Nalawade X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Natale, Jonathan" Cc: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: Re: AS_CONFED_SET References: <1117F7D44159934FB116E36F4ABF221B020AF7A8@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit [] -gargi "Natale, Jonathan" wrote: > > How is an AS_CONFED_SET displayed in the show ip bgp command output? > > thnx From owner-idr@merit.edu Thu Jun 6 19:56:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02242 for ; Thu, 6 Jun 2002 18:46:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82E3C912D9; Thu, 6 Jun 2002 16:46:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 481D0912DD; Thu, 6 Jun 2002 16:46:22 -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 7997B912D9 for ; Thu, 6 Jun 2002 16:46:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85E2F5DE02; Thu, 6 Jun 2002 16:46:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 59EA85DD9C for ; Thu, 6 Jun 2002 16:46:12 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KkKEF053665; Thu, 6 Jun 2002 16:46:20 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56KkDo42521; Thu, 6 Jun 2002 16:46:13 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KkDjq57842658; Thu, 6 Jun 2002 16:46:13 -0400 (EDT) Message-ID: <3CFFCA15.8878F3BF@research.bell-labs.com> Date: Thu, 06 Jun 2002 16:46:13 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: danny@tcb.net Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <200206062042.g56KgT520524@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit With all due respect, I don't think that this list is the right forum for ad-hominem attacks! :-) (at least speaking as someone with a PhD, that you so deride).... Enough said. -Anindya Danny McPherson wrote: > Generally speaking, it doesn't take a PHD or fancy algorithm > to figure out several of the proporals won't help my routers > scale any better. > > -danny From owner-idr@merit.edu Thu Jun 6 19:56:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02212 for ; Thu, 6 Jun 2002 18:46:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A74E912DD; Thu, 6 Jun 2002 17:59:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FDFF912E4; Thu, 6 Jun 2002 17:59:57 -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 3065B912DD for ; Thu, 6 Jun 2002 17:59:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 371065DDC2; Thu, 6 Jun 2002 17:59:51 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id B26375DD9C for ; Thu, 6 Jun 2002 17:59:50 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56LxQJ30727 for ; Thu, 6 Jun 2002 15:59:26 -0600 Message-Id: <200206062159.g56LxQJ30727@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 06 Jun 2002 15:59:26 -0600 Sender: owner-idr@merit.edu Precedence: bulk > >> Speaking as a SP (today), I'll gladly provide BGP table access to > >> anyone interested in doing this. > > Or get any number of them from archive.routeviews.org. Actually, I was speaking more along the lines of a full analysis, where they'd get all the paths from all the EBGP-speaking routers in my AS, and given the routing topology, flag where issues will/may occur and determine the impact of a given proposal. (Then I could use the code for a few other things I need to do :-) -danny From owner-idr@merit.edu Thu Jun 6 19:56:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02197 for ; Thu, 6 Jun 2002 18:46:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9B8E912D5; Thu, 6 Jun 2002 16:42:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B0C7912D6; Thu, 6 Jun 2002 16:42: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 91A84912D5 for ; Thu, 6 Jun 2002 16:42:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E6885DE02; Thu, 6 Jun 2002 16:42:53 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 245955DD9C for ; Thu, 6 Jun 2002 16:42:53 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56KgT520524 for ; Thu, 6 Jun 2002 14:42:29 -0600 Message-Id: <200206062042.g56KgT520524@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 06 Jun 2002 14:42:29 -0600 Sender: owner-idr@merit.edu Precedence: bulk > I am actually curious -- have any of you out there with access to real > routing tables applied any of these algorithms (that purport to send > extra routes) and seen how many extra routes are generated? Two > datapoints would be of interest: > (a) For what percentage of routing prefixes are extra routes generated? > (b) For those prefixes for which extra routes are generated, how many > extra routes (on an average) are generated per prefix? > This would provide some ideas about extra memory requirements. Maybe we > should actually have some numbers before completely dissing a perfectly > good solution. Speaking as a SP (today), I'll gladly provide BGP table access to anyone interested in doing this. Generally speaking, it doesn't take a PHD or fancy algorithm to figure out several of the proporals won't help my routers scale any better. -danny From owner-idr@merit.edu Thu Jun 6 19:56:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02307 for ; Thu, 6 Jun 2002 18:46:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF548912CE; Thu, 6 Jun 2002 15:37:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0A07912CF; Thu, 6 Jun 2002 15:37: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 723F1912CE for ; Thu, 6 Jun 2002 15:37:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D0535DDF4; Thu, 6 Jun 2002 15:37:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 4E1775DDC2 for ; Thu, 6 Jun 2002 15:37:09 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56JbGEF053099; Thu, 6 Jun 2002 15:37:16 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56Jb9o36013; Thu, 6 Jun 2002 15:37:10 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56Jb9jq61961518; Thu, 6 Jun 2002 15:37:09 -0400 (EDT) Message-ID: <3CFFB9E5.5398E907@research.bell-labs.com> Date: Thu, 06 Jun 2002 15:37:09 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: I-BGP Oscillations References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <3CFFB44D.F8D020BD@research.bell-labs.com> <200206061927.g56JRkf86900@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 'Decency' criteria includes state that one needs to hold, etc... > > In other words, the ammount of state required to detect such events > shouldn't be greater than the state necessary to advertise the best > external MED winner paths from all mesh participants. > > Note that the answer 'ibgp dampening' that is certain to pop up in > peoples minds by association is a bit misleading. When you start > thinking about it is quite a different beast... it is not suficient to > say that you just apply the procedures applied to ebgp dampening since > the problem is quite different. could you elucidate further and explain how detection of the problem is different for i-bgp and e-bgp? also, i was not exactly suggesting a dampening mechanism (as they are used today). i was arguing for a mechanism which would be triggered whenever frequent announcements followed by withdrawals of the same i-bgp route is observed. this mechanism would then start sending out extra routes. -anindya From owner-idr@merit.edu Thu Jun 6 19:56:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02172 for ; Thu, 6 Jun 2002 18:46:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43DF4912BB; Thu, 6 Jun 2002 13:57:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4E7C912B7; Thu, 6 Jun 2002 13:57:03 -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 D3AE6912B7 for ; Thu, 6 Jun 2002 13:57:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D41955DEBE; Thu, 6 Jun 2002 13:56:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 90E9D5DEB4 for ; Thu, 6 Jun 2002 13:56:56 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 13:57:04 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7A7@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: RE: bgp pruning Date: Thu, 6 Jun 2002 13:57:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA02172 Given the following config: DUT-------r2 l         l l         l l         l r3--------r4   All routers are in different AS's.  The AS # is the router #.  r3 showed that the DUT was sending the routes that originated from r3 with an AS path of 3 4 2 1 (which is the correct AS path).  The expected behavior is for the DUT to not send these routes since they will be denied by r3 anyway as part of the BGP pruning process; this is what a major vendor does (prunes on the output as well). But the RFC1771 does not require that these routes not be sent (it does require that they be pruned at the input of r3).  It seems to me that it IS better to do it the way the major vendor does it (prune at input and output) in order to save BW and processing.   Why does RFC1771/the 17th draft not specify output pruning (or does it)?    Can/should this be added?   What does that other major vendor do?   How am I doing on my political correctness?   Thank you.   From owner-idr@merit.edu Thu Jun 6 19:56:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01603 for ; Thu, 6 Jun 2002 18:44:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8726912C4; Thu, 6 Jun 2002 15:00:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71BDA912C6; Thu, 6 Jun 2002 15:00:56 -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 6603C912C4 for ; Thu, 6 Jun 2002 15:00:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A0635DDAC; Thu, 6 Jun 2002 15:00:50 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (unknown [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 152325DD9C for ; Thu, 6 Jun 2002 15:00:50 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g56J0tW92992; Thu, 6 Jun 2002 15:00:55 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g56J0p992980; Thu, 6 Jun 2002 15:00:51 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g56J0pp29056; Thu, 6 Jun 2002 15:00:51 -0400 (EDT) Date: Thu, 6 Jun 2002 15:00:51 -0400 From: Jeffrey Haas To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: your mail Message-ID: <20020606150051.B27447@nexthop.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <200206061855.g56Itda86837@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206061855.g56Itda86837@roque-bsd.juniper.net>; from roque@juniper.net on Thu, Jun 06, 2002 at 11:55:39AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jun 06, 2002 at 11:55:39AM -0700, Pedro Roque Marques wrote: > One possible solution is to mandate 'always-compare-med' behaviour > which will make paths have a global ordering. I remember there was > strong reaction against this from the operational folks but i'm not > quite sure what the arguments where (would apreciate if somebody could > refresh my memory). With the current behavior, a given AS may inject backup paths to their upstream and have the expected behavior happen so long as it gets to the MED portion of tie-breaking: the routes with the worse meds are suppressed. With always-compare-med, all AS peers must adhere to a common policy of what MEDs they will use for a given prefix. While theoretically possible, making more than one ISP agree about anything is hard to scale. :-) > Or we can attempt to specify a different attribute/mechanism that > achieves the desired effects. If I recall previous discussions, the amount of state that would need to be flooded throughout the AS was only a little less than flooding the relevant full routing instances. > Pedro. -- Jeff Haas NextHop Technologies From owner-idr@merit.edu Thu Jun 6 19:56:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02355 for ; Thu, 6 Jun 2002 18:46:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11AC8912C3; Thu, 6 Jun 2002 14:55:38 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3251912C4; Thu, 6 Jun 2002 14:55: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 A53EB912C3 for ; Thu, 6 Jun 2002 14:55:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABA1F5DEB3; Thu, 6 Jun 2002 14:55:31 -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 531AA5DD9C for ; Thu, 6 Jun 2002 14:55:31 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56Itdm42762; Thu, 6 Jun 2002 11:55:39 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56Itda86837; Thu, 6 Jun 2002 11:55:39 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 11:55:39 -0700 (PDT) Message-Id: <200206061855.g56Itda86837@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: f b shepherd Cc: idr@merit.edu In-Reply-To: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit f b shepherd writes: > ==> It seems to me impossible to adhere to only propogating > best-path and yet to eliminate all oscillations which were > considering (or maybe even to only eleiminate types I and II churn). > At least not without some other radical change to the protocol. There is a simple answer, which is to address the current MED behaviour. MEDs as current specified make it so that there isn't possible to establish a global ordering between BGP paths. The protocol when originally designed implicit required such property. Given a global ordering of paths within an ibgp mesh no persistent osciallation will occur and the protocol as originally specified will be stable. In order to achieve this, of course, one needs to encounter an solution to the problem that MEDs are supposed to solve. One possible solution is to mandate 'always-compare-med' behaviour which will make paths have a global ordering. I remember there was strong reaction against this from the operational folks but i'm not quite sure what the arguments where (would apreciate if somebody could refresh my memory). Or we can attempt to specify a different attribute/mechanism that achieves the desired effects. Pedro. From owner-idr@merit.edu Thu Jun 6 19:56:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02151 for ; Thu, 6 Jun 2002 18:46:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9E97912E2; Thu, 6 Jun 2002 17:28:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB460912E3; Thu, 6 Jun 2002 17:28:49 -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 8B08F912E2 for ; Thu, 6 Jun 2002 17:28:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BB885DDAD; Thu, 6 Jun 2002 17:28:43 -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 49F195DD9C for ; Thu, 6 Jun 2002 17:28:43 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56LSpm52714; Thu, 6 Jun 2002 14:28:51 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56LSpG87141; Thu, 6 Jun 2002 14:28:51 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 14:28:51 -0700 (PDT) Message-Id: <200206062128.g56LSpG87141@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: In-Reply-To: <39469E08BD83D411A3D900204840EC55822722@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC55822722@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Abarbanel, Benjamin writes: my text: > ibgp route decision mush be consistent enought to ensure that loops > are not formed. I don't think you can gurantee that if different > members of the mesh use different attributes. >>> This solution is no different than an operator going to a router >>> with an oscillating route and deconfiguring the MED from it, while >>> keeping the other routers unchanged. When you 'unconfigure MED' from a route you basically strip that attribute at the border router that receives it. Thus no inconsistencies exist since everybody sees the same set of attributes. If done properly this manual condifuration never causes inconsistent behaviour, since it affects what all routers see in terms of attributes for the same path. >>> >>> BTW, when all the routers are equiped with the MED dampening, they >>> will all reach the same conclusion with the state of the MED and they will >>> all be consistent. >>> Different members of an ibgp mesh see different routes and different events... the number of flaps in a route is different. Most mesh members have a different prespective and the potential to reach different conclusions. It is probably best for me to refrain from commenting further until i see a concrete proposal which can then be analyzed. I just wanted to caution you in advance to a set of issues that imho should be addressed by such proposal. Pedro. From owner-idr@merit.edu Thu Jun 6 19:56:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02341 for ; Thu, 6 Jun 2002 18:46:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B862912D4; Thu, 6 Jun 2002 16:39:24 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB184912D5; Thu, 6 Jun 2002 16:39:23 -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 CDF43912D4 for ; Thu, 6 Jun 2002 16:39:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3EC45DE2E; Thu, 6 Jun 2002 16:39:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 58E465DD9C for ; Thu, 6 Jun 2002 16:39:17 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56Kcrw20301 for ; Thu, 6 Jun 2002 14:38:53 -0600 Message-Id: <200206062038.g56Kcrw20301@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Date: Thu, 06 Jun 2002 14:38:53 -0600 Sender: owner-idr@merit.edu Precedence: bulk > One possible solution is to mandate 'always-compare-med' behaviour > which will make paths have a global ordering. I remember there was > strong reaction against this from the operational folks but i'm not > quite sure what the arguments where (would apreciate if somebody could > refresh my memory). Correct me if I'm wrong -- but the primary use of MEDs is for a BGP speaker to convey the optimal entry point for a given destination to a peer AS. That is, for one AS to associate MEDs with given reachabilty based on some policy internally consistent within the AS. Typically, the MED values are derived from IGP metrics associated with BGP NEXT_HOPs, thereby reflecting internal route selection preference in the process. Now, beyond that fact that MEDs are largely broken in general in the Internet, mostly as a result of aggregation... The issues with comparing MEDs between different ASes is that MED values are derived from some policy defined and contained internal to the peer network. Used to be, comparing MEDs between a network that ran IS-IS and a network that ran OSPF would result in the network running IS-IS receiving a much larger amount of traffic, simply because the IS-IS metric space was limited to 6 bits, and the resulting IGP metric-derived BGP MED from the AS were lower values. Though the IS-IS metric space isn't so much of an issue today, basing BGP path selection on MED values received from different ASes, probabilistically (sp?) derived from potentially significantly different policies, is certainly a BAD idea. In marketing speak, MEDs intend to turn hot potato routing into cold potato routing but end up with mashed potato routing. -danny From owner-idr@merit.edu Thu Jun 6 19:56:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02207 for ; Thu, 6 Jun 2002 18:46:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A758912CF; Thu, 6 Jun 2002 15:51:23 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27C9F912D0; Thu, 6 Jun 2002 15:51:23 -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 36C35912CF for ; Thu, 6 Jun 2002 15:51:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37D345DE02; Thu, 6 Jun 2002 15:51:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B044F5DDC2 for ; Thu, 6 Jun 2002 15:51:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12874; Thu, 6 Jun 2002 15:51:22 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27456; Thu, 6 Jun 2002 15:51:23 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 15:51:22 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271F@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 15:51:20 -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 Pedro: -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 3:35 PM To: Abarbanel, Benjamin Cc: idr@merit.edu Subject: RE: Abarbanel, Benjamin writes: > I have a third solution to propose to the list. Why not dampen the > MED from the BGP Route Selection Criteria during conditions when a > route is oscillating As i mentioned in my previous e-mail to the list, the devil is in the details... Someone needs to specify the behaviour and do an analysis to see if it is feasible... without some detailed analysis i don't think it is possible to know if that is a feasible solution. Keep in mind the following scenario: You have N peering points with AS 1 in your ibgp mesh. Each of those N points receives a route with an MED. When the best external route changes, all of those N peering points advertise their external route to the mesh and then withraw it as they converge to the second best MED. In this case are you going to hold dampening history for all these paths ? Are you going to apply penalties to individual paths (as in the ebgp case) or routes... don't forget that you need to dampen things in a coverged state (i.e. no routing loops in the mesh). >> What is being dampened is not the route but whether we use the MED >> for this route in the BRSC calculations when we detect a route has been >> oscillating. Once, the route exits its oscillation state MED is automatically >> reapplied. >> >> General IBGP dampening can be done as was done in EBGP but for the problem >> we have been exposed to, the MED dampening should suffice. >> >> Yes, we would need to keep track of the routes previous history in order >> to know that it has entered oscillation state. This mechanism can be >> described in detail in a draft. >> >> Ben From owner-idr@merit.edu Thu Jun 6 19:56:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02277 for ; Thu, 6 Jun 2002 18:46:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87310912DC; Thu, 6 Jun 2002 17:17:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 502B9912DF; Thu, 6 Jun 2002 17:17:11 -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 58BFC912DC for ; Thu, 6 Jun 2002 17:17:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57E255DDA0; Thu, 6 Jun 2002 17:17:05 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0DCE95DD9C for ; Thu, 6 Jun 2002 17:17:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22556; Thu, 6 Jun 2002 17:17:09 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17884; Thu, 6 Jun 2002 17:17:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 17:17:09 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822722@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 17:17:07 -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: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 4:46 PM To: Abarbanel, Benjamin Cc: idr@merit.edu Subject: RE: Abarbanel, Benjamin writes: >>> What is being dampened is not the route but whether we use the MED >>> for this route in the BRSC calculations when we detect a route has >>> been oscillating. Once, the route exits its oscillation state MED >>> is automatically reapplied. >>> >>> General IBGP dampening can be done as was done in EBGP but for the problem >>> we have been exposed to, the MED dampening should suffice. >>> >>> Yes, we would need to keep track of the routes previous history in >>> order to know that it has entered oscillation state. This >>> mechanism can be described in detail in a draft. >>> While i would encorage you to describe the proposal in detail, your brief synopsis gives me the impression that you propose to ignore certain attributes on different members of the ibgp mesh. ibgp route decision mush be consistent enought to ensure that loops are not formed. I don't think you can gurantee that if different members of the mesh use different attributes. >> This solution is no different than an operator going to a router with >> an oscillating route and deconfiguring the MED from it, while keeping >> the other routers unchanged. Yes, inconsistancy will form, but millisecond >> route oscillation will be stoped much faster than an operator can first >> find the router and second stop it by applying manual configuration change. >> Remember the router will have enough smarts to know the state of the route >> and how to adjust its MED to dampen the oscillation. As others have said, >> all solutions proposed will have temporary transient states that are not >> healthy to the network. >> >> BTW, when all the routers are equiped with the MED dampening, they will all >> reach the same conclusion with the state of the MED and they will all be >> consistent. >> >> Ben From owner-idr@merit.edu Thu Jun 6 19:56:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02339 for ; Thu, 6 Jun 2002 18:46:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D76C59120D; Thu, 6 Jun 2002 15:26:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A759B912CA; Thu, 6 Jun 2002 15:26:49 -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 BDA1D9120D for ; Thu, 6 Jun 2002 15:26:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFC125DDF4; Thu, 6 Jun 2002 15:26:43 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4B07A5DDC2 for ; Thu, 6 Jun 2002 15:26:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09904; Thu, 6 Jun 2002 15:26:48 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20826; Thu, 6 Jun 2002 15:26:49 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 15:26:48 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271D@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , f b shepherd Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 15:26:47 -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 I have a third solution to propose to the list. Why not dampen the MED from the BGP Route Selection Criteria during conditions when a route is oscillating, thus temporarily removing the route from a possible oscillation state and stoping it. This solution only imposes additional internal resources on a given router and does not introduce scalability issues with external routers. In addition, the oscillation is not critical to the topology configured but to the behavior of the route. In other words, I propose we treat the route oscillation not try to cure it, since its source is topologically unpredictable and the existing BGP protocol design does not warrant redefining its basic rules of operation. Ben -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 2:56 PM To: f b shepherd Cc: idr@merit.edu Subject: f b shepherd writes: > ==> It seems to me impossible to adhere to only propogating > best-path and yet to eliminate all oscillations which were > considering (or maybe even to only eleiminate types I and II churn). > At least not without some other radical change to the protocol. There is a simple answer, which is to address the current MED behaviour. MEDs as current specified make it so that there isn't possible to establish a global ordering between BGP paths. The protocol when originally designed implicit required such property. Given a global ordering of paths within an ibgp mesh no persistent osciallation will occur and the protocol as originally specified will be stable. In order to achieve this, of course, one needs to encounter an solution to the problem that MEDs are supposed to solve. One possible solution is to mandate 'always-compare-med' behaviour which will make paths have a global ordering. I remember there was strong reaction against this from the operational folks but i'm not quite sure what the arguments where (would apreciate if somebody could refresh my memory). Or we can attempt to specify a different attribute/mechanism that achieves the desired effects. Pedro. From owner-idr@merit.edu Thu Jun 6 19:56:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02171 for ; Thu, 6 Jun 2002 18:46:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0956E912EE; Thu, 6 Jun 2002 17:51:36 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4DEF912ED; Thu, 6 Jun 2002 17:51:35 -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 710E6912E8 for ; Thu, 6 Jun 2002 17:51:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79CCC5DDAD; Thu, 6 Jun 2002 17:51:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 058225DD9C for ; Thu, 6 Jun 2002 17:51:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA25904; Thu, 6 Jun 2002 17:51:32 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26126; Thu, 6 Jun 2002 17:51:33 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 17:51:33 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822723@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 17:51:31 -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 Pedro: -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 5:29 PM To: Abarbanel, Benjamin Cc: idr@merit.edu Subject: RE: Abarbanel, Benjamin writes: my text: > ibgp route decision mush be consistent enought to ensure that loops > are not formed. I don't think you can gurantee that if different > members of the mesh use different attributes. >>> This solution is no different than an operator going to a router >>> with an oscillating route and deconfiguring the MED from it, while >>> keeping the other routers unchanged. When you 'unconfigure MED' from a route you basically strip that attribute at the border router that receives it. Thus no inconsistencies exist since everybody sees the same set of attributes. If done properly this manual condifuration never causes inconsistent behaviour, since it affects what all routers see in terms of attributes for the same path. >>>> So why cant the same thing be accomplish by the MED Dampening? >>> >>> BTW, when all the routers are equiped with the MED dampening, they >>> will all reach the same conclusion with the state of the MED and they will >>> all be consistent. >>> Different members of an ibgp mesh see different routes and different events... the number of flaps in a route is different. Most mesh members have a different prespective and the potential to reach different conclusions. >>>> True, but the mechanism will reach the same conclusion whether to >>>> Dampen the route'a MED or not, based on the route's state. >>>> >>>> BTW. I dont think MED has to be applied symmetrically as you alluded >>>> to in earlier posts. MED is just an attribute in helping pick a bias >>>> for the best exit point of a given AS, it does not have to be the >>>> same in each router. Therefore, suppressing it should not cause >>>> prolonged instabilities. It will affect the optimal path chosen assuming >>>> its based on IGP metrics and routes that are reachable. >>>> >>>> Ben It is probably best for me to refrain from commenting further until i see a concrete proposal which can then be analyzed. I just wanted to caution you in advance to a set of issues that imho should be addressed by such proposal. Pedro. From owner-idr@merit.edu Thu Jun 6 19:56:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02310 for ; Thu, 6 Jun 2002 18:46:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCFDA912D7; Thu, 6 Jun 2002 15:18:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93CA7912D6; Thu, 6 Jun 2002 15:18:34 -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 40C509120D for ; Thu, 6 Jun 2002 15:18:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4324F5DDC2; Thu, 6 Jun 2002 15:18:23 -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 B18B05DDF4 for ; Thu, 6 Jun 2002 15:18:22 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56JIUm44180; Thu, 6 Jun 2002 12:18:30 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56JIUM86879; Thu, 6 Jun 2002 12:18:30 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 12:18:30 -0700 (PDT) Message-Id: <200206061918.g56JIUM86879@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: your mail In-Reply-To: <20020606150051.B27447@nexthop.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <200206061855.g56Itda86837@roque-bsd.juniper.net> <20020606150051.B27447@nexthop.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jeffrey Haas writes: > On Thu, Jun 06, 2002 at 11:55:39AM -0700, Pedro Roque Marques wrote: >> One possible solution is to mandate 'always-compare-med' behaviour >>... > With the current behavior, a given AS may inject backup paths to > their upstream and have the expected behavior happen so long as it > gets to the MED portion of tie-breaking: the routes with the worse > meds are suppressed. Can you elaborate please... i don't quite get the scenario where different behaviour is introduced. > With always-compare-med, all AS peers must adhere to a common policy > of what MEDs they will use for a given prefix. Only for prefixes that they both announce... i don't have access to meaningful data myself but a point made several times in this discussion is that the number of prefixes which end up with a decision with same length as-paths from different neighbor ASes where between the same AS you pick best MED and between different AS you pick best IGP, etc... is said to be quite small. Still probably unpractical to coordinate, i admit. > While theoretically > possible, making more than one ISP agree about anything is hard to > scale. :-) Don't forget that the same thing is true for any proposal that changes the number of paths present on their systems... or any behaviour change. :-) >> Or we can attempt to specify a different attribute/mechanism that >> achieves the desired effects. > If I recall previous discussions, the amount of state that would > need to be flooded throughout the AS was only a little less than > flooding the relevant full routing instances. There are 2 different type of problems that i'm aware of... 1) The current behaviour of MEDs make it so that all the routers in an ibgp choose one of the paths of a neighbor AS over another reducing the number of paths in the system. If you discard MEDs at your borders the number of paths injected in the iBGP greatly increases (to the number of peering points) as all the mesh members start prefering their own external path and advertising them into the mesh. 2) You need to convey the information itself of which of the exit points is preferable from a point of view of your neighbor AS. MHO is that it is possible to find solutions for this issues. Pedro. From owner-idr@merit.edu Thu Jun 6 19:56:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02202 for ; Thu, 6 Jun 2002 18:46:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9A2B912B4; Thu, 6 Jun 2002 13:55:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D374912B7; Thu, 6 Jun 2002 13:55:33 -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 36534912B4 for ; Thu, 6 Jun 2002 13:55:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36E645DEBE; Thu, 6 Jun 2002 13:55:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E2F675DEB4 for ; Thu, 6 Jun 2002 13:55:26 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 13:55:34 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7A6@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: idr@merit.edu, "'isp-bgp@isp-bgp.com'" , isp-routing@isp-routing.com Subject: bgp pruning Date: Thu, 6 Jun 2002 13:55:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D83.598E4C90" Sender: owner-idr@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D83.598E4C90 Content-Type: text/plain Given the following config: DUT-------r2 l l l l l l r3--------r4 All routers are in different AS's. The AS # is the router #. r3 showed that the DUT was sending the routes that originated from r3 with an AS path of 3 4 2 1 (which is the correct AS path). The expected behavior is for the DUT to not send these routes since they will be denied by r3 anyway as part of the BGP pruning process; this is what a major vendor does (prunes on the output as well). But the RFC1771 does not require that these routes not be sent (it does require that they be pruned at the input of r3). It seems to me that it IS better to do it the way the major vendor does it (prune at input and output) in order to save BW and processing. Why does RFC1771/the 17th draft not specify output pruning (or does it)? Can/should this be added? What does that other major vendor do? How am I doing on my political correctness? Thank you. ------_=_NextPart_001_01C20D83.598E4C90 Content-Type: text/html

 

Given the following config:

DUT-------r2

l         l

l         l

l         l

r3--------r4

 

All routers are in different AS's.  The AS # is the router #.  r3 showed that the DUT was sending the routes that originated from r3 with an AS path of 3 4 2 1 (which is the correct AS path).  The expected behavior is for the DUT to not send these routes since they will be denied by r3 anyway as part of the BGP pruning process; this is what a major vendor does (prunes on the output as well). But the RFC1771 does not require that these routes not be sent (it does require that they be pruned at the input of r3).  It seems to me that it IS better to do it the way the major vendor does it (prune at input and output) in order to save BW and processing.

 

Why does RFC1771/the 17th draft not specify output pruning (or does it)? 

 

Can/should this be added?

 

What does that other major vendor do?

 

How am I doing on my political correctness?

 

Thank you.

 

------_=_NextPart_001_01C20D83.598E4C90-- From owner-idr@merit.edu Thu Jun 6 21:54:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24898 for ; Thu, 6 Jun 2002 21:54:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B3159121C; Thu, 6 Jun 2002 21:54:39 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1534E912E6; Thu, 6 Jun 2002 21:54:38 -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 215EB9121C for ; Thu, 6 Jun 2002 21:54:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CFAA5DE37; Thu, 6 Jun 2002 21:54:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id B2ECB5DDA2 for ; Thu, 6 Jun 2002 21:54:32 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g571scHt019075; Thu, 6 Jun 2002 18:54:38 -0700 (PDT) Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) From: Alvaro Retana To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: Anindya Basu , Subject: RE: I-BGP Oscillations In-Reply-To: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Thu, 6 Jun 2002, Abarbanel, Benjamin wrote: -> Why not, IBGP Dampening is what I have been thinking aboute since -> this problem was first exposed to IETF.... The problem with dampening is that you're just hiding the churn (making it slower), not fixing it. :-( -> From: Pedro Roque Marques [mailto:roque@juniper.net] ... -> > One way to address this issue would be to *only* send out extra -> > routes when necessary. In other words, if an oscillation involving -> > I-BGP routes is detected, extra information for only that route -> > could be sent out. -> -> If we come up with a decent detection mechanism it would be so much -> simpler just to reduce the rate of oscilation. "reducing the rate of oscillation" sounds to me like dampening. =:-) Again, that doesn't solve the problem, it just masks it, potentially making the periods of 'incorrect' routing longer (as well as the periods of correct routing, of course)... -> Note that the answer 'ibgp dampening' that is certain to pop up in -> peoples minds by association is a bit misleading. I agree that iBGP dampening is not the answer. However, a "dampening-like" (no penalties) mechanism to detect the oscillation and then act on it, would work. Obviously, the oscillation characteristics of a MED churn are not the same as the ones of "normal" flapping. We had run some numbers a while back (maybe a year and a half ago) on data from backbones experiencing the MED churn, and found that only about 1-2% of the routes were **candidates** to oscillate. IMHO, the state and extra information is not significant. ;-) Alvaro. From owner-idr@merit.edu Fri Jun 7 11:10:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00154 for ; Fri, 7 Jun 2002 11:10:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 999E89122B; Fri, 7 Jun 2002 11:10:19 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F92C912C3; Fri, 7 Jun 2002 11:10: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 8BF699122B for ; Fri, 7 Jun 2002 11:10:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD3B55DE53; Fri, 7 Jun 2002 11:10:13 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 40C045DE52 for ; Fri, 7 Jun 2002 11:10:13 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03365; Fri, 7 Jun 2002 11:10:18 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13085; Fri, 7 Jun 2002 11:10:17 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 11:10:12 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822726@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Alvaro Retana'" , "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: Anindya Basu , idr@merit.edu Subject: RE: I-BGP Oscillations Date: Fri, 7 Jun 2002 11:10:10 -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 -> Why not, IBGP Dampening is what I have been thinking aboute since -> this problem was first exposed to IETF.... > The problem with dampening is that you're just hiding the churn (making it > slower), not fixing it. :-( By dampening the route that is oscillation due to MED in a certain configuration. You either remove the MED attribute affecting the decision process and thus allow other routes to get preference or you completely remove the route from being a candidate if its oscillating too much. Thus you totally disable the oscillation and churn condition. Broadcasting other routes to stop an oscillating route might affect the decision process and stop the churn, but its like hitting a nail with a sledge hammer. Why should we expose the network to more redundant routes? I am sure, we will have many more legitimate opportunities to do so, but not to stop a bug in the protocol. Please review proposed workaround solutions sited in section 4.3 (item 2, 3) and section 5.2 (item 1,2) of draft-ietf-idr-route-oscillation-01.txt. I dont think what I am proposing is very far from these solutions being done automatically by the MED induced route oscillation detection mechanism. -> Note that the answer 'ibgp dampening' that is certain to pop up in -> peoples minds by association is a bit misleading. > I agree that iBGP dampening is not the answer. However, a > "dampening-like" (no penalties) mechanism to detect the oscillation and > then act on it, would work. Obviously, the oscillation characteristics of > a MED churn are not the same as the ones of "normal" flapping. Can you be more specific on what you mean by "MED churn are not the same as the ones of "normal" flapping:. > We had run some numbers a while back (maybe a year and a half ago) on data > from backbones experiencing the MED churn, and found that only about 1-2% > of the routes were **candidates** to oscillate. IMHO, the state and extra > information is not significant. ;-) what was the frequency of oscillation? What was the impact to the router that you tested? Also, what was the memory consumption levels during this period of instability? Thanks, Ben From owner-idr@merit.edu Fri Jun 7 11:13:14 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00389 for ; Fri, 7 Jun 2002 11:13:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 320A4912C3; Fri, 7 Jun 2002 11:13:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F182A912C4; Fri, 7 Jun 2002 11:13:02 -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 1838F912C3 for ; Fri, 7 Jun 2002 11:13:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47E845DE52; Fri, 7 Jun 2002 11:12:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C40965DE4F for ; Fri, 7 Jun 2002 11:12:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03708; Fri, 7 Jun 2002 11:13:02 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13937; Fri, 7 Jun 2002 11:13:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 11:13:02 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822727@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'danny@tcb.net'" , idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Fri, 7 Jun 2002 11:13:01 -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 Danny: Can you site in size of topology and number of routes, how many more routes would a peer experience if we use the solution to stop oscillation by broadcasting non-best paths to peers as was defined by Wilfond and others? Ben -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Thursday, June 06, 2002 5:59 PM To: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > >> Speaking as a SP (today), I'll gladly provide BGP table access to > >> anyone interested in doing this. > > Or get any number of them from archive.routeviews.org. Actually, I was speaking more along the lines of a full analysis, where they'd get all the paths from all the EBGP-speaking routers in my AS, and given the routing topology, flag where issues will/may occur and determine the impact of a given proposal. (Then I could use the code for a few other things I need to do :-) -danny From owner-idr@merit.edu Fri Jun 7 12:00:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02043 for ; Fri, 7 Jun 2002 12:00:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D780912CA; Fri, 7 Jun 2002 12:00:38 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A8C5912CC; Fri, 7 Jun 2002 12:00:38 -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 6525E912CA for ; Fri, 7 Jun 2002 12:00:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E69F35DE55; Fri, 7 Jun 2002 12:00:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 6B79C5DE52 for ; Fri, 7 Jun 2002 12:00:30 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g57G06T07746 for ; Fri, 7 Jun 2002 10:00:06 -0600 Message-Id: <200206071600.g57G06T07746@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Fri, 07 Jun 2002 10:00:06 -0600 Sender: owner-idr@merit.edu Precedence: bulk > Can you site in size of topology and number of routes, how many more > routes would a peer experience if we use the solution to stop oscillation > by broadcasting non-best paths to peers as was defined by Wilfond and > others? I can provide any interested with real numbers from a real network employing BGP RR. If you're interested contact me offline. -danny From owner-idr@merit.edu Fri Jun 7 12:09:35 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02358 for ; Fri, 7 Jun 2002 12:09:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D3CB912CD; Fri, 7 Jun 2002 12:07:08 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06682912D1; Fri, 7 Jun 2002 12:07:07 -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 8D723912CD for ; Fri, 7 Jun 2002 12:07:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5BE45DE5A; Fri, 7 Jun 2002 12:06:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 0A6825DE55 for ; Fri, 7 Jun 2002 12:06:58 -0400 (EDT) Received: from [192.168.42.10] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA25401; Fri, 7 Jun 2002 12:07:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: Date: Fri, 7 Jun 2002 11:51:58 -0400 To: idr@merit.edu From: "John G. Scudder" Subject: oscillation, total ordering, and always-compare-med Cc: Jeffrey Haas , Pedro Roque Marques Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk A couple of replies, aggregated. --John At 4:14 PM -0400 6/6/02, Jeffrey Haas wrote: >Without taking this to the more complicated cases, the argument that >the operational community makes is that "always-compare-med" is a form >of denial of service. "Denial of service" overstates the case. By definition, for the MEDs of two ISPs to clash (which does _not_ happen often), they must be MEDs for the same prefix, and the paths must be considered equally-desirable by all previous criteria. If one defines "service" as "the delivery of packets to the network depicted by that prefix", then it's clearly not being denied in that case -- one equally-desirable path is merely being picked over another. The argument may even be made that the policy of the prefix owner is not even being subverted, because if the prefix owner preferred to receive traffic via one or the other of the ISPs in question, they'd pad their AS path in one of the directions, and in doing so would render the MED question moot. If I were still an ISP I think this argument would be sufficient to convince me to turn on always-compare-med everywhere in my network (perhaps after auditing my routing tables). But I'm not, so there you have it. Certainly always-compare-med changes MED semantics, but "denial of service" it ain't. At 11:55 AM -0700 6/6/02, Pedro Roque Marques wrote: >There is a simple answer, which is to address the current MED >behaviour. MEDs as current specified make it so that there isn't >possible to establish a global ordering between BGP paths. The >protocol when originally designed implicit required such property. > >Given a global ordering of paths within an ibgp mesh no persistent >osciallation will occur and the protocol as originally specified will >be stable. Yep. And of course always-compare-med gives us total ordering (at the admitted cost of changing the MED semantics). >In order to achieve this, of course, one needs to encounter an >solution to the problem that MEDs are supposed to solve. By this I take it you are saying one needs a solution which (a) gives us total ordering over all BGP routes, (b) scales as well as current (hierarchical) IBGP and (c) gives us the exact semantics MEDs are intended to provide (i.e., the semantics they do provide in a full IBGP mesh). I would be extremely surprised (though happy) if there exists a solution which satisfies all these criteria. Perhaps one of the researchers on the list would like to do a proof of this statement for their next SIGCOMM paper. (While a proof would be nice, the fact that nobody's done it yet is at least some evidence.) >One possible solution is to mandate 'always-compare-med' behaviour >which will make paths have a global ordering. I remember there was >strong reaction against this from the operational folks but i'm not >quite sure what the arguments where (would apreciate if somebody could >refresh my memory). As many folks already know, personally always-compare-med is my preferred solution because instead of trying to band-aid over the bug in the protocol, it eliminates it in a clean, cheap and efficient manner. However, as Pedro says there has been strong resistance to the idea from operational folks, hence the current round of discussion. Also, it bears repeating that the always-compare-med solution can be deployed _now_ by anyone who wants to, since many (most? all?) vendors already provide an always-compare-med knob. So for anyone who is prepared to use it, a solution exists today. From owner-idr@merit.edu Fri Jun 7 13:24:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04821 for ; Fri, 7 Jun 2002 13:24:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1756912C3; Fri, 7 Jun 2002 13:24:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE78F912CA; Fri, 7 Jun 2002 13:24:21 -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 C763E912C3 for ; Fri, 7 Jun 2002 13:24:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06E875DE65; Fri, 7 Jun 2002 13:24:16 -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 A67D55DE90 for ; Fri, 7 Jun 2002 13:24:15 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 37F0B2CDB59; Fri, 7 Jun 2002 10:24:23 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id D6B2215D3C1; Fri, 7 Jun 2002 10:24:19 -0700 (PDT) To: Alvaro Retana Cc: idr@merit.edu, enke@redback.com Subject: Re: I-BGP Oscillations In-Reply-To: Message from Alvaro Retana of "Thu, 06 Jun 2002 21:54:38 EDT." Date: Fri, 07 Jun 2002 10:24:19 -0700 From: Enke Chen Message-Id: <20020607172420.D6B2215D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) > From: Alvaro Retana > To: "'Pedro Roque Marques'" , > "Abarbanel, Benjamin" > Cc: Anindya Basu , > Subject: RE: I-BGP Oscillations > In-Reply-To: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> > Message-ID: > MIME-Version: 1.0 [snip] > > -> If we come up with a decent detection mechanism it would be so much > -> simpler just to reduce the rate of oscilation. > > "reducing the rate of oscillation" sounds to me like dampening. =:-) > Again, that doesn't solve the problem, it just masks it, potentially > making the periods of 'incorrect' routing longer (as well as the periods > of correct routing, of course)... > > > -> Note that the answer 'ibgp dampening' that is certain to pop up in > -> peoples minds by association is a bit misleading. > > I agree that iBGP dampening is not the answer. However, a > "dampening-like" (no penalties) mechanism to detect the oscillation and > then act on it, would work. Obviously, the oscillation characteristics of > a MED churn are not the same as the ones of "normal" flapping. Regarding a "dampening-like" mechanism (but no dampening) for IBGP route oscillation detection, I would like to point out that not only is such a mechanism a good idea, it is also feasible to implement. In fact, the mechanism has been implemented and in production release on Redback SE800 for a while. The command "sho bgp route flap-statistics internal" displays the IBGP routes that are flapping, and their frequencies. Then one can look closely at the ones with the high flap frequencies to see if they are indeed experiencing the "persistent route oscillation". -- Enke From owner-idr@merit.edu Fri Jun 7 13:41:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05263 for ; Fri, 7 Jun 2002 13:41:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A996D912CA; Fri, 7 Jun 2002 13:41:36 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D090912CD; Fri, 7 Jun 2002 13:41:36 -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 8BB5D912CA for ; Fri, 7 Jun 2002 13:41:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE6085DE5F; Fri, 7 Jun 2002 13:41:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4538A5DDF1 for ; Fri, 7 Jun 2002 13:41:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19806; Fri, 7 Jun 2002 13:41:28 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17087; Fri, 7 Jun 2002 13:41:25 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 13:41:24 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582272D@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Enke Chen'" , Alvaro Retana Cc: idr@merit.edu Subject: RE: I-BGP Oscillations Date: Fri, 7 Jun 2002 13:41:23 -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 Horrayy Enke, Thank you. I dont know why I was getting such resistance to this method. Ben -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Friday, June 07, 2002 1:24 PM To: Alvaro Retana Cc: idr@merit.edu; enke@redback.com Subject: Re: I-BGP Oscillations > Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) > From: Alvaro Retana > To: "'Pedro Roque Marques'" , > "Abarbanel, Benjamin" > Cc: Anindya Basu , > Subject: RE: I-BGP Oscillations > In-Reply-To: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> > Message-ID: > MIME-Version: 1.0 [snip] > > -> If we come up with a decent detection mechanism it would be so much > -> simpler just to reduce the rate of oscilation. > > "reducing the rate of oscillation" sounds to me like dampening. =:-) > Again, that doesn't solve the problem, it just masks it, potentially > making the periods of 'incorrect' routing longer (as well as the periods > of correct routing, of course)... > > > -> Note that the answer 'ibgp dampening' that is certain to pop up in > -> peoples minds by association is a bit misleading. > > I agree that iBGP dampening is not the answer. However, a > "dampening-like" (no penalties) mechanism to detect the oscillation and > then act on it, would work. Obviously, the oscillation characteristics of > a MED churn are not the same as the ones of "normal" flapping. Regarding a "dampening-like" mechanism (but no dampening) for IBGP route oscillation detection, I would like to point out that not only is such a mechanism a good idea, it is also feasible to implement. In fact, the mechanism has been implemented and in production release on Redback SE800 for a while. The command "sho bgp route flap-statistics internal" displays the IBGP routes that are flapping, and their frequencies. Then one can look closely at the ones with the high flap frequencies to see if they are indeed experiencing the "persistent route oscillation". -- Enke From owner-idr@merit.edu Fri Jun 7 13:53:33 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05735 for ; Fri, 7 Jun 2002 13:53:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 61D7D912FF; Fri, 7 Jun 2002 13:51:43 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32DAE912F9; Fri, 7 Jun 2002 13:51:43 -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 25933912F0 for ; Fri, 7 Jun 2002 13:49:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61EC55DE5D; Fri, 7 Jun 2002 13:49:44 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 1DE5C5DE53 for ; Fri, 7 Jun 2002 13:49:44 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57HnnHt006052; Fri, 7 Jun 2002 10:49:50 -0700 (PDT) Date: Fri, 7 Jun 2002 13:49:49 -0400 (EDT) From: Alvaro Retana To: "Abarbanel, Benjamin" Cc: "'Pedro Roque Marques'" , Anindya Basu , Subject: RE: I-BGP Oscillations In-Reply-To: <39469E08BD83D411A3D900204840EC55822726@vie-msgusr-01.dc.fore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 7 Jun 2002, Abarbanel, Benjamin wrote: Ben: -> Please review proposed workaround solutions sited in section 4.3 (item -> 2, 3) and section 5.2 (item 1,2) of -> draft-ietf-idr-route-oscillation-01.txt. I dont think what I am -> proposing is very far from these solutions being done automatically by -> the MED induced route oscillation detection mechanism. I think someone else mentioned before that the potential workarounds in the idr-route-oscillation draft were not considered acceptable by network operators -- at least not at the time we first brought the issue up at IETF and NANOG... -> -> Note that the answer 'ibgp dampening' that is certain to pop up in -> -> peoples minds by association is a bit misleading. -> -> > I agree that iBGP dampening is not the answer. However, a -> > "dampening-like" (no penalties) mechanism to detect the oscillation and -> > then act on it, would work. Obviously, the oscillation characteristics of -> > a MED churn are not the same as the ones of "normal" flapping. -> -> Can you be more specific on what you mean by "MED churn are not the -> same as the ones of "normal" flapping:. In short... For the MED churn to occur, you need a group of routes to meet the "requirements" (they're changing because of each other)...in "normal" flapping, each route flaps independently (even though they may all flap for the same reason: a peer reset, for example). -> > We had run some numbers a while back (maybe a year and a half ago) on data -> > from backbones experiencing the MED churn, and found that only about 1-2% -> > of the routes were **candidates** to oscillate. IMHO, the state and extra -> > information is not significant. ;-) -> -> what was the frequency of oscillation? Because of our implementation, close to one minute. ;-) But when we saw it in a multi-vendor backbone, the frequency varied (mostly faster). -> What was the impact to the router that you tested? Also, what was the -> memory consumption levels during this period of instability? They were live routers. ;-) No visible changes in performance, memory utilization, etc.. Some transient loops and constantly changing routes was what brought our attention to it. :-) :-) Alvaro. From owner-idr@merit.edu Fri Jun 7 14:10:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06765 for ; Fri, 7 Jun 2002 14:10:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A533912C3; Fri, 7 Jun 2002 14:10:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09A6D912D3; Fri, 7 Jun 2002 14:10: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 B3C5F912C3 for ; Fri, 7 Jun 2002 14:10:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1C8A5DDF1; Fri, 7 Jun 2002 14:10:48 -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 9C2B45DDEA for ; Fri, 7 Jun 2002 14:10:48 -0400 (EDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 74D07F2C52; Fri, 7 Jun 2002 11:10:56 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 578A6979C1; Fri, 7 Jun 2002 11:10:52 -0700 (PDT) To: "Abarbanel, Benjamin" Cc: Alvaro Retana , idr@merit.edu, enke@redback.com Subject: Re: I-BGP Oscillations In-Reply-To: Message from "Abarbanel, Benjamin" of "Fri, 07 Jun 2002 13:41:23 EDT." <39469E08BD83D411A3D900204840EC5582272D@vie-msgusr-01.dc.fore.com> Date: Fri, 07 Jun 2002 11:10:52 -0700 From: Enke Chen Message-Id: <20020607181054.578A6979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Ben, It seems to me that folks are resisting the idea of "IBGP route dampening" (which has too many issues). I do not think that folks are resisting the idea of a "dampening-like" mechanism for detectig IBGP route flap/oscillation (without actually dampening these routes). -- Enke > Message-ID: <39469E08BD83D411A3D900204840EC5582272D@vie-msgusr-01.dc.fore.com> > From: "Abarbanel, Benjamin" > To: "'Enke Chen'" , > Alvaro Retana > Cc: idr@merit.edu > Subject: RE: I-BGP Oscillations > Date: Fri, 7 Jun 2002 13:41:23 -0400 > > Horrayy Enke, Thank you. I dont know why I was getting such resistance to > this method. > > Ben > > -----Original Message----- > From: Enke Chen [mailto:enke@redback.com] > Sent: Friday, June 07, 2002 1:24 PM > To: Alvaro Retana > Cc: idr@merit.edu; enke@redback.com > Subject: Re: I-BGP Oscillations > > > > Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) > > From: Alvaro Retana > > To: "'Pedro Roque Marques'" , > > "Abarbanel, Benjamin" > > Cc: Anindya Basu , > > Subject: RE: I-BGP Oscillations > > In-Reply-To: > <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> > > Message-ID: > > MIME-Version: 1.0 > > [snip] > > > > > -> If we come up with a decent detection mechanism it would be so much > > -> simpler just to reduce the rate of oscilation. > > > > "reducing the rate of oscillation" sounds to me like dampening. =:-) > > Again, that doesn't solve the problem, it just masks it, potentially > > making the periods of 'incorrect' routing longer (as well as the periods > > of correct routing, of course)... > > > > > > -> Note that the answer 'ibgp dampening' that is certain to pop up in > > -> peoples minds by association is a bit misleading. > > > > I agree that iBGP dampening is not the answer. However, a > > "dampening-like" (no penalties) mechanism to detect the oscillation and > > then act on it, would work. Obviously, the oscillation characteristics of > > a MED churn are not the same as the ones of "normal" flapping. > > Regarding a "dampening-like" mechanism (but no dampening) for IBGP route > oscillation detection, I would like to point out that not only is such > a mechanism a good idea, it is also feasible to implement. In fact, the > mechanism has been implemented and in production release on Redback SE800 > for a while. The command "sho bgp route flap-statistics internal" displays > the IBGP routes that are flapping, and their frequencies. Then one can > look closely at the ones with the high flap frequencies to see if they > are indeed experiencing the "persistent route oscillation". > > -- Enke From owner-idr@merit.edu Fri Jun 7 19:11:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16385 for ; Fri, 7 Jun 2002 19:11:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34C8B912DC; Fri, 7 Jun 2002 19:11:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01DB3912DF; Fri, 7 Jun 2002 19:11:40 -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 D6044912DC for ; Fri, 7 Jun 2002 19:11:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DD675DE65; Fri, 7 Jun 2002 19:11:35 -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 9A6705DDA4 for ; Fri, 7 Jun 2002 19:11:34 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 5F9995E45B; Fri, 7 Jun 2002 16:11:42 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 5A2617E6C1; Fri, 7 Jun 2002 16:11:42 -0700 (PDT) To: Pedro Roque Marques Cc: idr@merit.edu, enke@redback.com Subject: Re: rr-oscillation-reduce In-Reply-To: Message from Pedro Roque Marques of "Thu, 06 Jun 2002 11:44:16 PDT." <200206061844.g56IiGr86811@roque-bsd.juniper.net> Date: Fri, 07 Jun 2002 16:11:42 -0700 From: Enke Chen Message-Id: <20020607231142.5A2617E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Pedro: Thanks for your comments on the proposal. > Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) > Message-Id: <200206061844.g56IiGr86811@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: enke@redback.com > Cc: idr@merit.edu > Subject: rr-oscillation-reduce > > Enke, > A few questions/comments on your proposal... > > The gist of it is to advertise 'the best external' (i.e. route from > rr-clients) to the rest of the mesh when the best path is internal > (i.e. received from a ibgp mesh router). > > 1) Why do you limit this procedure to RRs/Confeds... ? Always advertising "the external best" by all border routers can cause significant increase in the number of paths (and memory usage) in a network. The proposal in draft-chen-rr-oscillation-reduce is trying to reduce/eliminate most the route oscillations by advertising the minimal set of additional routing information (that is, at most one path). By "at most one path" I mean that a RR may not advertise a path to other clusters even when clients have external paths. For example, after the RR advertises the overall best (from another cluster) to a client, the client would withdraw its advertisement to the RR if the client does not select its external path as the best. If we allowed the client to always advertise "the best external" path, the client would not withdraw. Then the RR and the rest of the network would be stuck with the additional path that are not useful in route selection. Please note that the additional path would not be present in the netowrk even in the case of full IBGP mesh (with advertising only the best). > > 2) Advertising the 'best external' route as always had the issue of > traffic loops (i believe the reason it hasn't been implemented as > specified in 1771 originally). You don't seem to address this in your > draft... do you believe it is not relevant... or is there some other > solution to this problem... I do not know that part of the implementation history. I can only speculate that the concern of additional memory and implementation simplicity/complexity may have played a larger role in the decision. > > To be more specific, if you have rtrs A, B, such that B has the best > path at t0, and A a valid external path, when at t1 B's external path > gets withrawn, traffic is almost guaranteed to loop until B's > advertisement reaches A. This can be potentially exacerbated by > mechanisms such as min advertisement interval. > > Whereas today such traffic would be blackholed by B... while it is > true that current routers are not as susceptible to rollover and die > when presented with looping traffic as opposed to software forwarding > based boxes of 5+ years ago it is likely that the resulting link > congestion is still a relevant factor.... comments ? Your comparison makes a lot of sense. With the proposal a RR advertises the cleints' best that survives through the route selection (see comment on 1)). It follows the current practice/spirit of advertising the best path. So I do not expect the convergence time to deviate much from today's. -- Enke From owner-idr@merit.edu Fri Jun 7 20:01:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17393 for ; Fri, 7 Jun 2002 20:01:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B3616912E1; Fri, 7 Jun 2002 20:01:50 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 848E7912DC; Fri, 7 Jun 2002 20:01:50 -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 90979912E1 for ; Fri, 7 Jun 2002 20:01:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C84365DDBF; Fri, 7 Jun 2002 20:01:37 -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 770A65DDA4 for ; Fri, 7 Jun 2002 20:01:37 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g5801jm28116; Fri, 7 Jun 2002 17:01:45 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g5801jV90037; Fri, 7 Jun 2002 17:01:45 -0700 (PDT) (envelope-from roque) Date: Fri, 7 Jun 2002 17:01:45 -0700 (PDT) Message-Id: <200206080001.g5801jV90037@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: rr-oscillation-reduce In-Reply-To: <20020607231142.5A2617E6C1@popserv3.redback.com> References: <200206061844.g56IiGr86811@roque-bsd.juniper.net> <20020607231142.5A2617E6C1@popserv3.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Enke Chen writes: > Hi, Pedro: Thanks for your comments on the proposal. >> Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) Message-Id: >> <200206061844.g56IiGr86811@roque-bsd.juniper.net> From: Pedro Roque >> Marques To: enke@redback.com Cc: idr@merit.edu >> Subject: rr-oscillation-reduce >> >> Enke, A few questions/comments on your proposal... >> >> The gist of it is to advertise 'the best external' (i.e. route from >> rr-clients) to the rest of the mesh when the best path is internal >> (i.e. received from a ibgp mesh router). >> >> 1) Why do you limit this procedure to RRs/Confeds... ? > Always advertising "the external best" by all border routers can > cause significant increase in the number of paths (and memory usage) > in a network. The proposal in draft-chen-rr-oscillation-reduce is > trying to reduce/eliminate most the route oscillations by > advertising the minimal set of additional routing information (that > is, at most one path). By "at most one path" I mean that a RR may > not advertise a path to other clusters even when clients have > external paths. For example, after the RR advertises the overall > best (from another cluster) to a client, the client would withdraw > its advertisement to the RR if the client does not select its > external path as the best. If we allowed the client to always > advertise "the best external" path, the client would not > withdraw. Then the RR and the rest of the network would be stuck > with the additional path that are not useful in route > selection. Please note that the additional path would not be present > in the netowrk even in the case of full IBGP mesh (with advertising > only the best). I'm missing something here... The draft says that the proposed modification is: "When the client best path for a RR exists, and the overall best path for the RR is from a non-client IBGP peer, the RR may advertise the client best path to all non-client IBGP peers." It seems to me that by your own admission this is a no op, since as you correctly point out the client will subsequently withrawn it's best path. >> 2) Advertising the 'best external' route as always had the issue >> of traffic loops (i believe the reason it hasn't been implemented >> as specified in 1771 originally). You don't seem to address this in >> your draft... do you believe it is not relevant... or is there some >> other solution to this problem... > I do not know that part of the implementation history. I can only > speculate that the concern of additional memory and implementation > simplicity/complexity may have played a larger role in the decision. >> Whereas today such traffic would be blackholed by B... while it is >> true that current routers are not as susceptible to rollover and >> die when presented with looping traffic as opposed to software >> forwarding based boxes of 5+ years ago it is likely that the >> resulting link congestion is still a relevant factor.... comments ? > So I do not expect the > convergence time to deviate much from today's. Yes, i believe that the convergence time will be the same. However the fundamental difference i'm point out is that during the convergence time traffic will loop instead of being blackholed as it is today. That would apear to be an implication that is necessary to consider. Pedro. From owner-idr@merit.edu Fri Jun 7 20:25:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17753 for ; Fri, 7 Jun 2002 20:25:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2121B912DC; Fri, 7 Jun 2002 20:25:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4A1B912E2; Fri, 7 Jun 2002 20:25: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 E51CA912DC for ; Fri, 7 Jun 2002 20:25:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 394A05DE13; Fri, 7 Jun 2002 20:25:07 -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 EA69B5DDA4 for ; Fri, 7 Jun 2002 20:25:06 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 5AA6A18D3FB; Fri, 7 Jun 2002 17:25:14 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 4B8C515D3C1; Fri, 7 Jun 2002 17:25:04 -0700 (PDT) To: Pedro Roque Marques Cc: idr@merit.edu, enke@redback.com Subject: Re: rr-oscillation-reduce In-Reply-To: Message from Pedro Roque Marques of "Fri, 07 Jun 2002 17:01:45 PDT." <200206080001.g5801jV90037@roque-bsd.juniper.net> Date: Fri, 07 Jun 2002 17:25:03 -0700 From: Enke Chen Message-Id: <20020608002506.4B8C515D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Fri, 7 Jun 2002 17:01:45 -0700 (PDT) > Message-Id: <200206080001.g5801jV90037@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: rr-oscillation-reduce > In-Reply-To: <20020607231142.5A2617E6C1@popserv3.redback.com> > References: > <200206061844.g56IiGr86811@roque-bsd.juniper.net> > <20020607231142.5A2617E6C1@popserv3.redback.com> > X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid > > Enke Chen writes: > > > Hi, Pedro: Thanks for your comments on the proposal. > > >> Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) Message-Id: > >> <200206061844.g56IiGr86811@roque-bsd.juniper.net> From: Pedro Roque > >> Marques To: enke@redback.com Cc: idr@merit.edu > >> Subject: rr-oscillation-reduce > >> > >> Enke, A few questions/comments on your proposal... > >> > >> The gist of it is to advertise 'the best external' (i.e. route from > >> rr-clients) to the rest of the mesh when the best path is internal > >> (i.e. received from a ibgp mesh router). > >> > >> 1) Why do you limit this procedure to RRs/Confeds... ? > > > Always advertising "the external best" by all border routers can > > cause significant increase in the number of paths (and memory usage) > > in a network. The proposal in draft-chen-rr-oscillation-reduce is > > trying to reduce/eliminate most the route oscillations by > > advertising the minimal set of additional routing information (that > > is, at most one path). By "at most one path" I mean that a RR may > > not advertise a path to other clusters even when clients have > > external paths. For example, after the RR advertises the overall > > best (from another cluster) to a client, the client would withdraw > > its advertisement to the RR if the client does not select its > > external path as the best. If we allowed the client to always > > advertise "the best external" path, the client would not > > withdraw. Then the RR and the rest of the network would be stuck > > with the additional path that are not useful in route > > selection. Please note that the additional path would not be present > > in the netowrk even in the case of full IBGP mesh (with advertising > > only the best). > > I'm missing something here... > > The draft says that the proposed modification is: > > "When the client best path for a RR exists, and the overall > best path for the RR is from a non-client IBGP peer, the RR > may advertise the client best path to all non-client IBGP > peers." > > It seems to me that by your own admission this is a no op, since as > you correctly point out the client will subsequently withrawn it's > best path. The text in the draft talks about a RR (toward other clusters), and it does not suggest any change to a client. So a client will withdraw its best path only if its external best does not survive through the route selection. It will not withdraw if its external path remains as the best. > > >> 2) Advertising the 'best external' route as always had the issue > >> of traffic loops (i believe the reason it hasn't been implemented > >> as specified in 1771 originally). You don't seem to address this in > >> your draft... do you believe it is not relevant... or is there some > >> other solution to this problem... > > > I do not know that part of the implementation history. I can only > > speculate that the concern of additional memory and implementation > > simplicity/complexity may have played a larger role in the decision. > > >> Whereas today such traffic would be blackholed by B... while it is > >> true that current routers are not as susceptible to rollover and > >> die when presented with looping traffic as opposed to software > >> forwarding based boxes of 5+ years ago it is likely that the > >> resulting link congestion is still a relevant factor.... comments ? > > > So I do not expect the > > convergence time to deviate much from today's. > > Yes, i believe that the convergence time will be the same. However the > fundamental difference i'm point out is that during the convergence > time traffic will loop instead of being blackholed as it is today. > > That would apear to be an implication that is necessary to consider. Understood. However, it seems to me the implication on the traffic behavior (during routing re-converging) should be no different from doing closest-exit routing in which case multiple alternate paths are present. As I understand, quite a few large providers have been doing closest-exit routing for years. -- Enke From owner-idr@merit.edu Fri Jun 7 20:39:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18044 for ; Fri, 7 Jun 2002 20:39:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E141912E2; Fri, 7 Jun 2002 20:40:02 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21279912E9; Fri, 7 Jun 2002 20:40:02 -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 D4E9B912E2 for ; Fri, 7 Jun 2002 20:40:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 163A75DE13; Fri, 7 Jun 2002 20:39:56 -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 B9BEC5DDA4 for ; Fri, 7 Jun 2002 20:39:55 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g580e3m29972; Fri, 7 Jun 2002 17:40:03 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g580e3X90108; Fri, 7 Jun 2002 17:40:03 -0700 (PDT) (envelope-from roque) Date: Fri, 7 Jun 2002 17:40:03 -0700 (PDT) Message-Id: <200206080040.g580e3X90108@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: rr-oscillation-reduce In-Reply-To: <20020608002506.4B8C515D3C1@popserv1.redback.com> References: <200206080001.g5801jV90037@roque-bsd.juniper.net> <20020608002506.4B8C515D3C1@popserv1.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Enke Chen writes: > The text in the draft talks about a RR (toward other clusters), and > it does not suggest any change to a client. So a client will > withdraw its best path only if its external best does not survive > through the route selection. It will not withdraw if its external > path remains as the best. Ok... would you consider including a description of why this is necessary and/or sufficient to avoid oscilation or certain types of oscillation. > Understood. However, it seems to me the implication on the traffic > behavior (during routing re-converging) should be no different from > doing closest-exit routing in which case multiple alternate paths > are present. As I understand, quite a few large providers have been > doing closest-exit routing for years. I believe i disagree: If you have RRa and RRb, where RRa is advertising a route that it is not installed in it's routing table, it is actually prefering RRb route. When RRb (or the cluster) looses it's best external path it may proceed to forward traffic to RRa which will then loop it back to RRb. This regardless if you are doing closest-exit or not... btw: if you are doing pure closest-exit this entire discussion is irrelevant, correct ? Pedro. From owner-idr@merit.edu Fri Jun 7 21:06:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18553 for ; Fri, 7 Jun 2002 21:06:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22E2F91225; Fri, 7 Jun 2002 21:06:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4C59912E9; Fri, 7 Jun 2002 21:06:56 -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 E8DF491225 for ; Fri, 7 Jun 2002 21:06:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DE185DE53; Fri, 7 Jun 2002 21:06:51 -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 E66615DDA4 for ; Fri, 7 Jun 2002 21:06:50 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 16ACC2CDB40; Fri, 7 Jun 2002 18:06:36 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 6C1E915D3C1; Fri, 7 Jun 2002 18:06:29 -0700 (PDT) To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: rr-oscillation-reduce In-Reply-To: Message from Pedro Roque Marques of "Fri, 07 Jun 2002 17:40:03 PDT." <200206080040.g580e3X90108@roque-bsd.juniper.net> Date: Fri, 07 Jun 2002 18:06:29 -0700 From: Enke Chen Message-Id: <20020608010630.6C1E915D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Fri, 7 Jun 2002 17:40:03 -0700 (PDT) > Message-Id: <200206080040.g580e3X90108@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: rr-oscillation-reduce > In-Reply-To: <20020608002506.4B8C515D3C1@popserv1.redback.com> > References: > <200206080001.g5801jV90037@roque-bsd.juniper.net> > <20020608002506.4B8C515D3C1@popserv1.redback.com> > > Enke Chen writes: > > > The text in the draft talks about a RR (toward other clusters), and > > it does not suggest any change to a client. So a client will > > withdraw its best path only if its external best does not survive > > through the route selection. It will not withdraw if its external > > path remains as the best. > > Ok... would you consider including a description of why this is > necessary and/or sufficient to avoid oscilation or certain types of > oscillation. Sure. > > > Understood. However, it seems to me the implication on the traffic > > behavior (during routing re-converging) should be no different from > > doing closest-exit routing in which case multiple alternate paths > > are present. As I understand, quite a few large providers have been > > doing closest-exit routing for years. > > I believe i disagree: > > If you have RRa and RRb, where RRa is advertising a route that > it is not installed in it's routing table, it is actually prefering > RRb route. When RRb (or the cluster) looses it's best external path it > may proceed to forward traffic to RRa which will then loop it back to > RRb. > Ok. > This regardless if you are doing closest-exit or not... btw: if you > are doing pure closest-exit this entire discussion is irrelevant, > correct ? Right. As I remember, the providers typically only does closest-exit routing toward other providers, and they typically honors MEDs from their customers. So it was (and still is?) a mixed routing. -- Enke From owner-idr@merit.edu Sat Jun 8 05:32:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03895 for ; Sat, 8 Jun 2002 05:32:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 60C44912ED; Sat, 8 Jun 2002 05:32:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DDAB912EF; Sat, 8 Jun 2002 05:32:11 -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 AF454912ED for ; Sat, 8 Jun 2002 05:31:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 142DC5DE6A; Sat, 8 Jun 2002 05:31:20 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id B37065DD93 for ; Sat, 8 Jun 2002 05:31:19 -0400 (EDT) Message-ID: <20020608093127.91456.qmail@web20301.mail.yahoo.com> Received: from [165.213.0.2] by web20301.mail.yahoo.com via HTTP; Sat, 08 Jun 2002 02:31:27 PDT Date: Sat, 8 Jun 2002 02:31:27 -0700 (PDT) From: Mareline Sheldon Subject: Route Reflectors Again! To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi All, What should a correct implmentation for Route Reflector do when it originates a route say by a network command. Should it create a ORIGINATOR field and the CLUSTER_ID in it? My current implmentation is not doing this. Do i need to change it? I ran Agilent router test suite for the conformance tests and it passes all the tests. There is no test in the suite to test self originated routes. Please help. Regards, mareline s. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-idr@merit.edu Tue Jun 18 00:40:08 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28395 for ; Tue, 18 Jun 2002 00:40:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D273D9125D; Tue, 18 Jun 2002 00:39:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CD599125E; Tue, 18 Jun 2002 00:39:33 -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 D3E6C9125D for ; Tue, 18 Jun 2002 00:39:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD0985DDF5; Tue, 18 Jun 2002 00:39:23 -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 AF9C25DDB5 for ; Tue, 18 Jun 2002 00:39:21 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 2358D18D3F7; Mon, 17 Jun 2002 21:39:21 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id AF0837E6C1; Mon, 17 Jun 2002 21:39:20 -0700 (PDT) To: idr@merit.edu Cc: enke@redback.com Subject: draft-chen-route-oscillation-avoid-00.txt Date: Mon, 17 Jun 2002 21:39:20 -0700 From: Enke Chen Message-Id: <20020618043920.AF0837E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: I have submitted . As I will be away (in a couple of days) from email for a while, I thought that I would post the draft to the mailing list directly so that your comments or questions on the draft can be taken care of in the next couple of days. Regards, -- Enke -------------------------------------------------------------------- Network Working Group Enke Chen Internet Draft Redback Networks Expiration Date: December 2002 BGP Route Oscillation Avoidance for Route Reflection and Confederation draft-chen-route-oscillation-avoid-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract In this document we propose a mechanism and routing setup that would avoid persistent route oscillations and yield consistent route selection in a network using one-level Route Reflection, or using Confederation where routers that participate in inter-member-AS peering are fully meshed. Chen [Page 1] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 3. Introduction As documented in [1], the routing information reduction by BGP Route Reflection [2], or BGP Confederation [3] can result in persistent route oscillations with certain network topologies and routing setup. In this document we propose a mechanism and routing setup that would avoid persistent route oscillations and yield consistent route selection in a network using one-level Route Reflection, or using Confederation where routers that participate in inter-member-AS peering are fully meshed. The proposed mechanism makes use of the mechanisms presented in [4, 5], and works within the current BGP protocol [6, 7] that limits route advertisement to only one path per prefix. 4. Observations on IBGP Updates Currently a BGP speaker follows the basic BGP principle that only the best path is advertised to a BGP peer. Since the best path of a prefix for a BGP speaker is impacted by routes received from internal peers, the route advertised by the speaker is also impacted by routes received from internal peers. This dependency can lead to circular (and possibly excessive) IBGP routing updates, slow convergence, and persistent route oscillation in the worst case. The earlier version of BGP [6] specifies that a BGP speaker should advertise to IBGP its best external route [6, Sect. 9.2.1]. With this approach the route advertisement toward IBGP peers is independent of route advertisement received from IBGP peers. In addition, this approach has the benefit of faster routing convergence compared to the current practice of advertising the best path. If clients of a Route Reflector (RR) adopts this approach, and the RR advertises to other clusters the best path from its clients and external peers (as proposed in [4]), then the advertisement by the RR to other clusters would become independent of routes received from other clusters. It is based on this observation that we formulate a mechanism and routing setup that would avoid route oscillations for one-level route reflection, and for a confederation where routers that participate in inter-member-AS peering are fully meshed. Chen [Page 2] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 5. Mechanism for One-level Route Reflection This mechanism consists of the following procedures and routing setup: a) One-level Route Reflection (all RRs are fully meshed). b) BGP full mesh among clients of a RR. c) Apply the mechanism in [4] for a RR. d) A client advertises its best external route to IBGP peers. Due to c) and d), we claim that with this mechanism and setup the network is free of route oscillation. It is noted that due to d) the best external path advertised by a BGP speaker to an IBGP peer may be different from the overall best path installed in RIB/FIB. Clearly the difference will not cause any forwarding loop when the overall best path is also an external path. When the overall best path for a BGP speaker is from an internal peer, we claim that the best external path for the speaker will not be selected as the best path by any other speakers. The proof for this claim is included in the Appendix. Therefore we conclude that the route selection consistency is maintained with the proposed mechanism. 6. Mechanism for Confederation The mechanism for Confederation consists of the following procedures and routing setup: a) BGP full mesh among routers that participate in inter-member-AS peering. b) BGP full mesh within a member-AS. c) Apply the mechanism in [5] for a router that peers with a neighobring AS in the confederation. d) For a router that does not participate in inter-member-AS peering, it should advertises its best external route to peers within a confederation. We claim that with the mechanism and routing setup a network would Chen [Page 3] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 avoid persistent route oscillations and yield consistent route selection. This claim can be proved similarly. 7. Appendix: Proof of Route Selection Consistency To simplify presentation, let us describe a general route reflection setup as follows: RR1 ---------- RR2 ---------- RR3 --- ... RRn / | | | | / | | | | / | | | | / | | | | C11 C12 C2 C3 ... | | | | | | | | | | (E11) (E12) (E2) (E3) ... In this figure, there are multiple clusters with RR1, RR2, RR3 as the route reflectors. C11 and C12 are clients of RR1. C2 is client of RR2, and C3 is a client of RR3. E11, E12, E2, and E3 are the external paths. Other than for the purpose of illustration, no restrictions are imposed on the route reflection topology including the number of clusters, number of clients, and where and how many external paths are connected. Assume that E2 is the best path among all paths received by RR1 from other clusters, and assume that the EBGP path E11 is not the overall best path for C11. we try to prove that E11 will not be selected as the best path by any other routers. Based on route selection procedures described in [7], E11 can only lose (on C11) to an IBGP path (either E12 or E2) by either LOCAL- PREF, or Origin, or AS-PATH Length, or MED. Due to the natural of these parameters, as long as the overall best path (either E12 or E2) is present on a router, E11 will continue to lose on the router irrespective of any other paths. Due to full IBGP mesh within a cluster, both E12 and E2 are present on all routers within the cluster. So E11 will not be selected as the best path by any router within the cluster. To prove that E11 will not be selected as the best path by a router in another cluster, we need to consider two cases: Chen [Page 4] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 (1) Assume E11 is lost to E12 on C11. Then E11 will not selected as the best path from its clients on RR1, and will not be advertised by RR1 to other clusters. (2) Assume E11 is lost to E2 on C11. As RRs are fully meshed, E2 will be present on all RRs. Thus E11 will not be selected as the best path by any of the RRs. Within the cluster served by RR2, E11 will not be selected by its clients (even if E11 is better than E3 on RR2) as E2 is present. As E2 is present on RR3, E11 will not be advertised to its clients, thus will not be selected as the best path by its clients. 8. Security Considerations This document introduces no new security concerns to BGP or other specifications referenced in this document. 9. Acknowledgments The author would like to thank Jenny Yuan for her review and comments. 10. References [1] McPherson, D., Gill, V., Walton, D., Retana, A., "BGP Persistent Route Oscillation Condition", Work in Progress (draft-ietf-idr- route-oscillation-01), February 2002. [2] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [3] Traina, P., McPherson, D., Scudder, J.. "Autonomous System Con- federations for BGP", RFC 3065, February 2001. [4] Chen, E., "BGP Route Oscillation Reduction with Route Reflection", Work in Progress (draft-chen-rr-oscillation-reduce-01.txt), June 2002. [5] Chen, E., "BGP Route Oscillation Reduction with Confederation", Work in Progress (draft-chen-confed-oscillation-reduce-01.txt), June 2002. [6] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Chen [Page 5] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 RFC 1771, March 1995. [7] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress (draft-ietf-idr-bgp4-17), January 2002 11. Author Information Enke Chen Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 Email: enke@redback.com Chen [Page 6] From owner-idr@merit.edu Fri Jun 21 11:44:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17946 for ; Fri, 21 Jun 2002 11:44:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 010819134B; Fri, 21 Jun 2002 11:39:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC2769134E; Fri, 21 Jun 2002 11:39: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 944999134B for ; Fri, 21 Jun 2002 11:39:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4152F5E797; Fri, 21 Jun 2002 11:38:15 -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 C53D85E7EE for ; Fri, 21 Jun 2002 11:38:10 -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 g5LFcAm57068 for ; Fri, 21 Jun 2002 08:38:10 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200206211538.g5LFcAm57068@merlot.juniper.net> To: idr@merit.edu Subject: extended communities implementation report MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6990.1024673890.1@juniper.net> Date: Fri, 21 Jun 2002 08:38:10 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, As part of advancing BGP Extended Communities, we need to provide an implementation report. With this in mind I am asking folks who implemented BGP Extended Communities and are willing to participate in the report to drop me an e-mail (yakov@juniper.net). Participation in the report means answering a small number of questions. While the report itself is going to be public, the identity of the folks who participate in the report need not be public. Thanks in advance. Yakov. From owner-idr@merit.edu Fri Jun 21 11:48:14 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18126 for ; Fri, 21 Jun 2002 11:48:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 983469134F; Fri, 21 Jun 2002 11:46:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9CBB91350; Fri, 21 Jun 2002 11:46:14 -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 CD8A69134E for ; Fri, 21 Jun 2002 11:46:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DDF95E923; Fri, 21 Jun 2002 11:45:32 -0400 (EDT) Delivered-To: idr@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 5480C5E8FE for ; Fri, 21 Jun 2002 11:45:31 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17LQbG-000Mll-00; Fri, 21 Jun 2002 08:45:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: extended communities implementation report References: <200206211538.g5LFcAm57068@merlot.juniper.net> Message-Id: Date: Fri, 21 Jun 2002 08:45:26 -0700 Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Participation in the report means answering a small number of > questions. about each feature and sub-feature and how they were tested to inter-operate with a separate diverse implementation. randy From owner-idr@merit.edu Fri Jun 21 22:44:40 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07945 for ; Fri, 21 Jun 2002 22:44:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58FF69135E; Fri, 21 Jun 2002 22:44:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3037191360; Fri, 21 Jun 2002 22:44: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 34FB89135E for ; Fri, 21 Jun 2002 22:44:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22B8A5DD92; Fri, 21 Jun 2002 22:44:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20309.mail.yahoo.com (web20309.mail.yahoo.com [216.136.226.90]) by segue.merit.edu (Postfix) with SMTP id 7E57B5DD8C for ; Fri, 21 Jun 2002 22:44:39 -0400 (EDT) Message-ID: <20020622024438.91135.qmail@web20309.mail.yahoo.com> Received: from [165.213.0.2] by web20309.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 19:44:38 PDT Date: Fri, 21 Jun 2002 19:44:38 -0700 (PDT) From: Mareline Sheldon Subject: Repost:: Route Reflectors To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Incase this went unnoticed --------------------------- Hi All, What should a correct implmentation for Route Reflector do when it originates a route say by a network command. Should it create a ORIGINATOR field and the CLUSTER_ID in it? My current implmentation is not doing this. Do i need to change it? I ran Agilent router test suite for the conformance tests and it passes all the tests. There is no test in the suite to test self originated routes. Please help. Regards, mareline s. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-idr@merit.edu Fri Jun 21 22:51:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08029 for ; Fri, 21 Jun 2002 22:51:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2091191214; Fri, 21 Jun 2002 22:51:37 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6B0E91360; Fri, 21 Jun 2002 22:51:36 -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 08C0E91214 for ; Fri, 21 Jun 2002 22:51:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC4845DDC9; Fri, 21 Jun 2002 22:51:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 6C74F5DDCE for ; Fri, 21 Jun 2002 22:51:35 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g5M2p0B08795 for ; Fri, 21 Jun 2002 20:51:00 -0600 Message-Id: <200206220251.g5M2p0B08795@tcb.net> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: Repost:: Route Reflectors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 2002 20:50:59 -0600 Sender: owner-idr@merit.edu Precedence: bulk These attributes only apply to *reflected* routes (i.e., not locally originated or EBGP learned routes). -danny > Incase this went unnoticed > --------------------------- > Hi All, > What should a correct implmentation for Route Reflector do when it originates a route say by a > network command. Should it create a ORIGINATOR field and the CLUSTER_ID in it? > > My current implmentation is not doing this. Do i need to change it? > > I ran Agilent router test suite for the conformance tests and it passes all the tests. There > is no test in the suite to test self originated routes. > > Please help. > > Regards, > mareline s. > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com From owner-idr@merit.edu Sat Jun 22 01:03:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10160 for ; Sat, 22 Jun 2002 01:03:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3F2C91234; Sat, 22 Jun 2002 01:03:21 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DDF591360; Sat, 22 Jun 2002 01:03:21 -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 217C391234 for ; Sat, 22 Jun 2002 01:01:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 088DC5DD8F; Sat, 22 Jun 2002 01:01:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tower.partan.com (tower.partan.com [198.6.255.248]) by segue.merit.edu (Postfix) with ESMTP id 8EAA95DD8C for ; Sat, 22 Jun 2002 01:01:58 -0400 (EDT) Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id BAA14425; Sat, 22 Jun 2002 01:01:50 -0400 (EDT) Date: Sat, 22 Jun 2002 01:01:50 -0400 From: Andrew Partan To: "John G. Scudder" Cc: idr@merit.edu, Jeffrey Haas , Pedro Roque Marques Subject: Re: oscillation, total ordering, and always-compare-med Message-ID: <20020622010150.A28187@partan.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jgs@cisco.com on Fri, Jun 07, 2002 at 11:51:58AM -0400 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jun 07, 2002 at 11:51:58AM -0400, John G. Scudder wrote: > By definition, for the MEDs of two ISPs to clash (which does _not_ > happen often), they must be MEDs for the same prefix, and the paths > must be considered equally-desirable by all previous criteria. It can happen a lot - it all depends on where you are and where you are looking. If, say, you are a customer of Sprint and UUNET and you are looking towards other ASs that are also customers of both Sprint and UUNET, then all of those prefixes will be otherwise equal. But the MEDs from Sprint and UUNET may be on completely different scales and not comparable. > If I were still an ISP I think this argument would be sufficient to > convince me to turn on always-compare-med everywhere in my network MFN tried (tries?) to use always-compare-med, but it was a huge pain in the rear - especially when you tried to figure out what to add (or subtract) to the MEDs from one ISP to make them roughly comparable to the MEDs from another ISP. And what you had to do to make them roughly comparable changed from time to time. Very ugly & non-scaleable. --asp From owner-idr@merit.edu Thu Jun 27 06:39:07 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09087 for ; Thu, 27 Jun 2002 06:39:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D0DE912F3; Thu, 27 Jun 2002 06:39:10 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1039F912F4; Thu, 27 Jun 2002 06:39:09 -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 C3E50912F3 for ; Thu, 27 Jun 2002 06:39:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA7B45DEA8; Thu, 27 Jun 2002 06:39:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 351D45DD8E for ; Thu, 27 Jun 2002 06:39:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08901; Thu, 27 Jun 2002 06:38:20 -0400 (EDT) Message-Id: <200206271038.GAA08901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cristallo-bgp-tunnel-attr-00.txt Date: Thu, 27 Jun 2002 06:38:20 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Tunnel Attribute Author(s) : G. Cristallo, J. De Clercq Filename : draft-cristallo-bgp-tunnel-attr-00.txt Pages : 6 Date : 26-Jun-02 This document proposes the Tunnel Attribute, which may be used by a given BGP Speaker to indicate whether it expects to receive all, some, or none of its traffic through a tunnel and the types of tunnel that may be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cristallo-bgp-tunnel-attr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-cristallo-bgp-tunnel-attr-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-cristallo-bgp-tunnel-attr-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. --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: <20020626134556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cristallo-bgp-tunnel-attr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cristallo-bgp-tunnel-attr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626134556.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 GAA10682 for ; Thu, 27 Jun 2002 06:39:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D0DE912F3; Thu, 27 Jun 2002 06:39:10 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1039F912F4; Thu, 27 Jun 2002 06:39:09 -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 C3E50912F3 for ; Thu, 27 Jun 2002 06:39:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA7B45DEA8; Thu, 27 Jun 2002 06:39:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 351D45DD8E for ; Thu, 27 Jun 2002 06:39:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08901; Thu, 27 Jun 2002 06:38:20 -0400 (EDT) Message-Id: <200206271038.GAA08901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cristallo-bgp-tunnel-attr-00.txt Date: Thu, 27 Jun 2002 06:38:20 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Tunnel Attribute Author(s) : G. Cristallo, J. De Clercq Filename : draft-cristallo-bgp-tunnel-attr-00.txt Pages : 6 Date : 26-Jun-02 This document proposes the Tunnel Attribute, which may be used by a given BGP Speaker to indicate whether it expects to receive all, some, or none of its traffic through a tunnel and the types of tunnel that may be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cristallo-bgp-tunnel-attr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-cristallo-bgp-tunnel-attr-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-cristallo-bgp-tunnel-attr-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. --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: <20020626134556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cristallo-bgp-tunnel-attr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cristallo-bgp-tunnel-attr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626134556.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 BAA02507 for ; Sat, 22 Jun 2002 01:03:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3F2C91234; Sat, 22 Jun 2002 01:03:21 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DDF591360; Sat, 22 Jun 2002 01:03:21 -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 217C391234 for ; Sat, 22 Jun 2002 01:01:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 088DC5DD8F; Sat, 22 Jun 2002 01:01:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tower.partan.com (tower.partan.com [198.6.255.248]) by segue.merit.edu (Postfix) with ESMTP id 8EAA95DD8C for ; Sat, 22 Jun 2002 01:01:58 -0400 (EDT) Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id BAA14425; Sat, 22 Jun 2002 01:01:50 -0400 (EDT) Date: Sat, 22 Jun 2002 01:01:50 -0400 From: Andrew Partan To: "John G. Scudder" Cc: idr@merit.edu, Jeffrey Haas , Pedro Roque Marques Subject: Re: oscillation, total ordering, and always-compare-med Message-ID: <20020622010150.A28187@partan.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jgs@cisco.com on Fri, Jun 07, 2002 at 11:51:58AM -0400 Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jun 07, 2002 at 11:51:58AM -0400, John G. Scudder wrote: > By definition, for the MEDs of two ISPs to clash (which does _not_ > happen often), they must be MEDs for the same prefix, and the paths > must be considered equally-desirable by all previous criteria. It can happen a lot - it all depends on where you are and where you are looking. If, say, you are a customer of Sprint and UUNET and you are looking towards other ASs that are also customers of both Sprint and UUNET, then all of those prefixes will be otherwise equal. But the MEDs from Sprint and UUNET may be on completely different scales and not comparable. > If I were still an ISP I think this argument would be sufficient to > convince me to turn on always-compare-med everywhere in my network MFN tried (tries?) to use always-compare-med, but it was a huge pain in the rear - especially when you tried to figure out what to add (or subtract) to the MEDs from one ISP to make them roughly comparable to the MEDs from another ISP. And what you had to do to make them roughly comparable changed from time to time. Very ugly & non-scaleable. --asp 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 WAA28114 for ; Fri, 21 Jun 2002 22:52:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2091191214; Fri, 21 Jun 2002 22:51:37 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6B0E91360; Fri, 21 Jun 2002 22:51:36 -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 08C0E91214 for ; Fri, 21 Jun 2002 22:51:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC4845DDC9; Fri, 21 Jun 2002 22:51:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 6C74F5DDCE for ; Fri, 21 Jun 2002 22:51:35 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g5M2p0B08795 for ; Fri, 21 Jun 2002 20:51:00 -0600 Message-Id: <200206220251.g5M2p0B08795@tcb.net> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: Repost:: Route Reflectors Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 2002 20:50:59 -0600 Sender: owner-idr@merit.edu Precedence: bulk These attributes only apply to *reflected* routes (i.e., not locally originated or EBGP learned routes). -danny > Incase this went unnoticed > --------------------------- > Hi All, > What should a correct implmentation for Route Reflector do when it originates a route say by a > network command. Should it create a ORIGINATOR field and the CLUSTER_ID in it? > > My current implmentation is not doing this. Do i need to change it? > > I ran Agilent router test suite for the conformance tests and it passes all the tests. There > is no test in the suite to test self originated routes. > > Please help. > > Regards, > mareline s. > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.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 WAA27918 for ; Fri, 21 Jun 2002 22:45:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58FF69135E; Fri, 21 Jun 2002 22:44:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3037191360; Fri, 21 Jun 2002 22:44: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 34FB89135E for ; Fri, 21 Jun 2002 22:44:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22B8A5DD92; Fri, 21 Jun 2002 22:44:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20309.mail.yahoo.com (web20309.mail.yahoo.com [216.136.226.90]) by segue.merit.edu (Postfix) with SMTP id 7E57B5DD8C for ; Fri, 21 Jun 2002 22:44:39 -0400 (EDT) Message-ID: <20020622024438.91135.qmail@web20309.mail.yahoo.com> Received: from [165.213.0.2] by web20309.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 19:44:38 PDT Date: Fri, 21 Jun 2002 19:44:38 -0700 (PDT) From: Mareline Sheldon Subject: Repost:: Route Reflectors To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Incase this went unnoticed --------------------------- Hi All, What should a correct implmentation for Route Reflector do when it originates a route say by a network command. Should it create a ORIGINATOR field and the CLUSTER_ID in it? My current implmentation is not doing this. Do i need to change it? I ran Agilent router test suite for the conformance tests and it passes all the tests. There is no test in the suite to test self originated routes. Please help. Regards, mareline s. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.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 LAA05777 for ; Fri, 21 Jun 2002 11:48:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 983469134F; Fri, 21 Jun 2002 11:46:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9CBB91350; Fri, 21 Jun 2002 11:46:14 -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 CD8A69134E for ; Fri, 21 Jun 2002 11:46:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DDF95E923; Fri, 21 Jun 2002 11:45:32 -0400 (EDT) Delivered-To: idr@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 5480C5E8FE for ; Fri, 21 Jun 2002 11:45:31 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17LQbG-000Mll-00; Fri, 21 Jun 2002 08:45:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: extended communities implementation report References: <200206211538.g5LFcAm57068@merlot.juniper.net> Message-Id: Date: Fri, 21 Jun 2002 08:45:26 -0700 Sender: owner-idr@merit.edu Precedence: bulk > Participation in the report means answering a small number of > questions. about each feature and sub-feature and how they were tested to inter-operate with a separate diverse implementation. randy 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 LAA05472 for ; Fri, 21 Jun 2002 11:39:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 010819134B; Fri, 21 Jun 2002 11:39:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC2769134E; Fri, 21 Jun 2002 11:39: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 944999134B for ; Fri, 21 Jun 2002 11:39:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4152F5E797; Fri, 21 Jun 2002 11:38:15 -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 C53D85E7EE for ; Fri, 21 Jun 2002 11:38:10 -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 g5LFcAm57068 for ; Fri, 21 Jun 2002 08:38:10 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200206211538.g5LFcAm57068@merlot.juniper.net> To: idr@merit.edu Subject: extended communities implementation report MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6990.1024673890.1@juniper.net> Date: Fri, 21 Jun 2002 08:38:10 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, As part of advancing BGP Extended Communities, we need to provide an implementation report. With this in mind I am asking folks who implemented BGP Extended Communities and are willing to participate in the report to drop me an e-mail (yakov@juniper.net). Participation in the report means answering a small number of questions. While the report itself is going to be public, the identity of the folks who participate in the report need not be public. Thanks in advance. Yakov. 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 AAA20261 for ; Tue, 18 Jun 2002 00:40:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D273D9125D; Tue, 18 Jun 2002 00:39:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CD599125E; Tue, 18 Jun 2002 00:39:33 -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 D3E6C9125D for ; Tue, 18 Jun 2002 00:39:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD0985DDF5; Tue, 18 Jun 2002 00:39:23 -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 AF9C25DDB5 for ; Tue, 18 Jun 2002 00:39:21 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 2358D18D3F7; Mon, 17 Jun 2002 21:39:21 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id AF0837E6C1; Mon, 17 Jun 2002 21:39:20 -0700 (PDT) To: idr@merit.edu Cc: enke@redback.com Subject: draft-chen-route-oscillation-avoid-00.txt Date: Mon, 17 Jun 2002 21:39:20 -0700 From: Enke Chen Message-Id: <20020618043920.AF0837E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: I have submitted . As I will be away (in a couple of days) from email for a while, I thought that I would post the draft to the mailing list directly so that your comments or questions on the draft can be taken care of in the next couple of days. Regards, -- Enke -------------------------------------------------------------------- Network Working Group Enke Chen Internet Draft Redback Networks Expiration Date: December 2002 BGP Route Oscillation Avoidance for Route Reflection and Confederation draft-chen-route-oscillation-avoid-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract In this document we propose a mechanism and routing setup that would avoid persistent route oscillations and yield consistent route selection in a network using one-level Route Reflection, or using Confederation where routers that participate in inter-member-AS peering are fully meshed. Chen [Page 1] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 3. Introduction As documented in [1], the routing information reduction by BGP Route Reflection [2], or BGP Confederation [3] can result in persistent route oscillations with certain network topologies and routing setup. In this document we propose a mechanism and routing setup that would avoid persistent route oscillations and yield consistent route selection in a network using one-level Route Reflection, or using Confederation where routers that participate in inter-member-AS peering are fully meshed. The proposed mechanism makes use of the mechanisms presented in [4, 5], and works within the current BGP protocol [6, 7] that limits route advertisement to only one path per prefix. 4. Observations on IBGP Updates Currently a BGP speaker follows the basic BGP principle that only the best path is advertised to a BGP peer. Since the best path of a prefix for a BGP speaker is impacted by routes received from internal peers, the route advertised by the speaker is also impacted by routes received from internal peers. This dependency can lead to circular (and possibly excessive) IBGP routing updates, slow convergence, and persistent route oscillation in the worst case. The earlier version of BGP [6] specifies that a BGP speaker should advertise to IBGP its best external route [6, Sect. 9.2.1]. With this approach the route advertisement toward IBGP peers is independent of route advertisement received from IBGP peers. In addition, this approach has the benefit of faster routing convergence compared to the current practice of advertising the best path. If clients of a Route Reflector (RR) adopts this approach, and the RR advertises to other clusters the best path from its clients and external peers (as proposed in [4]), then the advertisement by the RR to other clusters would become independent of routes received from other clusters. It is based on this observation that we formulate a mechanism and routing setup that would avoid route oscillations for one-level route reflection, and for a confederation where routers that participate in inter-member-AS peering are fully meshed. Chen [Page 2] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 5. Mechanism for One-level Route Reflection This mechanism consists of the following procedures and routing setup: a) One-level Route Reflection (all RRs are fully meshed). b) BGP full mesh among clients of a RR. c) Apply the mechanism in [4] for a RR. d) A client advertises its best external route to IBGP peers. Due to c) and d), we claim that with this mechanism and setup the network is free of route oscillation. It is noted that due to d) the best external path advertised by a BGP speaker to an IBGP peer may be different from the overall best path installed in RIB/FIB. Clearly the difference will not cause any forwarding loop when the overall best path is also an external path. When the overall best path for a BGP speaker is from an internal peer, we claim that the best external path for the speaker will not be selected as the best path by any other speakers. The proof for this claim is included in the Appendix. Therefore we conclude that the route selection consistency is maintained with the proposed mechanism. 6. Mechanism for Confederation The mechanism for Confederation consists of the following procedures and routing setup: a) BGP full mesh among routers that participate in inter-member-AS peering. b) BGP full mesh within a member-AS. c) Apply the mechanism in [5] for a router that peers with a neighobring AS in the confederation. d) For a router that does not participate in inter-member-AS peering, it should advertises its best external route to peers within a confederation. We claim that with the mechanism and routing setup a network would Chen [Page 3] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 avoid persistent route oscillations and yield consistent route selection. This claim can be proved similarly. 7. Appendix: Proof of Route Selection Consistency To simplify presentation, let us describe a general route reflection setup as follows: RR1 ---------- RR2 ---------- RR3 --- ... RRn / | | | | / | | | | / | | | | / | | | | C11 C12 C2 C3 ... | | | | | | | | | | (E11) (E12) (E2) (E3) ... In this figure, there are multiple clusters with RR1, RR2, RR3 as the route reflectors. C11 and C12 are clients of RR1. C2 is client of RR2, and C3 is a client of RR3. E11, E12, E2, and E3 are the external paths. Other than for the purpose of illustration, no restrictions are imposed on the route reflection topology including the number of clusters, number of clients, and where and how many external paths are connected. Assume that E2 is the best path among all paths received by RR1 from other clusters, and assume that the EBGP path E11 is not the overall best path for C11. we try to prove that E11 will not be selected as the best path by any other routers. Based on route selection procedures described in [7], E11 can only lose (on C11) to an IBGP path (either E12 or E2) by either LOCAL- PREF, or Origin, or AS-PATH Length, or MED. Due to the natural of these parameters, as long as the overall best path (either E12 or E2) is present on a router, E11 will continue to lose on the router irrespective of any other paths. Due to full IBGP mesh within a cluster, both E12 and E2 are present on all routers within the cluster. So E11 will not be selected as the best path by any router within the cluster. To prove that E11 will not be selected as the best path by a router in another cluster, we need to consider two cases: Chen [Page 4] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 (1) Assume E11 is lost to E12 on C11. Then E11 will not selected as the best path from its clients on RR1, and will not be advertised by RR1 to other clusters. (2) Assume E11 is lost to E2 on C11. As RRs are fully meshed, E2 will be present on all RRs. Thus E11 will not be selected as the best path by any of the RRs. Within the cluster served by RR2, E11 will not be selected by its clients (even if E11 is better than E3 on RR2) as E2 is present. As E2 is present on RR3, E11 will not be advertised to its clients, thus will not be selected as the best path by its clients. 8. Security Considerations This document introduces no new security concerns to BGP or other specifications referenced in this document. 9. Acknowledgments The author would like to thank Jenny Yuan for her review and comments. 10. References [1] McPherson, D., Gill, V., Walton, D., Retana, A., "BGP Persistent Route Oscillation Condition", Work in Progress (draft-ietf-idr- route-oscillation-01), February 2002. [2] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [3] Traina, P., McPherson, D., Scudder, J.. "Autonomous System Con- federations for BGP", RFC 3065, February 2001. [4] Chen, E., "BGP Route Oscillation Reduction with Route Reflection", Work in Progress (draft-chen-rr-oscillation-reduce-01.txt), June 2002. [5] Chen, E., "BGP Route Oscillation Reduction with Confederation", Work in Progress (draft-chen-confed-oscillation-reduce-01.txt), June 2002. [6] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Chen [Page 5] Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002 RFC 1771, March 1995. [7] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress (draft-ietf-idr-bgp4-17), January 2002 11. Author Information Enke Chen Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 Email: enke@redback.com Chen [Page 6] 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 FAA06549 for ; Sat, 8 Jun 2002 05:32:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 60C44912ED; Sat, 8 Jun 2002 05:32:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DDAB912EF; Sat, 8 Jun 2002 05:32:11 -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 AF454912ED for ; Sat, 8 Jun 2002 05:31:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 142DC5DE6A; Sat, 8 Jun 2002 05:31:20 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id B37065DD93 for ; Sat, 8 Jun 2002 05:31:19 -0400 (EDT) Message-ID: <20020608093127.91456.qmail@web20301.mail.yahoo.com> Received: from [165.213.0.2] by web20301.mail.yahoo.com via HTTP; Sat, 08 Jun 2002 02:31:27 PDT Date: Sat, 8 Jun 2002 02:31:27 -0700 (PDT) From: Mareline Sheldon Subject: Route Reflectors Again! To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi All, What should a correct implmentation for Route Reflector do when it originates a route say by a network command. Should it create a ORIGINATOR field and the CLUSTER_ID in it? My current implmentation is not doing this. Do i need to change it? I ran Agilent router test suite for the conformance tests and it passes all the tests. There is no test in the suite to test self originated routes. Please help. Regards, mareline s. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.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 VAA18274 for ; Fri, 7 Jun 2002 21:07:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22E2F91225; Fri, 7 Jun 2002 21:06:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4C59912E9; Fri, 7 Jun 2002 21:06:56 -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 E8DF491225 for ; Fri, 7 Jun 2002 21:06:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DE185DE53; Fri, 7 Jun 2002 21:06:51 -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 E66615DDA4 for ; Fri, 7 Jun 2002 21:06:50 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 16ACC2CDB40; Fri, 7 Jun 2002 18:06:36 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 6C1E915D3C1; Fri, 7 Jun 2002 18:06:29 -0700 (PDT) To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: rr-oscillation-reduce In-Reply-To: Message from Pedro Roque Marques of "Fri, 07 Jun 2002 17:40:03 PDT." <200206080040.g580e3X90108@roque-bsd.juniper.net> Date: Fri, 07 Jun 2002 18:06:29 -0700 From: Enke Chen Message-Id: <20020608010630.6C1E915D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Fri, 7 Jun 2002 17:40:03 -0700 (PDT) > Message-Id: <200206080040.g580e3X90108@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: rr-oscillation-reduce > In-Reply-To: <20020608002506.4B8C515D3C1@popserv1.redback.com> > References: > <200206080001.g5801jV90037@roque-bsd.juniper.net> > <20020608002506.4B8C515D3C1@popserv1.redback.com> > > Enke Chen writes: > > > The text in the draft talks about a RR (toward other clusters), and > > it does not suggest any change to a client. So a client will > > withdraw its best path only if its external best does not survive > > through the route selection. It will not withdraw if its external > > path remains as the best. > > Ok... would you consider including a description of why this is > necessary and/or sufficient to avoid oscilation or certain types of > oscillation. Sure. > > > Understood. However, it seems to me the implication on the traffic > > behavior (during routing re-converging) should be no different from > > doing closest-exit routing in which case multiple alternate paths > > are present. As I understand, quite a few large providers have been > > doing closest-exit routing for years. > > I believe i disagree: > > If you have RRa and RRb, where RRa is advertising a route that > it is not installed in it's routing table, it is actually prefering > RRb route. When RRb (or the cluster) looses it's best external path it > may proceed to forward traffic to RRa which will then loop it back to > RRb. > Ok. > This regardless if you are doing closest-exit or not... btw: if you > are doing pure closest-exit this entire discussion is irrelevant, > correct ? Right. As I remember, the providers typically only does closest-exit routing toward other providers, and they typically honors MEDs from their customers. So it was (and still is?) a mixed routing. -- Enke 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 UAA17269 for ; Fri, 7 Jun 2002 20:40:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E141912E2; Fri, 7 Jun 2002 20:40:02 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21279912E9; Fri, 7 Jun 2002 20:40:02 -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 D4E9B912E2 for ; Fri, 7 Jun 2002 20:40:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 163A75DE13; Fri, 7 Jun 2002 20:39:56 -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 B9BEC5DDA4 for ; Fri, 7 Jun 2002 20:39:55 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g580e3m29972; Fri, 7 Jun 2002 17:40:03 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g580e3X90108; Fri, 7 Jun 2002 17:40:03 -0700 (PDT) (envelope-from roque) Date: Fri, 7 Jun 2002 17:40:03 -0700 (PDT) Message-Id: <200206080040.g580e3X90108@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: rr-oscillation-reduce In-Reply-To: <20020608002506.4B8C515D3C1@popserv1.redback.com> References: <200206080001.g5801jV90037@roque-bsd.juniper.net> <20020608002506.4B8C515D3C1@popserv1.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Enke Chen writes: > The text in the draft talks about a RR (toward other clusters), and > it does not suggest any change to a client. So a client will > withdraw its best path only if its external best does not survive > through the route selection. It will not withdraw if its external > path remains as the best. Ok... would you consider including a description of why this is necessary and/or sufficient to avoid oscilation or certain types of oscillation. > Understood. However, it seems to me the implication on the traffic > behavior (during routing re-converging) should be no different from > doing closest-exit routing in which case multiple alternate paths > are present. As I understand, quite a few large providers have been > doing closest-exit routing for years. I believe i disagree: If you have RRa and RRb, where RRa is advertising a route that it is not installed in it's routing table, it is actually prefering RRb route. When RRb (or the cluster) looses it's best external path it may proceed to forward traffic to RRa which will then loop it back to RRb. This regardless if you are doing closest-exit or not... btw: if you are doing pure closest-exit this entire discussion is irrelevant, correct ? 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 UAA16644 for ; Fri, 7 Jun 2002 20:25:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2121B912DC; Fri, 7 Jun 2002 20:25:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4A1B912E2; Fri, 7 Jun 2002 20:25: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 E51CA912DC for ; Fri, 7 Jun 2002 20:25:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 394A05DE13; Fri, 7 Jun 2002 20:25:07 -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 EA69B5DDA4 for ; Fri, 7 Jun 2002 20:25:06 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 5AA6A18D3FB; Fri, 7 Jun 2002 17:25:14 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 4B8C515D3C1; Fri, 7 Jun 2002 17:25:04 -0700 (PDT) To: Pedro Roque Marques Cc: idr@merit.edu, enke@redback.com Subject: Re: rr-oscillation-reduce In-Reply-To: Message from Pedro Roque Marques of "Fri, 07 Jun 2002 17:01:45 PDT." <200206080001.g5801jV90037@roque-bsd.juniper.net> Date: Fri, 07 Jun 2002 17:25:03 -0700 From: Enke Chen Message-Id: <20020608002506.4B8C515D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Fri, 7 Jun 2002 17:01:45 -0700 (PDT) > Message-Id: <200206080001.g5801jV90037@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: rr-oscillation-reduce > In-Reply-To: <20020607231142.5A2617E6C1@popserv3.redback.com> > References: > <200206061844.g56IiGr86811@roque-bsd.juniper.net> > <20020607231142.5A2617E6C1@popserv3.redback.com> > X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid > > Enke Chen writes: > > > Hi, Pedro: Thanks for your comments on the proposal. > > >> Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) Message-Id: > >> <200206061844.g56IiGr86811@roque-bsd.juniper.net> From: Pedro Roque > >> Marques To: enke@redback.com Cc: idr@merit.edu > >> Subject: rr-oscillation-reduce > >> > >> Enke, A few questions/comments on your proposal... > >> > >> The gist of it is to advertise 'the best external' (i.e. route from > >> rr-clients) to the rest of the mesh when the best path is internal > >> (i.e. received from a ibgp mesh router). > >> > >> 1) Why do you limit this procedure to RRs/Confeds... ? > > > Always advertising "the external best" by all border routers can > > cause significant increase in the number of paths (and memory usage) > > in a network. The proposal in draft-chen-rr-oscillation-reduce is > > trying to reduce/eliminate most the route oscillations by > > advertising the minimal set of additional routing information (that > > is, at most one path). By "at most one path" I mean that a RR may > > not advertise a path to other clusters even when clients have > > external paths. For example, after the RR advertises the overall > > best (from another cluster) to a client, the client would withdraw > > its advertisement to the RR if the client does not select its > > external path as the best. If we allowed the client to always > > advertise "the best external" path, the client would not > > withdraw. Then the RR and the rest of the network would be stuck > > with the additional path that are not useful in route > > selection. Please note that the additional path would not be present > > in the netowrk even in the case of full IBGP mesh (with advertising > > only the best). > > I'm missing something here... > > The draft says that the proposed modification is: > > "When the client best path for a RR exists, and the overall > best path for the RR is from a non-client IBGP peer, the RR > may advertise the client best path to all non-client IBGP > peers." > > It seems to me that by your own admission this is a no op, since as > you correctly point out the client will subsequently withrawn it's > best path. The text in the draft talks about a RR (toward other clusters), and it does not suggest any change to a client. So a client will withdraw its best path only if its external best does not survive through the route selection. It will not withdraw if its external path remains as the best. > > >> 2) Advertising the 'best external' route as always had the issue > >> of traffic loops (i believe the reason it hasn't been implemented > >> as specified in 1771 originally). You don't seem to address this in > >> your draft... do you believe it is not relevant... or is there some > >> other solution to this problem... > > > I do not know that part of the implementation history. I can only > > speculate that the concern of additional memory and implementation > > simplicity/complexity may have played a larger role in the decision. > > >> Whereas today such traffic would be blackholed by B... while it is > >> true that current routers are not as susceptible to rollover and > >> die when presented with looping traffic as opposed to software > >> forwarding based boxes of 5+ years ago it is likely that the > >> resulting link congestion is still a relevant factor.... comments ? > > > So I do not expect the > > convergence time to deviate much from today's. > > Yes, i believe that the convergence time will be the same. However the > fundamental difference i'm point out is that during the convergence > time traffic will loop instead of being blackholed as it is today. > > That would apear to be an implication that is necessary to consider. Understood. However, it seems to me the implication on the traffic behavior (during routing re-converging) should be no different from doing closest-exit routing in which case multiple alternate paths are present. As I understand, quite a few large providers have been doing closest-exit routing for years. -- Enke 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 UAA15771 for ; Fri, 7 Jun 2002 20:02:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B3616912E1; Fri, 7 Jun 2002 20:01:50 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 848E7912DC; Fri, 7 Jun 2002 20:01:50 -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 90979912E1 for ; Fri, 7 Jun 2002 20:01:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C84365DDBF; Fri, 7 Jun 2002 20:01:37 -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 770A65DDA4 for ; Fri, 7 Jun 2002 20:01:37 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g5801jm28116; Fri, 7 Jun 2002 17:01:45 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g5801jV90037; Fri, 7 Jun 2002 17:01:45 -0700 (PDT) (envelope-from roque) Date: Fri, 7 Jun 2002 17:01:45 -0700 (PDT) Message-Id: <200206080001.g5801jV90037@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: rr-oscillation-reduce In-Reply-To: <20020607231142.5A2617E6C1@popserv3.redback.com> References: <200206061844.g56IiGr86811@roque-bsd.juniper.net> <20020607231142.5A2617E6C1@popserv3.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Enke Chen writes: > Hi, Pedro: Thanks for your comments on the proposal. >> Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) Message-Id: >> <200206061844.g56IiGr86811@roque-bsd.juniper.net> From: Pedro Roque >> Marques To: enke@redback.com Cc: idr@merit.edu >> Subject: rr-oscillation-reduce >> >> Enke, A few questions/comments on your proposal... >> >> The gist of it is to advertise 'the best external' (i.e. route from >> rr-clients) to the rest of the mesh when the best path is internal >> (i.e. received from a ibgp mesh router). >> >> 1) Why do you limit this procedure to RRs/Confeds... ? > Always advertising "the external best" by all border routers can > cause significant increase in the number of paths (and memory usage) > in a network. The proposal in draft-chen-rr-oscillation-reduce is > trying to reduce/eliminate most the route oscillations by > advertising the minimal set of additional routing information (that > is, at most one path). By "at most one path" I mean that a RR may > not advertise a path to other clusters even when clients have > external paths. For example, after the RR advertises the overall > best (from another cluster) to a client, the client would withdraw > its advertisement to the RR if the client does not select its > external path as the best. If we allowed the client to always > advertise "the best external" path, the client would not > withdraw. Then the RR and the rest of the network would be stuck > with the additional path that are not useful in route > selection. Please note that the additional path would not be present > in the netowrk even in the case of full IBGP mesh (with advertising > only the best). I'm missing something here... The draft says that the proposed modification is: "When the client best path for a RR exists, and the overall best path for the RR is from a non-client IBGP peer, the RR may advertise the client best path to all non-client IBGP peers." It seems to me that by your own admission this is a no op, since as you correctly point out the client will subsequently withrawn it's best path. >> 2) Advertising the 'best external' route as always had the issue >> of traffic loops (i believe the reason it hasn't been implemented >> as specified in 1771 originally). You don't seem to address this in >> your draft... do you believe it is not relevant... or is there some >> other solution to this problem... > I do not know that part of the implementation history. I can only > speculate that the concern of additional memory and implementation > simplicity/complexity may have played a larger role in the decision. >> Whereas today such traffic would be blackholed by B... while it is >> true that current routers are not as susceptible to rollover and >> die when presented with looping traffic as opposed to software >> forwarding based boxes of 5+ years ago it is likely that the >> resulting link congestion is still a relevant factor.... comments ? > So I do not expect the > convergence time to deviate much from today's. Yes, i believe that the convergence time will be the same. However the fundamental difference i'm point out is that during the convergence time traffic will loop instead of being blackholed as it is today. That would apear to be an implication that is necessary to consider. 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 TAA14029 for ; Fri, 7 Jun 2002 19:12:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34C8B912DC; Fri, 7 Jun 2002 19:11:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01DB3912DF; Fri, 7 Jun 2002 19:11:40 -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 D6044912DC for ; Fri, 7 Jun 2002 19:11:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DD675DE65; Fri, 7 Jun 2002 19:11:35 -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 9A6705DDA4 for ; Fri, 7 Jun 2002 19:11:34 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 5F9995E45B; Fri, 7 Jun 2002 16:11:42 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 5A2617E6C1; Fri, 7 Jun 2002 16:11:42 -0700 (PDT) To: Pedro Roque Marques Cc: idr@merit.edu, enke@redback.com Subject: Re: rr-oscillation-reduce In-Reply-To: Message from Pedro Roque Marques of "Thu, 06 Jun 2002 11:44:16 PDT." <200206061844.g56IiGr86811@roque-bsd.juniper.net> Date: Fri, 07 Jun 2002 16:11:42 -0700 From: Enke Chen Message-Id: <20020607231142.5A2617E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Pedro: Thanks for your comments on the proposal. > Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) > Message-Id: <200206061844.g56IiGr86811@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: enke@redback.com > Cc: idr@merit.edu > Subject: rr-oscillation-reduce > > Enke, > A few questions/comments on your proposal... > > The gist of it is to advertise 'the best external' (i.e. route from > rr-clients) to the rest of the mesh when the best path is internal > (i.e. received from a ibgp mesh router). > > 1) Why do you limit this procedure to RRs/Confeds... ? Always advertising "the external best" by all border routers can cause significant increase in the number of paths (and memory usage) in a network. The proposal in draft-chen-rr-oscillation-reduce is trying to reduce/eliminate most the route oscillations by advertising the minimal set of additional routing information (that is, at most one path). By "at most one path" I mean that a RR may not advertise a path to other clusters even when clients have external paths. For example, after the RR advertises the overall best (from another cluster) to a client, the client would withdraw its advertisement to the RR if the client does not select its external path as the best. If we allowed the client to always advertise "the best external" path, the client would not withdraw. Then the RR and the rest of the network would be stuck with the additional path that are not useful in route selection. Please note that the additional path would not be present in the netowrk even in the case of full IBGP mesh (with advertising only the best). > > 2) Advertising the 'best external' route as always had the issue of > traffic loops (i believe the reason it hasn't been implemented as > specified in 1771 originally). You don't seem to address this in your > draft... do you believe it is not relevant... or is there some other > solution to this problem... I do not know that part of the implementation history. I can only speculate that the concern of additional memory and implementation simplicity/complexity may have played a larger role in the decision. > > To be more specific, if you have rtrs A, B, such that B has the best > path at t0, and A a valid external path, when at t1 B's external path > gets withrawn, traffic is almost guaranteed to loop until B's > advertisement reaches A. This can be potentially exacerbated by > mechanisms such as min advertisement interval. > > Whereas today such traffic would be blackholed by B... while it is > true that current routers are not as susceptible to rollover and die > when presented with looping traffic as opposed to software forwarding > based boxes of 5+ years ago it is likely that the resulting link > congestion is still a relevant factor.... comments ? Your comparison makes a lot of sense. With the proposal a RR advertises the cleints' best that survives through the route selection (see comment on 1)). It follows the current practice/spirit of advertising the best path. So I do not expect the convergence time to deviate much from today's. -- Enke 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 OAA03601 for ; Fri, 7 Jun 2002 14:11:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A533912C3; Fri, 7 Jun 2002 14:10:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09A6D912D3; Fri, 7 Jun 2002 14:10: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 B3C5F912C3 for ; Fri, 7 Jun 2002 14:10:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1C8A5DDF1; Fri, 7 Jun 2002 14:10:48 -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 9C2B45DDEA for ; Fri, 7 Jun 2002 14:10:48 -0400 (EDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 74D07F2C52; Fri, 7 Jun 2002 11:10:56 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 578A6979C1; Fri, 7 Jun 2002 11:10:52 -0700 (PDT) To: "Abarbanel, Benjamin" Cc: Alvaro Retana , idr@merit.edu, enke@redback.com Subject: Re: I-BGP Oscillations In-Reply-To: Message from "Abarbanel, Benjamin" of "Fri, 07 Jun 2002 13:41:23 EDT." <39469E08BD83D411A3D900204840EC5582272D@vie-msgusr-01.dc.fore.com> Date: Fri, 07 Jun 2002 11:10:52 -0700 From: Enke Chen Message-Id: <20020607181054.578A6979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Ben, It seems to me that folks are resisting the idea of "IBGP route dampening" (which has too many issues). I do not think that folks are resisting the idea of a "dampening-like" mechanism for detectig IBGP route flap/oscillation (without actually dampening these routes). -- Enke > Message-ID: <39469E08BD83D411A3D900204840EC5582272D@vie-msgusr-01.dc.fore.com> > From: "Abarbanel, Benjamin" > To: "'Enke Chen'" , > Alvaro Retana > Cc: idr@merit.edu > Subject: RE: I-BGP Oscillations > Date: Fri, 7 Jun 2002 13:41:23 -0400 > > Horrayy Enke, Thank you. I dont know why I was getting such resistance to > this method. > > Ben > > -----Original Message----- > From: Enke Chen [mailto:enke@redback.com] > Sent: Friday, June 07, 2002 1:24 PM > To: Alvaro Retana > Cc: idr@merit.edu; enke@redback.com > Subject: Re: I-BGP Oscillations > > > > Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) > > From: Alvaro Retana > > To: "'Pedro Roque Marques'" , > > "Abarbanel, Benjamin" > > Cc: Anindya Basu , > > Subject: RE: I-BGP Oscillations > > In-Reply-To: > <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> > > Message-ID: > > MIME-Version: 1.0 > > [snip] > > > > > -> If we come up with a decent detection mechanism it would be so much > > -> simpler just to reduce the rate of oscilation. > > > > "reducing the rate of oscillation" sounds to me like dampening. =:-) > > Again, that doesn't solve the problem, it just masks it, potentially > > making the periods of 'incorrect' routing longer (as well as the periods > > of correct routing, of course)... > > > > > > -> Note that the answer 'ibgp dampening' that is certain to pop up in > > -> peoples minds by association is a bit misleading. > > > > I agree that iBGP dampening is not the answer. However, a > > "dampening-like" (no penalties) mechanism to detect the oscillation and > > then act on it, would work. Obviously, the oscillation characteristics of > > a MED churn are not the same as the ones of "normal" flapping. > > Regarding a "dampening-like" mechanism (but no dampening) for IBGP route > oscillation detection, I would like to point out that not only is such > a mechanism a good idea, it is also feasible to implement. In fact, the > mechanism has been implemented and in production release on Redback SE800 > for a while. The command "sho bgp route flap-statistics internal" displays > the IBGP routes that are flapping, and their frequencies. Then one can > look closely at the ones with the high flap frequencies to see if they > are indeed experiencing the "persistent route oscillation". > > -- Enke 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 NAA02967 for ; Fri, 7 Jun 2002 13:54:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 61D7D912FF; Fri, 7 Jun 2002 13:51:43 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32DAE912F9; Fri, 7 Jun 2002 13:51:43 -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 25933912F0 for ; Fri, 7 Jun 2002 13:49:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61EC55DE5D; Fri, 7 Jun 2002 13:49:44 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 1DE5C5DE53 for ; Fri, 7 Jun 2002 13:49:44 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57HnnHt006052; Fri, 7 Jun 2002 10:49:50 -0700 (PDT) Date: Fri, 7 Jun 2002 13:49:49 -0400 (EDT) From: Alvaro Retana To: "Abarbanel, Benjamin" Cc: "'Pedro Roque Marques'" , Anindya Basu , Subject: RE: I-BGP Oscillations In-Reply-To: <39469E08BD83D411A3D900204840EC55822726@vie-msgusr-01.dc.fore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Fri, 7 Jun 2002, Abarbanel, Benjamin wrote: Ben: -> Please review proposed workaround solutions sited in section 4.3 (item -> 2, 3) and section 5.2 (item 1,2) of -> draft-ietf-idr-route-oscillation-01.txt. I dont think what I am -> proposing is very far from these solutions being done automatically by -> the MED induced route oscillation detection mechanism. I think someone else mentioned before that the potential workarounds in the idr-route-oscillation draft were not considered acceptable by network operators -- at least not at the time we first brought the issue up at IETF and NANOG... -> -> Note that the answer 'ibgp dampening' that is certain to pop up in -> -> peoples minds by association is a bit misleading. -> -> > I agree that iBGP dampening is not the answer. However, a -> > "dampening-like" (no penalties) mechanism to detect the oscillation and -> > then act on it, would work. Obviously, the oscillation characteristics of -> > a MED churn are not the same as the ones of "normal" flapping. -> -> Can you be more specific on what you mean by "MED churn are not the -> same as the ones of "normal" flapping:. In short... For the MED churn to occur, you need a group of routes to meet the "requirements" (they're changing because of each other)...in "normal" flapping, each route flaps independently (even though they may all flap for the same reason: a peer reset, for example). -> > We had run some numbers a while back (maybe a year and a half ago) on data -> > from backbones experiencing the MED churn, and found that only about 1-2% -> > of the routes were **candidates** to oscillate. IMHO, the state and extra -> > information is not significant. ;-) -> -> what was the frequency of oscillation? Because of our implementation, close to one minute. ;-) But when we saw it in a multi-vendor backbone, the frequency varied (mostly faster). -> What was the impact to the router that you tested? Also, what was the -> memory consumption levels during this period of instability? They were live routers. ;-) No visible changes in performance, memory utilization, etc.. Some transient loops and constantly changing routes was what brought our attention to it. :-) :-) Alvaro. 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 NAA02533 for ; Fri, 7 Jun 2002 13:42:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A996D912CA; Fri, 7 Jun 2002 13:41:36 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D090912CD; Fri, 7 Jun 2002 13:41:36 -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 8BB5D912CA for ; Fri, 7 Jun 2002 13:41:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE6085DE5F; Fri, 7 Jun 2002 13:41:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4538A5DDF1 for ; Fri, 7 Jun 2002 13:41:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19806; Fri, 7 Jun 2002 13:41:28 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17087; Fri, 7 Jun 2002 13:41:25 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 13:41:24 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582272D@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Enke Chen'" , Alvaro Retana Cc: idr@merit.edu Subject: RE: I-BGP Oscillations Date: Fri, 7 Jun 2002 13:41:23 -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 Horrayy Enke, Thank you. I dont know why I was getting such resistance to this method. Ben -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Friday, June 07, 2002 1:24 PM To: Alvaro Retana Cc: idr@merit.edu; enke@redback.com Subject: Re: I-BGP Oscillations > Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) > From: Alvaro Retana > To: "'Pedro Roque Marques'" , > "Abarbanel, Benjamin" > Cc: Anindya Basu , > Subject: RE: I-BGP Oscillations > In-Reply-To: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> > Message-ID: > MIME-Version: 1.0 [snip] > > -> If we come up with a decent detection mechanism it would be so much > -> simpler just to reduce the rate of oscilation. > > "reducing the rate of oscillation" sounds to me like dampening. =:-) > Again, that doesn't solve the problem, it just masks it, potentially > making the periods of 'incorrect' routing longer (as well as the periods > of correct routing, of course)... > > > -> Note that the answer 'ibgp dampening' that is certain to pop up in > -> peoples minds by association is a bit misleading. > > I agree that iBGP dampening is not the answer. However, a > "dampening-like" (no penalties) mechanism to detect the oscillation and > then act on it, would work. Obviously, the oscillation characteristics of > a MED churn are not the same as the ones of "normal" flapping. Regarding a "dampening-like" mechanism (but no dampening) for IBGP route oscillation detection, I would like to point out that not only is such a mechanism a good idea, it is also feasible to implement. In fact, the mechanism has been implemented and in production release on Redback SE800 for a while. The command "sho bgp route flap-statistics internal" displays the IBGP routes that are flapping, and their frequencies. Then one can look closely at the ones with the high flap frequencies to see if they are indeed experiencing the "persistent route oscillation". -- Enke 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 NAA01938 for ; Fri, 7 Jun 2002 13:24:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1756912C3; Fri, 7 Jun 2002 13:24:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE78F912CA; Fri, 7 Jun 2002 13:24:21 -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 C763E912C3 for ; Fri, 7 Jun 2002 13:24:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06E875DE65; Fri, 7 Jun 2002 13:24:16 -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 A67D55DE90 for ; Fri, 7 Jun 2002 13:24:15 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 37F0B2CDB59; Fri, 7 Jun 2002 10:24:23 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id D6B2215D3C1; Fri, 7 Jun 2002 10:24:19 -0700 (PDT) To: Alvaro Retana Cc: idr@merit.edu, enke@redback.com Subject: Re: I-BGP Oscillations In-Reply-To: Message from Alvaro Retana of "Thu, 06 Jun 2002 21:54:38 EDT." Date: Fri, 07 Jun 2002 10:24:19 -0700 From: Enke Chen Message-Id: <20020607172420.D6B2215D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) > From: Alvaro Retana > To: "'Pedro Roque Marques'" , > "Abarbanel, Benjamin" > Cc: Anindya Basu , > Subject: RE: I-BGP Oscillations > In-Reply-To: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> > Message-ID: > MIME-Version: 1.0 [snip] > > -> If we come up with a decent detection mechanism it would be so much > -> simpler just to reduce the rate of oscilation. > > "reducing the rate of oscillation" sounds to me like dampening. =:-) > Again, that doesn't solve the problem, it just masks it, potentially > making the periods of 'incorrect' routing longer (as well as the periods > of correct routing, of course)... > > > -> Note that the answer 'ibgp dampening' that is certain to pop up in > -> peoples minds by association is a bit misleading. > > I agree that iBGP dampening is not the answer. However, a > "dampening-like" (no penalties) mechanism to detect the oscillation and > then act on it, would work. Obviously, the oscillation characteristics of > a MED churn are not the same as the ones of "normal" flapping. Regarding a "dampening-like" mechanism (but no dampening) for IBGP route oscillation detection, I would like to point out that not only is such a mechanism a good idea, it is also feasible to implement. In fact, the mechanism has been implemented and in production release on Redback SE800 for a while. The command "sho bgp route flap-statistics internal" displays the IBGP routes that are flapping, and their frequencies. Then one can look closely at the ones with the high flap frequencies to see if they are indeed experiencing the "persistent route oscillation". -- Enke 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 MAA29142 for ; Fri, 7 Jun 2002 12:10:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D3CB912CD; Fri, 7 Jun 2002 12:07:08 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06682912D1; Fri, 7 Jun 2002 12:07:07 -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 8D723912CD for ; Fri, 7 Jun 2002 12:07:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5BE45DE5A; Fri, 7 Jun 2002 12:06:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 0A6825DE55 for ; Fri, 7 Jun 2002 12:06:58 -0400 (EDT) Received: from [192.168.42.10] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA25401; Fri, 7 Jun 2002 12:07:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: Date: Fri, 7 Jun 2002 11:51:58 -0400 To: idr@merit.edu From: "John G. Scudder" Subject: oscillation, total ordering, and always-compare-med Cc: Jeffrey Haas , Pedro Roque Marques Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk A couple of replies, aggregated. --John At 4:14 PM -0400 6/6/02, Jeffrey Haas wrote: >Without taking this to the more complicated cases, the argument that >the operational community makes is that "always-compare-med" is a form >of denial of service. "Denial of service" overstates the case. By definition, for the MEDs of two ISPs to clash (which does _not_ happen often), they must be MEDs for the same prefix, and the paths must be considered equally-desirable by all previous criteria. If one defines "service" as "the delivery of packets to the network depicted by that prefix", then it's clearly not being denied in that case -- one equally-desirable path is merely being picked over another. The argument may even be made that the policy of the prefix owner is not even being subverted, because if the prefix owner preferred to receive traffic via one or the other of the ISPs in question, they'd pad their AS path in one of the directions, and in doing so would render the MED question moot. If I were still an ISP I think this argument would be sufficient to convince me to turn on always-compare-med everywhere in my network (perhaps after auditing my routing tables). But I'm not, so there you have it. Certainly always-compare-med changes MED semantics, but "denial of service" it ain't. At 11:55 AM -0700 6/6/02, Pedro Roque Marques wrote: >There is a simple answer, which is to address the current MED >behaviour. MEDs as current specified make it so that there isn't >possible to establish a global ordering between BGP paths. The >protocol when originally designed implicit required such property. > >Given a global ordering of paths within an ibgp mesh no persistent >osciallation will occur and the protocol as originally specified will >be stable. Yep. And of course always-compare-med gives us total ordering (at the admitted cost of changing the MED semantics). >In order to achieve this, of course, one needs to encounter an >solution to the problem that MEDs are supposed to solve. By this I take it you are saying one needs a solution which (a) gives us total ordering over all BGP routes, (b) scales as well as current (hierarchical) IBGP and (c) gives us the exact semantics MEDs are intended to provide (i.e., the semantics they do provide in a full IBGP mesh). I would be extremely surprised (though happy) if there exists a solution which satisfies all these criteria. Perhaps one of the researchers on the list would like to do a proof of this statement for their next SIGCOMM paper. (While a proof would be nice, the fact that nobody's done it yet is at least some evidence.) >One possible solution is to mandate 'always-compare-med' behaviour >which will make paths have a global ordering. I remember there was >strong reaction against this from the operational folks but i'm not >quite sure what the arguments where (would apreciate if somebody could >refresh my memory). As many folks already know, personally always-compare-med is my preferred solution because instead of trying to band-aid over the bug in the protocol, it eliminates it in a clean, cheap and efficient manner. However, as Pedro says there has been strong resistance to the idea from operational folks, hence the current round of discussion. Also, it bears repeating that the always-compare-med solution can be deployed _now_ by anyone who wants to, since many (most? all?) vendors already provide an always-compare-med knob. So for anyone who is prepared to use it, a solution exists today. 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 MAA28837 for ; Fri, 7 Jun 2002 12:02:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D780912CA; Fri, 7 Jun 2002 12:00:38 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A8C5912CC; Fri, 7 Jun 2002 12:00:38 -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 6525E912CA for ; Fri, 7 Jun 2002 12:00:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E69F35DE55; Fri, 7 Jun 2002 12:00:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 6B79C5DE52 for ; Fri, 7 Jun 2002 12:00:30 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g57G06T07746 for ; Fri, 7 Jun 2002 10:00:06 -0600 Message-Id: <200206071600.g57G06T07746@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Fri, 07 Jun 2002 10:00:06 -0600 Sender: owner-idr@merit.edu Precedence: bulk > Can you site in size of topology and number of routes, how many more > routes would a peer experience if we use the solution to stop oscillation > by broadcasting non-best paths to peers as was defined by Wilfond and > others? I can provide any interested with real numbers from a real network employing BGP RR. If you're interested contact me offline. -danny 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 LAA27205 for ; Fri, 7 Jun 2002 11:13:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 320A4912C3; Fri, 7 Jun 2002 11:13:03 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F182A912C4; Fri, 7 Jun 2002 11:13:02 -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 1838F912C3 for ; Fri, 7 Jun 2002 11:13:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47E845DE52; Fri, 7 Jun 2002 11:12:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C40965DE4F for ; Fri, 7 Jun 2002 11:12:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03708; Fri, 7 Jun 2002 11:13:02 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13937; Fri, 7 Jun 2002 11:13:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 11:13:02 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822727@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'danny@tcb.net'" , idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Fri, 7 Jun 2002 11:13:01 -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 Danny: Can you site in size of topology and number of routes, how many more routes would a peer experience if we use the solution to stop oscillation by broadcasting non-best paths to peers as was defined by Wilfond and others? Ben -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Thursday, June 06, 2002 5:59 PM To: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > >> Speaking as a SP (today), I'll gladly provide BGP table access to > >> anyone interested in doing this. > > Or get any number of them from archive.routeviews.org. Actually, I was speaking more along the lines of a full analysis, where they'd get all the paths from all the EBGP-speaking routers in my AS, and given the routing topology, flag where issues will/may occur and determine the impact of a given proposal. (Then I could use the code for a few other things I need to do :-) -danny 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 LAA27116 for ; Fri, 7 Jun 2002 11:11:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 999E89122B; Fri, 7 Jun 2002 11:10:19 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F92C912C3; Fri, 7 Jun 2002 11:10: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 8BF699122B for ; Fri, 7 Jun 2002 11:10:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD3B55DE53; Fri, 7 Jun 2002 11:10:13 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 40C045DE52 for ; Fri, 7 Jun 2002 11:10:13 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03365; Fri, 7 Jun 2002 11:10:18 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13085; Fri, 7 Jun 2002 11:10:17 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 11:10:12 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822726@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Alvaro Retana'" , "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: Anindya Basu , idr@merit.edu Subject: RE: I-BGP Oscillations Date: Fri, 7 Jun 2002 11:10:10 -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 -> Why not, IBGP Dampening is what I have been thinking aboute since -> this problem was first exposed to IETF.... > The problem with dampening is that you're just hiding the churn (making it > slower), not fixing it. :-( By dampening the route that is oscillation due to MED in a certain configuration. You either remove the MED attribute affecting the decision process and thus allow other routes to get preference or you completely remove the route from being a candidate if its oscillating too much. Thus you totally disable the oscillation and churn condition. Broadcasting other routes to stop an oscillating route might affect the decision process and stop the churn, but its like hitting a nail with a sledge hammer. Why should we expose the network to more redundant routes? I am sure, we will have many more legitimate opportunities to do so, but not to stop a bug in the protocol. Please review proposed workaround solutions sited in section 4.3 (item 2, 3) and section 5.2 (item 1,2) of draft-ietf-idr-route-oscillation-01.txt. I dont think what I am proposing is very far from these solutions being done automatically by the MED induced route oscillation detection mechanism. -> Note that the answer 'ibgp dampening' that is certain to pop up in -> peoples minds by association is a bit misleading. > I agree that iBGP dampening is not the answer. However, a > "dampening-like" (no penalties) mechanism to detect the oscillation and > then act on it, would work. Obviously, the oscillation characteristics of > a MED churn are not the same as the ones of "normal" flapping. Can you be more specific on what you mean by "MED churn are not the same as the ones of "normal" flapping:. > We had run some numbers a while back (maybe a year and a half ago) on data > from backbones experiencing the MED churn, and found that only about 1-2% > of the routes were **candidates** to oscillate. IMHO, the state and extra > information is not significant. ;-) what was the frequency of oscillation? What was the impact to the router that you tested? Also, what was the memory consumption levels during this period of instability? Thanks, Ben 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 VAA27446 for ; Thu, 6 Jun 2002 21:55:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B3159121C; Thu, 6 Jun 2002 21:54:39 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1534E912E6; Thu, 6 Jun 2002 21:54:38 -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 215EB9121C for ; Thu, 6 Jun 2002 21:54:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CFAA5DE37; Thu, 6 Jun 2002 21:54:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id B2ECB5DDA2 for ; Thu, 6 Jun 2002 21:54:32 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g571scHt019075; Thu, 6 Jun 2002 18:54:38 -0700 (PDT) Date: Thu, 6 Jun 2002 21:54:38 -0400 (EDT) From: Alvaro Retana To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: Anindya Basu , Subject: RE: I-BGP Oscillations In-Reply-To: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Thu, 6 Jun 2002, Abarbanel, Benjamin wrote: -> Why not, IBGP Dampening is what I have been thinking aboute since -> this problem was first exposed to IETF.... The problem with dampening is that you're just hiding the churn (making it slower), not fixing it. :-( -> From: Pedro Roque Marques [mailto:roque@juniper.net] ... -> > One way to address this issue would be to *only* send out extra -> > routes when necessary. In other words, if an oscillation involving -> > I-BGP routes is detected, extra information for only that route -> > could be sent out. -> -> If we come up with a decent detection mechanism it would be so much -> simpler just to reduce the rate of oscilation. "reducing the rate of oscillation" sounds to me like dampening. =:-) Again, that doesn't solve the problem, it just masks it, potentially making the periods of 'incorrect' routing longer (as well as the periods of correct routing, of course)... -> Note that the answer 'ibgp dampening' that is certain to pop up in -> peoples minds by association is a bit misleading. I agree that iBGP dampening is not the answer. However, a "dampening-like" (no penalties) mechanism to detect the oscillation and then act on it, would work. Obviously, the oscillation characteristics of a MED churn are not the same as the ones of "normal" flapping. We had run some numbers a while back (maybe a year and a half ago) on data from backbones experiencing the MED churn, and found that only about 1-2% of the routes were **candidates** to oscillate. IMHO, the state and extra information is not significant. ;-) Alvaro. 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 SAA18632 for ; Thu, 6 Jun 2002 18:00:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A74E912DD; Thu, 6 Jun 2002 17:59:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FDFF912E4; Thu, 6 Jun 2002 17:59:57 -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 3065B912DD for ; Thu, 6 Jun 2002 17:59:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 371065DDC2; Thu, 6 Jun 2002 17:59:51 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id B26375DD9C for ; Thu, 6 Jun 2002 17:59:50 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56LxQJ30727 for ; Thu, 6 Jun 2002 15:59:26 -0600 Message-Id: <200206062159.g56LxQJ30727@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 06 Jun 2002 15:59:26 -0600 Sender: owner-idr@merit.edu Precedence: bulk > >> Speaking as a SP (today), I'll gladly provide BGP table access to > >> anyone interested in doing this. > > Or get any number of them from archive.routeviews.org. Actually, I was speaking more along the lines of a full analysis, where they'd get all the paths from all the EBGP-speaking routers in my AS, and given the routing topology, flag where issues will/may occur and determine the impact of a given proposal. (Then I could use the code for a few other things I need to do :-) -danny 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 RAA18403 for ; Thu, 6 Jun 2002 17:53:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0956E912EE; Thu, 6 Jun 2002 17:51:36 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4DEF912ED; Thu, 6 Jun 2002 17:51:35 -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 710E6912E8 for ; Thu, 6 Jun 2002 17:51:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79CCC5DDAD; Thu, 6 Jun 2002 17:51:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 058225DD9C for ; Thu, 6 Jun 2002 17:51:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA25904; Thu, 6 Jun 2002 17:51:32 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26126; Thu, 6 Jun 2002 17:51:33 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 17:51:33 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822723@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 17:51:31 -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 Pedro: -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 5:29 PM To: Abarbanel, Benjamin Cc: idr@merit.edu Subject: RE: Abarbanel, Benjamin writes: my text: > ibgp route decision mush be consistent enought to ensure that loops > are not formed. I don't think you can gurantee that if different > members of the mesh use different attributes. >>> This solution is no different than an operator going to a router >>> with an oscillating route and deconfiguring the MED from it, while >>> keeping the other routers unchanged. When you 'unconfigure MED' from a route you basically strip that attribute at the border router that receives it. Thus no inconsistencies exist since everybody sees the same set of attributes. If done properly this manual condifuration never causes inconsistent behaviour, since it affects what all routers see in terms of attributes for the same path. >>>> So why cant the same thing be accomplish by the MED Dampening? >>> >>> BTW, when all the routers are equiped with the MED dampening, they >>> will all reach the same conclusion with the state of the MED and they will >>> all be consistent. >>> Different members of an ibgp mesh see different routes and different events... the number of flaps in a route is different. Most mesh members have a different prespective and the potential to reach different conclusions. >>>> True, but the mechanism will reach the same conclusion whether to >>>> Dampen the route'a MED or not, based on the route's state. >>>> >>>> BTW. I dont think MED has to be applied symmetrically as you alluded >>>> to in earlier posts. MED is just an attribute in helping pick a bias >>>> for the best exit point of a given AS, it does not have to be the >>>> same in each router. Therefore, suppressing it should not cause >>>> prolonged instabilities. It will affect the optimal path chosen assuming >>>> its based on IGP metrics and routes that are reachable. >>>> >>>> Ben It is probably best for me to refrain from commenting further until i see a concrete proposal which can then be analyzed. I just wanted to caution you in advance to a set of issues that imho should be addressed by such proposal. 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 RAA17604 for ; Thu, 6 Jun 2002 17:29:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9E97912E2; Thu, 6 Jun 2002 17:28:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB460912E3; Thu, 6 Jun 2002 17:28:49 -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 8B08F912E2 for ; Thu, 6 Jun 2002 17:28:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BB885DDAD; Thu, 6 Jun 2002 17:28:43 -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 49F195DD9C for ; Thu, 6 Jun 2002 17:28:43 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56LSpm52714; Thu, 6 Jun 2002 14:28:51 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56LSpG87141; Thu, 6 Jun 2002 14:28:51 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 14:28:51 -0700 (PDT) Message-Id: <200206062128.g56LSpG87141@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: In-Reply-To: <39469E08BD83D411A3D900204840EC55822722@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC55822722@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Abarbanel, Benjamin writes: my text: > ibgp route decision mush be consistent enought to ensure that loops > are not formed. I don't think you can gurantee that if different > members of the mesh use different attributes. >>> This solution is no different than an operator going to a router >>> with an oscillating route and deconfiguring the MED from it, while >>> keeping the other routers unchanged. When you 'unconfigure MED' from a route you basically strip that attribute at the border router that receives it. Thus no inconsistencies exist since everybody sees the same set of attributes. If done properly this manual condifuration never causes inconsistent behaviour, since it affects what all routers see in terms of attributes for the same path. >>> >>> BTW, when all the routers are equiped with the MED dampening, they >>> will all reach the same conclusion with the state of the MED and they will >>> all be consistent. >>> Different members of an ibgp mesh see different routes and different events... the number of flaps in a route is different. Most mesh members have a different prespective and the potential to reach different conclusions. It is probably best for me to refrain from commenting further until i see a concrete proposal which can then be analyzed. I just wanted to caution you in advance to a set of issues that imho should be addressed by such proposal. 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 RAA17543 for ; Thu, 6 Jun 2002 17:27:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 840B4912E1; Thu, 6 Jun 2002 17:27:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59359912E2; Thu, 6 Jun 2002 17:27:05 -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 2D6F0912E1 for ; Thu, 6 Jun 2002 17:27:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CF145DDA0; Thu, 6 Jun 2002 17:26:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 084B35DD9C for ; Thu, 6 Jun 2002 17:26:59 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 17:27:06 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7AD@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'Gargi Nalawade'" Cc: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: RE: AS_CONFED_SET Date: Thu, 6 Jun 2002 17:26:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk Thanks! So will a _ in a regexp match it? I'll just try anyway. Halabi's book does not mention it (then again he does not mention the \ -- which we might need to match the [ and ] if the _ does not work. -----Original Message----- From: Gargi Nalawade [mailto:gargi@cisco.com] Sent: Thursday, June 06, 2002 5:22 PM To: Natale, Jonathan Cc: 'idr@merit.edu'; 'isp-bgp@isp-bgp.com'; 'isp-routing@isp-routing.com' Subject: Re: AS_CONFED_SET [] -gargi "Natale, Jonathan" wrote: > > How is an AS_CONFED_SET displayed in the show ip bgp command output? > > thnx 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 RAA17378 for ; Thu, 6 Jun 2002 17:22:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B6C8912DF; Thu, 6 Jun 2002 17:22:05 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64A93912E0; Thu, 6 Jun 2002 17:22:05 -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 6D4EE912DF for ; Thu, 6 Jun 2002 17:22:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D5335DDA0; Thu, 6 Jun 2002 17:21:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by segue.merit.edu (Postfix) with ESMTP id 00C6D5DD9C for ; Thu, 6 Jun 2002 17:21:58 -0400 (EDT) Received: from gargi-u5.cisco.com (gargi-u5.cisco.com [128.107.162.118]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g56LM4PI005021; Thu, 6 Jun 2002 14:22:04 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by gargi-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA24987; Thu, 6 Jun 2002 14:22:04 -0700 (PDT) Message-ID: <3CFFD27C.F5BCC2DF@cisco.com> Date: Thu, 06 Jun 2002 14:22:04 -0700 From: Gargi Nalawade X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Natale, Jonathan" Cc: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: Re: AS_CONFED_SET References: <1117F7D44159934FB116E36F4ABF221B020AF7A8@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk [] -gargi "Natale, Jonathan" wrote: > > How is an AS_CONFED_SET displayed in the show ip bgp command output? > > thnx 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 RAA17181 for ; Thu, 6 Jun 2002 17:17:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87310912DC; Thu, 6 Jun 2002 17:17:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 502B9912DF; Thu, 6 Jun 2002 17:17:11 -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 58BFC912DC for ; Thu, 6 Jun 2002 17:17:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57E255DDA0; Thu, 6 Jun 2002 17:17:05 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0DCE95DD9C for ; Thu, 6 Jun 2002 17:17:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22556; Thu, 6 Jun 2002 17:17:09 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17884; Thu, 6 Jun 2002 17:17:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 17:17:09 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822722@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 17:17:07 -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: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 4:46 PM To: Abarbanel, Benjamin Cc: idr@merit.edu Subject: RE: Abarbanel, Benjamin writes: >>> What is being dampened is not the route but whether we use the MED >>> for this route in the BRSC calculations when we detect a route has >>> been oscillating. Once, the route exits its oscillation state MED >>> is automatically reapplied. >>> >>> General IBGP dampening can be done as was done in EBGP but for the problem >>> we have been exposed to, the MED dampening should suffice. >>> >>> Yes, we would need to keep track of the routes previous history in >>> order to know that it has entered oscillation state. This >>> mechanism can be described in detail in a draft. >>> While i would encorage you to describe the proposal in detail, your brief synopsis gives me the impression that you propose to ignore certain attributes on different members of the ibgp mesh. ibgp route decision mush be consistent enought to ensure that loops are not formed. I don't think you can gurantee that if different members of the mesh use different attributes. >> This solution is no different than an operator going to a router with >> an oscillating route and deconfiguring the MED from it, while keeping >> the other routers unchanged. Yes, inconsistancy will form, but millisecond >> route oscillation will be stoped much faster than an operator can first >> find the router and second stop it by applying manual configuration change. >> Remember the router will have enough smarts to know the state of the route >> and how to adjust its MED to dampen the oscillation. As others have said, >> all solutions proposed will have temporary transient states that are not >> healthy to the network. >> >> BTW, when all the routers are equiped with the MED dampening, they will all >> reach the same conclusion with the state of the MED and they will all be >> consistent. >> >> Ben 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 QAA16265 for ; Thu, 6 Jun 2002 16:49:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF508912DA; Thu, 6 Jun 2002 16:48:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71EB5912DC; Thu, 6 Jun 2002 16: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 A5FA0912DA for ; Thu, 6 Jun 2002 16:48:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B21075DEB3; Thu, 6 Jun 2002 16:48:34 -0400 (EDT) Delivered-To: idr@merit.edu Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with ESMTP id 51C6A5DD9C for ; Thu, 6 Jun 2002 16:48:34 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KmvUL005395; Thu, 6 Jun 2002 16:48:57 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56KmVo42784; Thu, 6 Jun 2002 16:48:31 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KmUjq63555044; Thu, 6 Jun 2002 16:48:30 -0400 (EDT) Message-ID: <3CFFCA9E.AE839554@research.bell-labs.com> Date: Thu, 06 Jun 2002 16:48:30 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Abarbanel, Benjamin" Cc: danny@tcb.net, idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <39469E08BD83D411A3D900204840EC55822721@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yes, we are aware of this -- it turns out that there may be transient black hole routing while the system is converging, but once the system converges, everybody will agree on a single, stable set of routes. There is a proof that actually shows this. Of course, you can be concerned about black hole routing before the system converges, but then, in any system undergoing transition, there *will be* some black hole routing for short periods. -Anindya "Abarbanel, Benjamin" wrote: > > Basu: > I have a problem with your solution of advertising routes that are not > best routes to IBGP peers. This in itself can lead to black holes or routing > loops. > Even if we can keep the number of routes to a small group, I dont like the > idea > of sending suboptimal routes to a peer. > > Ben > > -----Original Message----- > From: Anindya Basu [mailto:basu@research.bell-labs.com] > Sent: Thursday, June 06, 2002 4:11 PM > To: danny@tcb.net > Cc: idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > > I am actually curious -- have any of you out there with access to real > routing tables applied any of these algorithms (that purport to send > extra routes) and seen how many extra routes are generated? Two > datapoints would be of interest: > (a) For what percentage of routing prefixes are extra routes generated? > (b) For those prefixes for which extra routes are generated, how many > extra routes (on an average) are generated per prefix? > This would provide some ideas about extra memory requirements. Maybe we > should actually have some numbers before completely dissing a perfectly > good solution. > -Anindya > > Danny McPherson wrote: > > > > > >not quite, the proposal by wilfong et. al. actually stops it totally > and > > > >we can prove it. > > > > > > I know it's been said before (and recently) but a reminder just in > > > case: scaling matters. > > > > Right! A full IBGP mesh with no heirarchy, or heck, putting the > > routes in an IGP -- would fix it as well, but please, lets not > > forget that the solution has to be deployable and the several > > vendors in my network today aren't exactly begging for more > > BGP paths. > > > > -danny 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 QAA16224 for ; Thu, 6 Jun 2002 16:48:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82E3C912D9; Thu, 6 Jun 2002 16:46:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 481D0912DD; Thu, 6 Jun 2002 16:46:22 -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 7997B912D9 for ; Thu, 6 Jun 2002 16:46:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85E2F5DE02; Thu, 6 Jun 2002 16:46:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 59EA85DD9C for ; Thu, 6 Jun 2002 16:46:12 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KkKEF053665; Thu, 6 Jun 2002 16:46:20 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56KkDo42521; Thu, 6 Jun 2002 16:46:13 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KkDjq57842658; Thu, 6 Jun 2002 16:46:13 -0400 (EDT) Message-ID: <3CFFCA15.8878F3BF@research.bell-labs.com> Date: Thu, 06 Jun 2002 16:46:13 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: danny@tcb.net Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <200206062042.g56KgT520524@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk With all due respect, I don't think that this list is the right forum for ad-hominem attacks! :-) (at least speaking as someone with a PhD, that you so deride).... Enough said. -Anindya Danny McPherson wrote: > Generally speaking, it doesn't take a PHD or fancy algorithm > to figure out several of the proporals won't help my routers > scale any better. > > -danny 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 QAA16154 for ; Thu, 6 Jun 2002 16:47:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF919912D8; Thu, 6 Jun 2002 16:45:39 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 809B7912DC; Thu, 6 Jun 2002 16:45:39 -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 4A50B912D8 for ; Thu, 6 Jun 2002 16:45:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FFC55DE02; Thu, 6 Jun 2002 16:45:33 -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 F24535DD9C for ; Thu, 6 Jun 2002 16:45:32 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56Kjem49771; Thu, 6 Jun 2002 13:45:40 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56Kjep87049; Thu, 6 Jun 2002 13:45:40 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 13:45:40 -0700 (PDT) Message-Id: <200206062045.g56Kjep87049@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: In-Reply-To: <39469E08BD83D411A3D900204840EC5582271F@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC5582271F@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Abarbanel, Benjamin writes: >>> What is being dampened is not the route but whether we use the MED >>> for this route in the BRSC calculations when we detect a route has >>> been oscillating. Once, the route exits its oscillation state MED >>> is automatically reapplied. >>> >>> General IBGP dampening can be done as was done in EBGP but for the problem >>> we have been exposed to, the MED dampening should suffice. >>> >>> Yes, we would need to keep track of the routes previous history in >>> order to know that it has entered oscillation state. This >>> mechanism can be described in detail in a draft. >>> While i would encorage you to describe the proposal in detail, your brief synopsis gives me the impression that you propose to ignore certain attributes on different members of the ibgp mesh. ibgp route decision mush be consistent enought to ensure that loops are not formed. I don't think you can gurantee that if different members of the mesh use different attributes. Pedro. 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 QAA16028 for ; Thu, 6 Jun 2002 16:43:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9B8E912D5; Thu, 6 Jun 2002 16:42:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B0C7912D6; Thu, 6 Jun 2002 16:42: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 91A84912D5 for ; Thu, 6 Jun 2002 16:42:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E6885DE02; Thu, 6 Jun 2002 16:42:53 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 245955DD9C for ; Thu, 6 Jun 2002 16:42:53 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56KgT520524 for ; Thu, 6 Jun 2002 14:42:29 -0600 Message-Id: <200206062042.g56KgT520524@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 06 Jun 2002 14:42:29 -0600 Sender: owner-idr@merit.edu Precedence: bulk > I am actually curious -- have any of you out there with access to real > routing tables applied any of these algorithms (that purport to send > extra routes) and seen how many extra routes are generated? Two > datapoints would be of interest: > (a) For what percentage of routing prefixes are extra routes generated? > (b) For those prefixes for which extra routes are generated, how many > extra routes (on an average) are generated per prefix? > This would provide some ideas about extra memory requirements. Maybe we > should actually have some numbers before completely dissing a perfectly > good solution. Speaking as a SP (today), I'll gladly provide BGP table access to anyone interested in doing this. Generally speaking, it doesn't take a PHD or fancy algorithm to figure out several of the proporals won't help my routers scale any better. -danny 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 QAA16016 for ; Thu, 6 Jun 2002 16:43:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAF77912D6; Thu, 6 Jun 2002 16:43:27 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B226D912D8; Thu, 6 Jun 2002 16:43:27 -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 D7ED8912D6 for ; Thu, 6 Jun 2002 16:43:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E49FB5DE02; Thu, 6 Jun 2002 16:43:20 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 705865DD9C for ; Thu, 6 Jun 2002 16:43:20 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA18499; Thu, 6 Jun 2002 16:43:25 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09456; Thu, 6 Jun 2002 16:43:22 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 16:43:22 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822721@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Anindya Basu'" , danny@tcb.net Cc: idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 6 Jun 2002 16:43:21 -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 Basu: I have a problem with your solution of advertising routes that are not best routes to IBGP peers. This in itself can lead to black holes or routing loops. Even if we can keep the number of routes to a small group, I dont like the idea of sending suboptimal routes to a peer. Ben -----Original Message----- From: Anindya Basu [mailto:basu@research.bell-labs.com] Sent: Thursday, June 06, 2002 4:11 PM To: danny@tcb.net Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt I am actually curious -- have any of you out there with access to real routing tables applied any of these algorithms (that purport to send extra routes) and seen how many extra routes are generated? Two datapoints would be of interest: (a) For what percentage of routing prefixes are extra routes generated? (b) For those prefixes for which extra routes are generated, how many extra routes (on an average) are generated per prefix? This would provide some ideas about extra memory requirements. Maybe we should actually have some numbers before completely dissing a perfectly good solution. -Anindya Danny McPherson wrote: > > > >not quite, the proposal by wilfong et. al. actually stops it totally and > > >we can prove it. > > > > I know it's been said before (and recently) but a reminder just in > > case: scaling matters. > > Right! A full IBGP mesh with no heirarchy, or heck, putting the > routes in an IGP -- would fix it as well, but please, lets not > forget that the solution has to be deployable and the several > vendors in my network today aren't exactly begging for more > BGP paths. > > -danny 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 QAA15885 for ; Thu, 6 Jun 2002 16:39:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B862912D4; Thu, 6 Jun 2002 16:39:24 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB184912D5; Thu, 6 Jun 2002 16:39:23 -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 CDF43912D4 for ; Thu, 6 Jun 2002 16:39:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3EC45DE2E; Thu, 6 Jun 2002 16:39:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 58E465DD9C for ; Thu, 6 Jun 2002 16:39:17 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56Kcrw20301 for ; Thu, 6 Jun 2002 14:38:53 -0600 Message-Id: <200206062038.g56Kcrw20301@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Date: Thu, 06 Jun 2002 14:38:53 -0600 Sender: owner-idr@merit.edu Precedence: bulk > One possible solution is to mandate 'always-compare-med' behaviour > which will make paths have a global ordering. I remember there was > strong reaction against this from the operational folks but i'm not > quite sure what the arguments where (would apreciate if somebody could > refresh my memory). Correct me if I'm wrong -- but the primary use of MEDs is for a BGP speaker to convey the optimal entry point for a given destination to a peer AS. That is, for one AS to associate MEDs with given reachabilty based on some policy internally consistent within the AS. Typically, the MED values are derived from IGP metrics associated with BGP NEXT_HOPs, thereby reflecting internal route selection preference in the process. Now, beyond that fact that MEDs are largely broken in general in the Internet, mostly as a result of aggregation... The issues with comparing MEDs between different ASes is that MED values are derived from some policy defined and contained internal to the peer network. Used to be, comparing MEDs between a network that ran IS-IS and a network that ran OSPF would result in the network running IS-IS receiving a much larger amount of traffic, simply because the IS-IS metric space was limited to 6 bits, and the resulting IGP metric-derived BGP MED from the AS were lower values. Though the IS-IS metric space isn't so much of an issue today, basing BGP path selection on MED values received from different ASes, probabilistically (sp?) derived from potentially significantly different policies, is certainly a BAD idea. In marketing speak, MEDs intend to turn hot potato routing into cold potato routing but end up with mashed potato routing. -danny 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 QAA14953 for ; Thu, 6 Jun 2002 16:15:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18C72912D3; Thu, 6 Jun 2002 16:14:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA2BF912D4; Thu, 6 Jun 2002 16:14: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 CCD5C912D3 for ; Thu, 6 Jun 2002 16:14:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D36A65DE02; Thu, 6 Jun 2002 16:14:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (unknown [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 479475DD9C for ; Thu, 6 Jun 2002 16:14:09 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g56KEF596980; Thu, 6 Jun 2002 16:14:15 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g56KEC996969; Thu, 6 Jun 2002 16:14:12 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g56KECG02361; Thu, 6 Jun 2002 16:14:12 -0400 (EDT) Date: Thu, 6 Jun 2002 16:14:12 -0400 From: Jeffrey Haas To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: your mail Message-ID: <20020606161412.C27447@nexthop.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <200206061855.g56Itda86837@roque-bsd.juniper.net> <20020606150051.B27447@nexthop.com> <200206061918.g56JIUM86879@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206061918.g56JIUM86879@roque-bsd.juniper.net>; from roque@juniper.net on Thu, Jun 06, 2002 at 12:18:30PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jun 06, 2002 at 12:18:30PM -0700, Pedro Roque Marques wrote: > Can you elaborate please... i don't quite get the scenario where > different behaviour is introduced. The simplest one I can think of is that when "always-compare-med" is on, if you have some ISP that is injecting better MEDs than yours, it removes your routes from being used even when they should be used as the closest exit router. Example: Ra Rb *-----* Routers a and b are AS-BR's and iBGP between each other. ISPs 1 and 2 peer at Ra and Rb respectively. Some destination, D is injected by both. ISP-1 injects it with a MED of 2 and ISP-2 injects it with an MED of 1. With always-compare-med, if the LocalPref, AS_Path length, and origin are the same, then ISP-2's route will win in both routers because ISP-1's route is suppressed. Without always-compare-med, each ISP wins at the their respective BR. If you add a Rc that peers with Ra, Rb (fully-meshed), then: With always-compare-med: ISP-1's D is suppressed and never gets used. Without always-compare-med: Rc has the choice of ISP-1's and ISP-2's D and will continue through route selection, choosing IGP distance or routerid. Without taking this to the more complicated cases, the argument that the operational community makes is that "always-compare-med" is a form of denial of service. Of course, I don't speak for the operational community - I haven't had a login on a router that actually affects customer's routing for a few years. :-) > Only for prefixes that they both announce... i don't have access to > meaningful data myself but a point made several times in this > discussion is that the number of prefixes which end up with a decision > with same length as-paths from different neighbor ASes where between > the same AS you pick best MED and between different AS you pick best > IGP, etc... is said to be quite small. For particular topologies. It is possible that many ISPs just don't implement topologies that are affected by these issues. > Pedro. -- 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 QAA14861 for ; Thu, 6 Jun 2002 16:12:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 764EE912D2; Thu, 6 Jun 2002 16:11:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D83D912D3; Thu, 6 Jun 2002 16:11: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 E0FE6912D2 for ; Thu, 6 Jun 2002 16:11:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0C1D5DE02; Thu, 6 Jun 2002 16:11:11 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id B498F5DD9C for ; Thu, 6 Jun 2002 16:11:11 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KBJEF053372; Thu, 6 Jun 2002 16:11:19 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56KBCo39332; Thu, 6 Jun 2002 16:11:13 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56KBCjq62055109; Thu, 6 Jun 2002 16:11:12 -0400 (EDT) Message-ID: <3CFFC1E0.49EEF147@research.bell-labs.com> Date: Thu, 06 Jun 2002 16:11:12 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: danny@tcb.net Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <200206062002.g56K25W19519@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk I am actually curious -- have any of you out there with access to real routing tables applied any of these algorithms (that purport to send extra routes) and seen how many extra routes are generated? Two datapoints would be of interest: (a) For what percentage of routing prefixes are extra routes generated? (b) For those prefixes for which extra routes are generated, how many extra routes (on an average) are generated per prefix? This would provide some ideas about extra memory requirements. Maybe we should actually have some numbers before completely dissing a perfectly good solution. -Anindya Danny McPherson wrote: > > > >not quite, the proposal by wilfong et. al. actually stops it totally and > > >we can prove it. > > > > I know it's been said before (and recently) but a reminder just in > > case: scaling matters. > > Right! A full IBGP mesh with no heirarchy, or heck, putting the > routes in an IGP -- would fix it as well, but please, lets not > forget that the solution has to be deployable and the several > vendors in my network today aren't exactly begging for more > BGP paths. > > -danny 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 QAA14585 for ; Thu, 6 Jun 2002 16:03:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0366912D1; Thu, 6 Jun 2002 16:02:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DA06912D2; Thu, 6 Jun 2002 16:02:58 -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 90551912D1 for ; Thu, 6 Jun 2002 16:02:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 895E15DE02; Thu, 6 Jun 2002 16:02:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 118B45DD9C for ; Thu, 6 Jun 2002 16:02:30 -0400 (EDT) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g56K25W19519 for ; Thu, 6 Jun 2002 14:02:05 -0600 Message-Id: <200206062002.g56K25W19519@tcb.net> To: idr@merit.edu From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 06 Jun 2002 14:02:05 -0600 Sender: owner-idr@merit.edu Precedence: bulk > >not quite, the proposal by wilfong et. al. actually stops it totally and > >we can prove it. > > I know it's been said before (and recently) but a reminder just in > case: scaling matters. Right! A full IBGP mesh with no heirarchy, or heck, putting the routes in an IGP -- would fix it as well, but please, lets not forget that the solution has to be deployable and the several vendors in my network today aren't exactly begging for more BGP paths. -danny 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 PAA14150 for ; Thu, 6 Jun 2002 15:51:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A758912CF; Thu, 6 Jun 2002 15:51:23 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27C9F912D0; Thu, 6 Jun 2002 15:51:23 -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 36C35912CF for ; Thu, 6 Jun 2002 15:51:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37D345DE02; Thu, 6 Jun 2002 15:51:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B044F5DDC2 for ; Thu, 6 Jun 2002 15:51:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12874; Thu, 6 Jun 2002 15:51:22 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27456; Thu, 6 Jun 2002 15:51:23 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 15:51:22 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271F@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 15:51:20 -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 Pedro: -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 3:35 PM To: Abarbanel, Benjamin Cc: idr@merit.edu Subject: RE: Abarbanel, Benjamin writes: > I have a third solution to propose to the list. Why not dampen the > MED from the BGP Route Selection Criteria during conditions when a > route is oscillating As i mentioned in my previous e-mail to the list, the devil is in the details... Someone needs to specify the behaviour and do an analysis to see if it is feasible... without some detailed analysis i don't think it is possible to know if that is a feasible solution. Keep in mind the following scenario: You have N peering points with AS 1 in your ibgp mesh. Each of those N points receives a route with an MED. When the best external route changes, all of those N peering points advertise their external route to the mesh and then withraw it as they converge to the second best MED. In this case are you going to hold dampening history for all these paths ? Are you going to apply penalties to individual paths (as in the ebgp case) or routes... don't forget that you need to dampen things in a coverged state (i.e. no routing loops in the mesh). >> What is being dampened is not the route but whether we use the MED >> for this route in the BRSC calculations when we detect a route has been >> oscillating. Once, the route exits its oscillation state MED is automatically >> reapplied. >> >> General IBGP dampening can be done as was done in EBGP but for the problem >> we have been exposed to, the MED dampening should suffice. >> >> Yes, we would need to keep track of the routes previous history in order >> to know that it has entered oscillation state. This mechanism can be >> described in detail in a draft. >> >> Ben 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 PAA13654 for ; Thu, 6 Jun 2002 15:38:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF548912CE; Thu, 6 Jun 2002 15:37:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0A07912CF; Thu, 6 Jun 2002 15:37: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 723F1912CE for ; Thu, 6 Jun 2002 15:37:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D0535DDF4; Thu, 6 Jun 2002 15:37:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 4E1775DDC2 for ; Thu, 6 Jun 2002 15:37:09 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56JbGEF053099; Thu, 6 Jun 2002 15:37:16 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56Jb9o36013; Thu, 6 Jun 2002 15:37:10 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56Jb9jq61961518; Thu, 6 Jun 2002 15:37:09 -0400 (EDT) Message-ID: <3CFFB9E5.5398E907@research.bell-labs.com> Date: Thu, 06 Jun 2002 15:37:09 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: I-BGP Oscillations References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <3CFFB44D.F8D020BD@research.bell-labs.com> <200206061927.g56JRkf86900@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > 'Decency' criteria includes state that one needs to hold, etc... > > In other words, the ammount of state required to detect such events > shouldn't be greater than the state necessary to advertise the best > external MED winner paths from all mesh participants. > > Note that the answer 'ibgp dampening' that is certain to pop up in > peoples minds by association is a bit misleading. When you start > thinking about it is quite a different beast... it is not suficient to > say that you just apply the procedures applied to ebgp dampening since > the problem is quite different. could you elucidate further and explain how detection of the problem is different for i-bgp and e-bgp? also, i was not exactly suggesting a dampening mechanism (as they are used today). i was arguing for a mechanism which would be triggered whenever frequent announcements followed by withdrawals of the same i-bgp route is observed. this mechanism would then start sending out extra routes. -anindya 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 PAA13581 for ; Thu, 6 Jun 2002 15:35:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06FFF912CD; Thu, 6 Jun 2002 15:35:17 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2780912CE; Thu, 6 Jun 2002 15:35:16 -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 8E176912CD for ; Thu, 6 Jun 2002 15:35:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39D065DDF4; Thu, 6 Jun 2002 15:35:09 -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 DCB415DDC2 for ; Thu, 6 Jun 2002 15:35:08 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56JZGm45132; Thu, 6 Jun 2002 12:35:16 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56JZGa86921; Thu, 6 Jun 2002 12:35:16 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 12:35:16 -0700 (PDT) Message-Id: <200206061935.g56JZGa86921@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Abarbanel, Benjamin" Cc: idr@merit.edu Subject: RE: In-Reply-To: <39469E08BD83D411A3D900204840EC5582271D@vie-msgusr-01.dc.fore.com> References: <39469E08BD83D411A3D900204840EC5582271D@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Abarbanel, Benjamin writes: > I have a third solution to propose to the list. Why not dampen the > MED from the BGP Route Selection Criteria during conditions when a > route is oscillating As i mentioned in my previous e-mail to the list, the devil is in the details... Someone needs to specify the behaviour and do an analysis to see if it is feasible... without some detailed analysis i don't think it is possible to know if that is a feasible solution. Keep in mind the following scenario: You have N peering points with AS 1 in your ibgp mesh. Each of those N points receives a route with an MED. When the best external route changes, all of those N peering points advertise their external route to the mesh and then withraw it as they converge to the second best MED. In this case are you going to hold dampening history for all these paths ? Are you going to apply penalties to individual paths (as in the ebgp case) or routes... don't forget that you need to dampen things in a coverged state (i.e. no routing loops in the mesh). 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 PAA13497 for ; Thu, 6 Jun 2002 15:33:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A175912CC; Thu, 6 Jun 2002 15:31:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 314CF912D8; Thu, 6 Jun 2002 15:31: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 3DFF6912CC for ; Thu, 6 Jun 2002 15:31:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 405625DEA6; Thu, 6 Jun 2002 15:31:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B3C6B5DD9C for ; Thu, 6 Jun 2002 15:31:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10515; Thu, 6 Jun 2002 15:31:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22568; Thu, 6 Jun 2002 15:31:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 15:31:46 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271E@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , Anindya Basu Cc: idr@merit.edu Subject: RE: I-BGP Oscillations Date: Thu, 6 Jun 2002 15:31:43 -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 Pedro: Why not, IBGP Dampening is what I have been thinking aboute since this problem was first exposed to IETF. I have started a draft but never finished it, got talked out of it by one other gentlemen who wrote the original draft on route oscillations. Maybe its time to get serious on this. Ben -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 3:28 PM To: Anindya Basu Cc: idr@merit.edu Subject: I-BGP Oscillations Anindya Basu writes: > One way to address this issue would be to *only* send out extra > routes when necessary. In other words, if an oscillation involving > I-BGP routes is detected, extra information for only that route > could be sent out. If we come up with a decent detection mechanism it would be so much simpler just to reduce the rate of oscilation. Regardless a decent detection mechanism needs to be proposed... 'Decency' criteria includes state that one needs to hold, etc... In other words, the ammount of state required to detect such events shouldn't be greater than the state necessary to advertise the best external MED winner paths from all mesh participants. Note that the answer 'ibgp dampening' that is certain to pop up in peoples minds by association is a bit misleading. When you start thinking about it is quite a different beast... it is not suficient to say that you just apply the procedures applied to ebgp dampening since the problem is quite different. 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 PAA13258 for ; Thu, 6 Jun 2002 15:28:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F504912CA; Thu, 6 Jun 2002 15:27:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C9CC912CB; Thu, 6 Jun 2002 15:27: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 E8727912CA for ; Thu, 6 Jun 2002 15:27:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC40C5DEA6; Thu, 6 Jun 2002 15:27:38 -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 69A7F5DDC2 for ; Thu, 6 Jun 2002 15:27:38 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56JRkm44637; Thu, 6 Jun 2002 12:27:46 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56JRkf86900; Thu, 6 Jun 2002 12:27:46 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 12:27:46 -0700 (PDT) Message-Id: <200206061927.g56JRkf86900@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Anindya Basu Cc: idr@merit.edu Subject: I-BGP Oscillations In-Reply-To: <3CFFB44D.F8D020BD@research.bell-labs.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <3CFFB44D.F8D020BD@research.bell-labs.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Anindya Basu writes: > One way to address this issue would be to *only* send out extra > routes when necessary. In other words, if an oscillation involving > I-BGP routes is detected, extra information for only that route > could be sent out. If we come up with a decent detection mechanism it would be so much simpler just to reduce the rate of oscilation. Regardless a decent detection mechanism needs to be proposed... 'Decency' criteria includes state that one needs to hold, etc... In other words, the ammount of state required to detect such events shouldn't be greater than the state necessary to advertise the best external MED winner paths from all mesh participants. Note that the answer 'ibgp dampening' that is certain to pop up in peoples minds by association is a bit misleading. When you start thinking about it is quite a different beast... it is not suficient to say that you just apply the procedures applied to ebgp dampening since the problem is quite different. 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 PAA13233 for ; Thu, 6 Jun 2002 15:27:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D76C59120D; Thu, 6 Jun 2002 15:26:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A759B912CA; Thu, 6 Jun 2002 15:26:49 -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 BDA1D9120D for ; Thu, 6 Jun 2002 15:26:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFC125DDF4; Thu, 6 Jun 2002 15:26:43 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4B07A5DDC2 for ; Thu, 6 Jun 2002 15:26:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09904; Thu, 6 Jun 2002 15:26:48 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20826; Thu, 6 Jun 2002 15:26:49 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 15:26:48 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271D@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Pedro Roque Marques'" , f b shepherd Cc: idr@merit.edu Subject: RE: Date: Thu, 6 Jun 2002 15:26:47 -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 I have a third solution to propose to the list. Why not dampen the MED from the BGP Route Selection Criteria during conditions when a route is oscillating, thus temporarily removing the route from a possible oscillation state and stoping it. This solution only imposes additional internal resources on a given router and does not introduce scalability issues with external routers. In addition, the oscillation is not critical to the topology configured but to the behavior of the route. In other words, I propose we treat the route oscillation not try to cure it, since its source is topologically unpredictable and the existing BGP protocol design does not warrant redefining its basic rules of operation. Ben -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net] Sent: Thursday, June 06, 2002 2:56 PM To: f b shepherd Cc: idr@merit.edu Subject: f b shepherd writes: > ==> It seems to me impossible to adhere to only propogating > best-path and yet to eliminate all oscillations which were > considering (or maybe even to only eleiminate types I and II churn). > At least not without some other radical change to the protocol. There is a simple answer, which is to address the current MED behaviour. MEDs as current specified make it so that there isn't possible to establish a global ordering between BGP paths. The protocol when originally designed implicit required such property. Given a global ordering of paths within an ibgp mesh no persistent osciallation will occur and the protocol as originally specified will be stable. In order to achieve this, of course, one needs to encounter an solution to the problem that MEDs are supposed to solve. One possible solution is to mandate 'always-compare-med' behaviour which will make paths have a global ordering. I remember there was strong reaction against this from the operational folks but i'm not quite sure what the arguments where (would apreciate if somebody could refresh my memory). Or we can attempt to specify a different attribute/mechanism that achieves the desired effects. 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 PAA13014 for ; Thu, 6 Jun 2002 15:20:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCFDA912D7; Thu, 6 Jun 2002 15:18:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93CA7912D6; Thu, 6 Jun 2002 15:18:34 -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 40C509120D for ; Thu, 6 Jun 2002 15:18:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4324F5DDC2; Thu, 6 Jun 2002 15:18:23 -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 B18B05DDF4 for ; Thu, 6 Jun 2002 15:18:22 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56JIUm44180; Thu, 6 Jun 2002 12:18:30 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56JIUM86879; Thu, 6 Jun 2002 12:18:30 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 12:18:30 -0700 (PDT) Message-Id: <200206061918.g56JIUM86879@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: your mail In-Reply-To: <20020606150051.B27447@nexthop.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <200206061855.g56Itda86837@roque-bsd.juniper.net> <20020606150051.B27447@nexthop.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Jeffrey Haas writes: > On Thu, Jun 06, 2002 at 11:55:39AM -0700, Pedro Roque Marques wrote: >> One possible solution is to mandate 'always-compare-med' behaviour >>... > With the current behavior, a given AS may inject backup paths to > their upstream and have the expected behavior happen so long as it > gets to the MED portion of tie-breaking: the routes with the worse > meds are suppressed. Can you elaborate please... i don't quite get the scenario where different behaviour is introduced. > With always-compare-med, all AS peers must adhere to a common policy > of what MEDs they will use for a given prefix. Only for prefixes that they both announce... i don't have access to meaningful data myself but a point made several times in this discussion is that the number of prefixes which end up with a decision with same length as-paths from different neighbor ASes where between the same AS you pick best MED and between different AS you pick best IGP, etc... is said to be quite small. Still probably unpractical to coordinate, i admit. > While theoretically > possible, making more than one ISP agree about anything is hard to > scale. :-) Don't forget that the same thing is true for any proposal that changes the number of paths present on their systems... or any behaviour change. :-) >> Or we can attempt to specify a different attribute/mechanism that >> achieves the desired effects. > If I recall previous discussions, the amount of state that would > need to be flooded throughout the AS was only a little less than > flooding the relevant full routing instances. There are 2 different type of problems that i'm aware of... 1) The current behaviour of MEDs make it so that all the routers in an ibgp choose one of the paths of a neighbor AS over another reducing the number of paths in the system. If you discard MEDs at your borders the number of paths injected in the iBGP greatly increases (to the number of peering points) as all the mesh members start prefering their own external path and advertising them into the mesh. 2) You need to convey the information itself of which of the exit points is preferable from a point of view of your neighbor AS. MHO is that it is possible to find solutions for this issues. 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 PAA12738 for ; Thu, 6 Jun 2002 15:14:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9BF2912C8; Thu, 6 Jun 2002 15:13:25 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7522B912C9; Thu, 6 Jun 2002 15:13:25 -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 D376A912C8 for ; Thu, 6 Jun 2002 15:13:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D946A5DEB3; Thu, 6 Jun 2002 15:13:18 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 770CF5DDC2 for ; Thu, 6 Jun 2002 15:13:18 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56JDOEF052912; Thu, 6 Jun 2002 15:13:24 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56JDIk81930; Thu, 6 Jun 2002 15:13:18 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56JDHjq46830459; Thu, 6 Jun 2002 15:13:17 -0400 (EDT) Message-ID: <3CFFB44D.F8D020BD@research.bell-labs.com> Date: Thu, 06 Jun 2002 15:13:17 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: idr@merit.edu Cc: f b shepherd , Benjamin.Abarbanel@Marconi.com, gtw@research.bell-labs.com, enke@redback.com Subject: I-BGP Oscillations References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk I have been following the responses to various proposals for eliminating I-BGP oscillations with some interest and it appears that there are roughly two main approaches. 1. Try to solve the problem using a solution that fixes the current manifestation of the problem, without changing the protocol too much. draft-walton and draft-chen fall in this category. The main advantage to both these solutions is that they do not involve major changes to the protocol and they have reasonably good scaling properties. On the other hand, such solutions may not address all possible manifestations of the oscillation problem, as evidenced by some of the counter examples that Gordon has suggested. One way to resolve this is to restrict the kind of router configurations that are permitted (as suggested by Chen, as well as Scudder, under the class of real configurations). This approach has two drawbacks: (1) It may make the configuration process too restrictive, i.e., disallow many configurations that may be safe. (2) Fixing the current manifestation of the problem with a solution that appears to make it go away may be risky. It could produce other problems that did not manifest themselves before, as well as not address the entire existing class of problems. Obviously, as newer problems manifest themselves, further and further revisions to the protocol need to be made. 2. The second approach is to actually analyze the protocol and figure out which feature(s) that are inherent in the protocol are causing oscillations. Then redesign the protocol in a manner that is provably correct under all circumstances. This approach obviously addresses the two drawbacks outlined above. draft-wilfong and Pedro have been arguing for such an approach (in my opinion). However, this approach has one distinct disadvantage --- as pointed out by many of you (notably, John Scudder and Ben Abarbanel), there are some scalability issues that need to be addressed. The proposal in draft-wilfong (as well as in draft-walton) advocate sending some extra information to suppress oscillations. However, it is not clear how much extra information may need to get sent out (especially in the case of draft-wilfong). Given the memory constraints for today's routers, it may be hard to store all these extra routes in memory. One way to address this issue would be to *only* send out extra routes when necessary. In other words, if an oscillation involving I-BGP routes is detected, extra information for only that route could be sent out. This way, routers behave normally as usual, and when a particular route (or set of routes) begin to flap, the extra information corresponding to those routes could be computed and sent out. Thus, extra storage is *only* required when something bad happens. Hopefully, this provides a reasonable solution to the scalability problem. Thanks, -Anindya 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 PAA12258 for ; Thu, 6 Jun 2002 15:02:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8726912C4; Thu, 6 Jun 2002 15:00:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71BDA912C6; Thu, 6 Jun 2002 15:00:56 -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 6603C912C4 for ; Thu, 6 Jun 2002 15:00:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A0635DDAC; Thu, 6 Jun 2002 15:00:50 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (unknown [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 152325DD9C for ; Thu, 6 Jun 2002 15:00:50 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g56J0tW92992; Thu, 6 Jun 2002 15:00:55 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g56J0p992980; Thu, 6 Jun 2002 15:00:51 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g56J0pp29056; Thu, 6 Jun 2002 15:00:51 -0400 (EDT) Date: Thu, 6 Jun 2002 15:00:51 -0400 From: Jeffrey Haas To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: your mail Message-ID: <20020606150051.B27447@nexthop.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> <200206061855.g56Itda86837@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206061855.g56Itda86837@roque-bsd.juniper.net>; from roque@juniper.net on Thu, Jun 06, 2002 at 11:55:39AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jun 06, 2002 at 11:55:39AM -0700, Pedro Roque Marques wrote: > One possible solution is to mandate 'always-compare-med' behaviour > which will make paths have a global ordering. I remember there was > strong reaction against this from the operational folks but i'm not > quite sure what the arguments where (would apreciate if somebody could > refresh my memory). With the current behavior, a given AS may inject backup paths to their upstream and have the expected behavior happen so long as it gets to the MED portion of tie-breaking: the routes with the worse meds are suppressed. With always-compare-med, all AS peers must adhere to a common policy of what MEDs they will use for a given prefix. While theoretically possible, making more than one ISP agree about anything is hard to scale. :-) > Or we can attempt to specify a different attribute/mechanism that > achieves the desired effects. If I recall previous discussions, the amount of state that would need to be flooded throughout the AS was only a little less than flooding the relevant full routing instances. > Pedro. -- 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 OAA11986 for ; Thu, 6 Jun 2002 14:56:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11AC8912C3; Thu, 6 Jun 2002 14:55:38 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3251912C4; Thu, 6 Jun 2002 14:55: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 A53EB912C3 for ; Thu, 6 Jun 2002 14:55:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABA1F5DEB3; Thu, 6 Jun 2002 14:55:31 -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 531AA5DD9C for ; Thu, 6 Jun 2002 14:55:31 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56Itdm42762; Thu, 6 Jun 2002 11:55:39 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56Itda86837; Thu, 6 Jun 2002 11:55:39 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 11:55:39 -0700 (PDT) Message-Id: <200206061855.g56Itda86837@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: f b shepherd Cc: idr@merit.edu In-Reply-To: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> References: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk f b shepherd writes: > ==> It seems to me impossible to adhere to only propogating > best-path and yet to eliminate all oscillations which were > considering (or maybe even to only eleiminate types I and II churn). > At least not without some other radical change to the protocol. There is a simple answer, which is to address the current MED behaviour. MEDs as current specified make it so that there isn't possible to establish a global ordering between BGP paths. The protocol when originally designed implicit required such property. Given a global ordering of paths within an ibgp mesh no persistent osciallation will occur and the protocol as originally specified will be stable. In order to achieve this, of course, one needs to encounter an solution to the problem that MEDs are supposed to solve. One possible solution is to mandate 'always-compare-med' behaviour which will make paths have a global ordering. I remember there was strong reaction against this from the operational folks but i'm not quite sure what the arguments where (would apreciate if somebody could refresh my memory). Or we can attempt to specify a different attribute/mechanism that achieves the desired effects. 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 OAA11576 for ; Thu, 6 Jun 2002 14:44:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7768E912C2; Thu, 6 Jun 2002 14:44:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A5CB912C3; Thu, 6 Jun 2002 14:44: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 0A1C7912C2 for ; Thu, 6 Jun 2002 14:44:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1B4B5DD9C; Thu, 6 Jun 2002 14:44:08 -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 9DD615DEB3 for ; Thu, 6 Jun 2002 14:44:08 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g56IiGm42045; Thu, 6 Jun 2002 11:44:16 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g56IiGr86811; Thu, 6 Jun 2002 11:44:16 -0700 (PDT) (envelope-from roque) Date: Thu, 6 Jun 2002 11:44:16 -0700 (PDT) Message-Id: <200206061844.g56IiGr86811@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: enke@redback.com Cc: idr@merit.edu Subject: rr-oscillation-reduce X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Enke, A few questions/comments on your proposal... The gist of it is to advertise 'the best external' (i.e. route from rr-clients) to the rest of the mesh when the best path is internal (i.e. received from a ibgp mesh router). 1) Why do you limit this procedure to RRs/Confeds... ? 2) Advertising the 'best external' route as always had the issue of traffic loops (i believe the reason it hasn't been implemented as specified in 1771 originally). You don't seem to address this in your draft... do you believe it is not relevant... or is there some other solution to this problem... To be more specific, if you have rtrs A, B, such that B has the best path at t0, and A a valid external path, when at t1 B's external path gets withrawn, traffic is almost guaranteed to loop until B's advertisement reaches A. This can be potentially exacerbated by mechanisms such as min advertisement interval. Whereas today such traffic would be blackholed by B... while it is true that current routers are not as susceptible to rollover and die when presented with looping traffic as opposed to software forwarding based boxes of 5+ years ago it is likely that the resulting link congestion is still a relevant factor.... comments ? 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 OAA10872 for ; Thu, 6 Jun 2002 14:25:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F8BE912BE; Thu, 6 Jun 2002 14:24:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14EB5912C0; Thu, 6 Jun 2002 14:24: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 CA745912BE for ; Thu, 6 Jun 2002 14:24:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C89915DEB3; Thu, 6 Jun 2002 14:24:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 661435DD9C for ; Thu, 6 Jun 2002 14:24:39 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56IOkEF052517; Thu, 6 Jun 2002 14:24:46 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56IOdk78190; Thu, 6 Jun 2002 14:24:40 -0400 (EDT) Received: from jessie.research.bell-labs.com (localhost [127.0.0.1]) by jessie.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56IOc0J016047; Thu, 6 Jun 2002 14:24:38 -0400 (EDT) Message-Id: <200206061824.g56IOc0J016047@jessie.research.bell-labs.com> To: idr@merit.edu, Benjamin.Abarbanel@Marconi.com Cc: basu@research.bell-labs.com, gtw@research.bell-labs.com, enke@redback.com Subject: Date: Thu, 06 Jun 2002 14:24:38 -0400 From: f b shepherd Sender: owner-idr@merit.edu Precedence: bulk Content-Length: 1650 Anindya: The solution in draft-wilfong-ibgp-oscillations-00.txt is to merely dump all the routes that were not resolved by BGP Route Selection Criteria (BRSC) to all its peers, is a major disaster to the network. We are already pushing the limits of capacities in routers with 200,000 routes, now to solve a potential route oscillations problem, you dump all unresolved routes to all the peers. What will that do to the routing tables for routers not able to handle such a massive increase of routes? ==> Correct, as you put it, we dump a lot of extra routes. This was the only approach we could see at that time to a) allow MED to maintain some semblance of its intended meaning and b) eliminate any route oscillations (and nondeterminism in the adopted routing). In general, we have not peformed any analysis on the actual number of routes which would be passed. Presumably, quite often it could still only be the best route passed on by a RR. What if some routers are situated in the topology such that they will never get into route oscillations, why should they see a ton of useless routes coming at them from routers that are potentially prone to form or pass oscillating routes? ==> Good point. I also thought, one fundamental rule of BGP is to "Only propagate BGP routes that the router actually uses in its forwarding plain, meaning the route made it to its local-RIB". Are you saying we should pass BRSC unresolved routes to the Local-RIB with your proposal since you are propagating them to the peers? ==> It seems to me impossible to adhere to only propogating best-path and yet to eliminate all oscillations which were considering (or maybe even to only eleiminate types I and II churn). At least not without some other radical change to the protocol. As you mentioned above, the impact on router capacities may make the extra route dumping infeasible. As John also said, scalability is a key issue. As I had previously said - take our work then as hinting that a "total solution" to oscillations may actually require such a larger collection of passed messages. Regards - and apologies for my indentations. Bruce Ben 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 OAA10572 for ; Thu, 6 Jun 2002 14:17:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50C6C912BF; Thu, 6 Jun 2002 14:16:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22679912BE; Thu, 6 Jun 2002 14:16: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 0700E912BF for ; Thu, 6 Jun 2002 14:16:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BA945DEB3; Thu, 6 Jun 2002 14:16:07 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BCBD15DD9C for ; Thu, 6 Jun 2002 14:16:06 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 14:16:14 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7A8@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: AS_CONFED_SET Date: Thu, 6 Jun 2002 14:16:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk How is an AS_CONFED_SET displayed in the show ip bgp command output? thnx 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 NAA09813 for ; Thu, 6 Jun 2002 13:58:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43DF4912BB; Thu, 6 Jun 2002 13:57:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4E7C912B7; Thu, 6 Jun 2002 13:57:03 -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 D3AE6912B7 for ; Thu, 6 Jun 2002 13:57:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D41955DEBE; Thu, 6 Jun 2002 13:56:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 90E9D5DEB4 for ; Thu, 6 Jun 2002 13:56:56 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 13:57:04 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7A7@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'idr@merit.edu'" , "'isp-bgp@isp-bgp.com'" , "'isp-routing@isp-routing.com'" Subject: RE: bgp pruning Date: Thu, 6 Jun 2002 13:57:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA09813 Given the following config: DUT-------r2 l         l l         l l         l r3--------r4   All routers are in different AS's.  The AS # is the router #.  r3 showed that the DUT was sending the routes that originated from r3 with an AS path of 3 4 2 1 (which is the correct AS path).  The expected behavior is for the DUT to not send these routes since they will be denied by r3 anyway as part of the BGP pruning process; this is what a major vendor does (prunes on the output as well). But the RFC1771 does not require that these routes not be sent (it does require that they be pruned at the input of r3).  It seems to me that it IS better to do it the way the major vendor does it (prune at input and output) in order to save BW and processing.   Why does RFC1771/the 17th draft not specify output pruning (or does it)?    Can/should this be added?   What does that other major vendor do?   How am I doing on my political correctness?   Thank you.   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 NAA09804 for ; Thu, 6 Jun 2002 13:57:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00F09912B8; Thu, 6 Jun 2002 13:57:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC9DE912B9; Thu, 6 Jun 2002 13:57:03 -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 84331912B8 for ; Thu, 6 Jun 2002 13:57:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88E8F5DEBE; Thu, 6 Jun 2002 13:56:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0B52F5DEB4 for ; Thu, 6 Jun 2002 13:56:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28815; Thu, 6 Jun 2002 13:57:02 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21975; Thu, 6 Jun 2002 13:57:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 13:57:03 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271B@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Anindya Basu'" , "Abarbanel, Benjamin" Cc: "'Gordon Wilfong'" , Enke Chen , idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 6 Jun 2002 13:57:00 -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 Anindya: The solution in draft-wilfong-ibgp-oscillations-00.txt is to merely dump all the routes that were not resolved by BGP Route Selection Criteria (BRSC) to all its peers, is a major disaster to the network. We are already pushing the limits of capacities in routers with 200,000 routes, now to solve a potential route oscillations problem, you dump all unresolved routes to all the peers. What will that do to the routing tables for routers not able to handle such a massive increase of routes? What if some routers are situated in the topology such that they will never get into route oscillations, why should they see a ton of useless routes coming at them from routers that are potentially prone to form or pass oscillating routes? I also thought, one fundamental rule of BGP is to "Only propagate BGP routes that the router actually uses in its forwarding plain, meaning the route made it to its local-RIB". Are you saying we should pass BRSC unresolved routes to the Local-RIB with your proposal since you are propagating them to the peers? Ben -----Original Message----- From: Anindya Basu [mailto:basu@research.bell-labs.com] Sent: Thursday, June 06, 2002 12:41 PM To: Abarbanel, Benjamin Cc: 'Gordon Wilfong'; Enke Chen; idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt "Abarbanel, Benjamin" wrote: > > Sounds to me like all the proposals so far attempt to reduce the > probability of route oscillations, but do not control or stop it > totally. So I think another approach is warranted. > > Ben > not quite, the proposal by wilfong et. al. actually stops it totally and we can prove it. -anindya 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 NAA09750 for ; Thu, 6 Jun 2002 13:56:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9A2B912B4; Thu, 6 Jun 2002 13:55:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D374912B7; Thu, 6 Jun 2002 13:55:33 -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 36534912B4 for ; Thu, 6 Jun 2002 13:55:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36E645DEBE; Thu, 6 Jun 2002 13:55:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E2F675DEB4 for ; Thu, 6 Jun 2002 13:55:26 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 13:55:34 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B020AF7A6@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: idr@merit.edu, "'isp-bgp@isp-bgp.com'" , isp-routing@isp-routing.com Subject: bgp pruning Date: Thu, 6 Jun 2002 13:55:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D83.598E4C90" Sender: owner-idr@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D83.598E4C90 Content-Type: text/plain Given the following config: DUT-------r2 l l l l l l r3--------r4 All routers are in different AS's. The AS # is the router #. r3 showed that the DUT was sending the routes that originated from r3 with an AS path of 3 4 2 1 (which is the correct AS path). The expected behavior is for the DUT to not send these routes since they will be denied by r3 anyway as part of the BGP pruning process; this is what a major vendor does (prunes on the output as well). But the RFC1771 does not require that these routes not be sent (it does require that they be pruned at the input of r3). It seems to me that it IS better to do it the way the major vendor does it (prune at input and output) in order to save BW and processing. Why does RFC1771/the 17th draft not specify output pruning (or does it)? Can/should this be added? What does that other major vendor do? How am I doing on my political correctness? Thank you. ------_=_NextPart_001_01C20D83.598E4C90 Content-Type: text/html

 

Given the following config:

DUT-------r2

l         l

l         l

l         l

r3--------r4

 

All routers are in different AS's.  The AS # is the router #.  r3 showed that the DUT was sending the routes that originated from r3 with an AS path of 3 4 2 1 (which is the correct AS path).  The expected behavior is for the DUT to not send these routes since they will be denied by r3 anyway as part of the BGP pruning process; this is what a major vendor does (prunes on the output as well). But the RFC1771 does not require that these routes not be sent (it does require that they be pruned at the input of r3).  It seems to me that it IS better to do it the way the major vendor does it (prune at input and output) in order to save BW and processing.

 

Why does RFC1771/the 17th draft not specify output pruning (or does it)? 

 

Can/should this be added?

 

What does that other major vendor do?

 

How am I doing on my political correctness?

 

Thank you.

 

------_=_NextPart_001_01C20D83.598E4C90-- 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 NAA09015 for ; Thu, 6 Jun 2002 13:36:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AAD8912B5; Thu, 6 Jun 2002 13:34:31 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3656912D7; Thu, 6 Jun 2002 13:34:30 -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 67DA2912B5 for ; Thu, 6 Jun 2002 13:33:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E7FA5DDF4; Thu, 6 Jun 2002 13:33:04 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id ADCEB5DDAB for ; Thu, 6 Jun 2002 13:33:03 -0400 (EDT) Received: from [171.69.182.155] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA17513 for ; Thu, 6 Jun 2002 13:33:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <3CFF908D.58DC1F16@research.bell-labs.com> References: <39469E08BD83D411A3D900204840EC5582271A@vie-msgusr-01.dc.fore.com> <3CFF908D.58DC1F16@research.bell-labs.com> Date: Thu, 6 Jun 2002 13:33:03 -0400 To: idr@merit.edu From: "John G. Scudder" Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 12:40 PM -0400 6/6/02, Anindya Basu wrote: >"Abarbanel, Benjamin" wrote: > > Sounds to me like all the proposals so far attempt to reduce the >> probability of route oscillations, but do not control or stop it > > totally. So I think another approach is warranted. > >not quite, the proposal by wilfong et. al. actually stops it totally and >we can prove it. I know it's been said before (and recently) but a reminder just in case: scaling matters. Regards, --John 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 MAA06913 for ; Thu, 6 Jun 2002 12:42:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABAE1912BA; Thu, 6 Jun 2002 12:40:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C63E912B9; Thu, 6 Jun 2002 12:40: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 33393912AC for ; Thu, 6 Jun 2002 12:40:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28AB25DEB4; Thu, 6 Jun 2002 12:40:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with ESMTP id EFB555DDAB for ; Thu, 6 Jun 2002 12:40:48 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56GfCUL002688; Thu, 6 Jun 2002 12:41:12 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56Gejk69049; Thu, 6 Jun 2002 12:40:45 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56Gejjq62368057; Thu, 6 Jun 2002 12:40:45 -0400 (EDT) Message-ID: <3CFF908D.58DC1F16@research.bell-labs.com> Date: Thu, 06 Jun 2002 12:40:45 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Abarbanel, Benjamin" Cc: "'Gordon Wilfong'" , Enke Chen , idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <39469E08BD83D411A3D900204840EC5582271A@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk "Abarbanel, Benjamin" wrote: > > Sounds to me like all the proposals so far attempt to reduce the > probability of route oscillations, but do not control or stop it > totally. So I think another approach is warranted. > > Ben > not quite, the proposal by wilfong et. al. actually stops it totally and we can prove it. -anindya 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 MAA06253 for ; Thu, 6 Jun 2002 12:24:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A0F8912A6; Thu, 6 Jun 2002 12:24:14 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D6D0912A8; Thu, 6 Jun 2002 12:24:14 -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 02D36912A6 for ; Thu, 6 Jun 2002 12:24:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC8275DDA1; Thu, 6 Jun 2002 12:24:07 -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 AE4F45DD9C for ; Thu, 6 Jun 2002 12:24:07 -0400 (EDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 8B590449A30; Thu, 6 Jun 2002 09:24:14 -0700 (PDT) To: Gordon Wilfong Cc: Pedro Roque Marques , idr@merit.edu, enke@redback.com Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: Message from Gordon Wilfong of "Thu, 06 Jun 2002 08:03:17 EDT." <3CFF4F85.7566@research.bell-labs.com> Date: Thu, 06 Jun 2002 09:24:14 -0700 From: Enke Chen Message-Id: <20020606162414.8B590449A30@prattle.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Gordon: As I posted in the previous message, the local speaker does not have any control over the router-id allocation of the remote speaker. In addition, the router-id of the remote speaker can change without the prior knowledge of the local speaker. In that sense, the two external paths are equally good for the local speaker when the router-id has to be compared in route selection. We obvious are of different opinions on how big an issue the "non-deterministic behavior" (which one to select) is for a customer. Our opinions may not matter that much as compared to customers'. As we seem to be getting philosophical in the discussion thread, let me add some of my own. A "zero-cost" optimization is the the best thing, however, most of the time that is not possible. The next best thing is the "near-zero-cost" optimization, which IMO the approach of avoiding EBGP path switch (base on router-id) achieves. -- Enke > Message-ID: <3CFF4F85.7566@research.bell-labs.com> > Date: Thu, 06 Jun 2002 08:03:17 -0400 > To: Pedro Roque Marques > Cc: Enke Chen , idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > References: > <200206052259.g55MxJD84331@roque-bsd.juniper.net> > <20020605231454.C38A17E6C1@popserv3.redback.com> <200206052330.g55NUxC84403@roque-bsd.juniper.net> > > Hi Pedro, > > I completely agree with your statement that theoretical models > are essential in permitting a thorough understanding of > the behavior of systems. > > I also agree with you when you say that nondeterministic behavior > is a significant operational problem in that it makes reasoning > about your network, and hence debugging your network, difficult. > > One aspect of nondeterministic behavior is something we called > "transient oscillations" in our sigcomm 2002 paper. These > are instances where extreme timing coincidences could cause > route oscillations but such coincidences are > very unlikely. The more > significant aspect is that they indicate that there are more > than one stable routing states that the system could fall into. > That is, the behavior, while convergent, is nondeterministic. > > So for instance, the following example has two solutions. Given > very unlikely timing coincidences it could exhibit route oscillations. > > > ................................. > . AS0 . > . > . > . . > . [R1]***************[R2] > . > . * * * * > . > . 2 * *1 1 * *2 > . > .....*....* .....* > .....*....... > * * * > * > * * * > * > (0) * * * > * > * *(1) (1) * * > (0) > * * * > * > [AS1] [AS2] > > This example comes from a paper Tim Griffin and I are working > on. The numbers in parens are the MED values and the unadorned > numbers indicate BGP tie breaking rules (the lower the number > the more preferred the route). R1 and R2 are just > two (fully-meshed) routers, not necessarily route reflectors > in AS0. So one solution is where > R1 chooses to go through AS1 and R2 chooses to go through AS2. > Another solution is where R1 goes through AS2 and R2 goes through > AS1. It all depends on timing which routing gets established. > And the 2nd solution actually has the property that it violates > the semantics of MEDs in that both routers end up with routes > with higher MED values than other available routes through > the same neighboring AS. > > Since the modification to IBGP that we describe in > draft-wilfong-IBGP-oscillations-00.txt is guaranteed > to eliminate such transient oscillations (as well as > persistent oscillations), it guarantees not only will > any system converge, but it will converge deterministically > to the same solution irrespective of timing issues. > (The solution our method would result in would be the > first one with each Ri choosing the route through ASi.) > > - Gordon > > > Pedro Roque Marques wrote: > > > > Enke Chen writes: > > > > >> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: > > >> <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque > > >> Marques To: Enke Chen Cc: > > >> Gordon Wilfong , idr@merit.edu Subject: > > >> Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: > > >> <20020605214213.677367E6C1@popserv3.redback.com> > > >> > > >> Enke Chen writes: > > >> > > >> > Hi, Gordon: As you correctly pointed out: > > >> > > >> > > >> > o The code has been deployment for almost 3 years that (by > > > >> default) avoid the switch between two EBGP paths when the route > > > >> selection goes to the "random" steps (e.g., router-id > > > >> comparison). As a result, C1 would converge to AS1 as the > > >> best. This > is another way to resolve this case. > > >> > > >> > Now you know the real reason why that step was introduced in the > > >> > route selection :-) > > >> > > >> Avoiding the switch between paths doesn't avoid 'random' steps. It > > >> is itself a 'random' step in which the factor is arrival time of > > >> the route making it random and non-deterministic. > > > > > Let me clarify: I did not mean the step is "random" (sorry). I mean > > > the result of the step is random. For example, a BGP speaker does > > > not have any control over what router-id an EBGP peer will use (or > > > change). In that case, it really does not matter to the speaker > > > which EBGP path to choose when the route selection goes all the way > > > to comparing router-id. > > > > It matters that the router-id test is deterministic, i.e. predictable, > > while arrival order isn't. > > > > >> If there are cases where this seems a good idea there is an equal > > >> number of cases where it makes things worse. > > > > > Is there a specific example that avoid EBGP switch (based on > > > router-id) makes things worse? > > > > The main problem, imho, is that given a set of offered paths you > > cannot predict the behaviour, i.e. which path will be selected since > > it is not possible to predict the arrival order of the paths in a > > system. Personally i think that is a significant operational problem > > by itself. > > > > In this discussion, for instance, people attempt to given a set of > > paths predict the behaviour to check if it is stable or not and assume > > a deterministic behaviour in order to do so. In certain > > implementations that assumption is actually not correct. > > > > Although the IDR WG typically attempts to have a 'pratical' > > prespective on things, "theoretical" models are important in that they > > allow you to understand pratical behaviour. > > > > Let me put things in another way... even if i can't from the top of my > > head present you an example of what problems it causes, it doesn't > > mean that one can assert that it doesn't introduce new > > issues. i.e. lack of negative proof doesn't prove something. > > > > 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 MAA05963 for ; Thu, 6 Jun 2002 12:18:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86FE3912A5; Thu, 6 Jun 2002 12:17:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A92E912A6; Thu, 6 Jun 2002 12:17: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 4492B912A5 for ; Thu, 6 Jun 2002 12:17:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4485C5DDA1; Thu, 6 Jun 2002 12:17:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id BE6865DD9C for ; Thu, 6 Jun 2002 12:17:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18009; Thu, 6 Jun 2002 12:17:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28643; Thu, 6 Jun 2002 12:17:46 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jun 2002 12:17:46 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5582271A@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Gordon Wilfong'" , Enke Chen Cc: idr@merit.edu Subject: RE: draft-chen-rr-oscillation-reduce-00.txt Date: Thu, 6 Jun 2002 12:17: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 Sounds to me like all the proposals so far attempt to reduce the probability of route oscillations, but do not control or stop it totally. So I think another approach is warranted. Ben -----Original Message----- From: Gordon Wilfong [mailto:gtw@research.bell-labs.com] Sent: Wednesday, June 05, 2002 4:14 PM To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt Unfortunately, this method can fail to prevent persistent oscillations. Consider the example below that appears in a work in progress by Tim Griffin and Gordon Wilfong. There is a single cluster with one route reflector [RR1] and two client routers [C1] and [C2]. The client routers get routes from outside their AS from [AS1] and [AS2]. The numbers in parentheses represent the MED values. The unadorned numbers on the links between [RR1] and its clients are the IGP metric values. The unadorned numbers on the links from the client [C1] to the two outside ASes represent [C1]'s preference according to BGP tie breaking (with lower number representing the more preferred route). The example has the property that it suffers from persistent route oscillations. However the method discussed in draft-chen-rr-oscillation-reduce-00.txt will not prevent this oscillation since the route reflector's best route is always a client's route and so the method's behavior will be unchanged from unmodified I-BGP. 4 [RR1] ************* * * 1 * * * * * * * * [C1] [C2] *** * 2 * * 1 * * * * (2) * (1) * * (0) * * * [AS1] **[AS2] - Gordon Enke Chen wrote: > > Hi, folks: > Two drafts are posted: > > o draft-chen-rr-oscillation-reduce-00.txt > o draft-chen-confed-oscillation-reduce-00.txt > > A simple proposal for Route Reflection and one for Confederration > are presented for presistent route oscillation reduction. Based > on our computation, they resolve all the persisitent route oscillation > cases documented. > > If you have a persistent route oscillatin case that can not be resolved > by these proposals, we will appreciate greatly if you let us know. > > Comments? > > Regards, -- Enke > > ------- Forwarded Message > > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt > Date: Wed, 05 Jun 2002 07:33:23 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : BGP Route Oscillation Reduction with Route Reflection > Author(s) : E. Chen > Filename : draft-chen-rr-oscillation-reduce-00.txt > Pages : 4 > Date : 04-Jun-02 > > This document proposes a simple revision to Route Reflection that > allows a Route Reflector to advertise the best path from its clients > to other clusters when the overall best path for the RR differs. The > availability of the routing information to other clusters helps > achieve stable route selection, and moves route reflection closer to > IBGP full-mesh equivalence in terms of routing information. It has > been shown that the proposed mechanism eliminates a number of > persistent route oscillation cases involving Route Reflection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt > > ------- End of Forwarded Message 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 IAA26344 for ; Thu, 6 Jun 2002 08:04:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 577E19128B; Thu, 6 Jun 2002 08:03:29 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CEBB9128D; Thu, 6 Jun 2002 08:03:29 -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 B5FD49128B for ; Thu, 6 Jun 2002 08:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D7EE5DD9C; Thu, 6 Jun 2002 08:03:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 9B5A45DEB4 for ; Thu, 6 Jun 2002 08:03:17 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g56C3OEF049134; Thu, 6 Jun 2002 08:03:24 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56C3Hk44884; Thu, 6 Jun 2002 08:03:18 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id IAA1926515; Thu, 6 Jun 2002 08:03:17 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id IAA16306; Thu, 6 Jun 2002 08:03:18 -0400 (EDT) Message-ID: <3CFF4F85.7566@research.bell-labs.com> Date: Thu, 06 Jun 2002 08:03:17 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: Pedro Roque Marques Cc: Enke Chen , idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <200206052259.g55MxJD84331@roque-bsd.juniper.net> <20020605231454.C38A17E6C1@popserv3.redback.com> <200206052330.g55NUxC84403@roque-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Hi Pedro, I completely agree with your statement that theoretical models are essential in permitting a thorough understanding of the behavior of systems. I also agree with you when you say that nondeterministic behavior is a significant operational problem in that it makes reasoning about your network, and hence debugging your network, difficult. One aspect of nondeterministic behavior is something we called "transient oscillations" in our sigcomm 2002 paper. These are instances where extreme timing coincidences could cause route oscillations but such coincidences are very unlikely. The more significant aspect is that they indicate that there are more than one stable routing states that the system could fall into. That is, the behavior, while convergent, is nondeterministic. So for instance, the following example has two solutions. Given very unlikely timing coincidences it could exhibit route oscillations. ................................. . AS0 . . . . . . [R1]***************[R2] . . * * * * . . 2 * *1 1 * *2 . .....*....* .....* .....*....... * * * * * * * * (0) * * * * * *(1) (1) * * (0) * * * * [AS1] [AS2] This example comes from a paper Tim Griffin and I are working on. The numbers in parens are the MED values and the unadorned numbers indicate BGP tie breaking rules (the lower the number the more preferred the route). R1 and R2 are just two (fully-meshed) routers, not necessarily route reflectors in AS0. So one solution is where R1 chooses to go through AS1 and R2 chooses to go through AS2. Another solution is where R1 goes through AS2 and R2 goes through AS1. It all depends on timing which routing gets established. And the 2nd solution actually has the property that it violates the semantics of MEDs in that both routers end up with routes with higher MED values than other available routes through the same neighboring AS. Since the modification to IBGP that we describe in draft-wilfong-IBGP-oscillations-00.txt is guaranteed to eliminate such transient oscillations (as well as persistent oscillations), it guarantees not only will any system converge, but it will converge deterministically to the same solution irrespective of timing issues. (The solution our method would result in would be the first one with each Ri choosing the route through ASi.) - Gordon Pedro Roque Marques wrote: > > Enke Chen writes: > > >> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: > >> <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque > >> Marques To: Enke Chen Cc: > >> Gordon Wilfong , idr@merit.edu Subject: > >> Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: > >> <20020605214213.677367E6C1@popserv3.redback.com> > >> > >> Enke Chen writes: > >> > >> > Hi, Gordon: As you correctly pointed out: > >> > >> > >> > o The code has been deployment for almost 3 years that (by > > >> default) avoid the switch between two EBGP paths when the route > > >> selection goes to the "random" steps (e.g., router-id > > >> comparison). As a result, C1 would converge to AS1 as the > >> best. This > is another way to resolve this case. > >> > >> > Now you know the real reason why that step was introduced in the > >> > route selection :-) > >> > >> Avoiding the switch between paths doesn't avoid 'random' steps. It > >> is itself a 'random' step in which the factor is arrival time of > >> the route making it random and non-deterministic. > > > Let me clarify: I did not mean the step is "random" (sorry). I mean > > the result of the step is random. For example, a BGP speaker does > > not have any control over what router-id an EBGP peer will use (or > > change). In that case, it really does not matter to the speaker > > which EBGP path to choose when the route selection goes all the way > > to comparing router-id. > > It matters that the router-id test is deterministic, i.e. predictable, > while arrival order isn't. > > >> If there are cases where this seems a good idea there is an equal > >> number of cases where it makes things worse. > > > Is there a specific example that avoid EBGP switch (based on > > router-id) makes things worse? > > The main problem, imho, is that given a set of offered paths you > cannot predict the behaviour, i.e. which path will be selected since > it is not possible to predict the arrival order of the paths in a > system. Personally i think that is a significant operational problem > by itself. > > In this discussion, for instance, people attempt to given a set of > paths predict the behaviour to check if it is stable or not and assume > a deterministic behaviour in order to do so. In certain > implementations that assumption is actually not correct. > > Although the IDR WG typically attempts to have a 'pratical' > prespective on things, "theoretical" models are important in that they > allow you to understand pratical behaviour. > > Let me put things in another way... even if i can't from the top of my > head present you an example of what problems it causes, it doesn't > mean that one can assert that it doesn't introduce new > issues. i.e. lack of negative proof doesn't prove something. > > 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 TAA29840 for ; Wed, 5 Jun 2002 19:32:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E309391285; Wed, 5 Jun 2002 19:30:59 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B086791286; Wed, 5 Jun 2002 19:30: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 4744F91285 for ; Wed, 5 Jun 2002 19:30:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F5A85DEB5; Wed, 5 Jun 2002 19:30:53 -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 6AF5A5DDBC for ; Wed, 5 Jun 2002 19:30:52 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g55NV0m94210; Wed, 5 Jun 2002 16:31:00 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g55NUxC84403; Wed, 5 Jun 2002 16:30:59 -0700 (PDT) (envelope-from roque) Date: Wed, 5 Jun 2002 16:30:59 -0700 (PDT) Message-Id: <200206052330.g55NUxC84403@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: <20020605231454.C38A17E6C1@popserv3.redback.com> References: <200206052259.g55MxJD84331@roque-bsd.juniper.net> <20020605231454.C38A17E6C1@popserv3.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Enke Chen writes: >> Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: >> <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque >> Marques To: Enke Chen Cc: >> Gordon Wilfong , idr@merit.edu Subject: >> Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: >> <20020605214213.677367E6C1@popserv3.redback.com> >> >> Enke Chen writes: >> >> > Hi, Gordon: As you correctly pointed out: >> >> >> > o The code has been deployment for almost 3 years that (by > >> default) avoid the switch between two EBGP paths when the route > >> selection goes to the "random" steps (e.g., router-id > >> comparison). As a result, C1 would converge to AS1 as the >> best. This > is another way to resolve this case. >> >> > Now you know the real reason why that step was introduced in the >> > route selection :-) >> >> Avoiding the switch between paths doesn't avoid 'random' steps. It >> is itself a 'random' step in which the factor is arrival time of >> the route making it random and non-deterministic. > Let me clarify: I did not mean the step is "random" (sorry). I mean > the result of the step is random. For example, a BGP speaker does > not have any control over what router-id an EBGP peer will use (or > change). In that case, it really does not matter to the speaker > which EBGP path to choose when the route selection goes all the way > to comparing router-id. It matters that the router-id test is deterministic, i.e. predictable, while arrival order isn't. >> If there are cases where this seems a good idea there is an equal >> number of cases where it makes things worse. > Is there a specific example that avoid EBGP switch (based on > router-id) makes things worse? The main problem, imho, is that given a set of offered paths you cannot predict the behaviour, i.e. which path will be selected since it is not possible to predict the arrival order of the paths in a system. Personally i think that is a significant operational problem by itself. In this discussion, for instance, people attempt to given a set of paths predict the behaviour to check if it is stable or not and assume a deterministic behaviour in order to do so. In certain implementations that assumption is actually not correct. Although the IDR WG typically attempts to have a 'pratical' prespective on things, "theoretical" models are important in that they allow you to understand pratical behaviour. Let me put things in another way... even if i can't from the top of my head present you an example of what problems it causes, it doesn't mean that one can assert that it doesn't introduce new issues. i.e. lack of negative proof doesn't prove something. 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 TAA29393 for ; Wed, 5 Jun 2002 19:17:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8C3691284; Wed, 5 Jun 2002 19:14:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7856A91287; Wed, 5 Jun 2002 19:14:58 -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 F129D91284 for ; Wed, 5 Jun 2002 19:14:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C29F75DEC8; Wed, 5 Jun 2002 19:14:47 -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 885995DEC7 for ; Wed, 5 Jun 2002 19:14:47 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id D449E262804; Wed, 5 Jun 2002 16:14:54 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id C38A17E6C1; Wed, 5 Jun 2002 16:14:54 -0700 (PDT) To: Pedro Roque Marques Cc: Gordon Wilfong , idr@merit.edu, enke@redback.com Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: Message from Pedro Roque Marques of "Wed, 05 Jun 2002 15:59:20 PDT." <200206052259.g55MxJD84331@roque-bsd.juniper.net> Date: Wed, 05 Jun 2002 16:14:54 -0700 From: Enke Chen Message-Id: <20020605231454.C38A17E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) > Message-Id: <200206052259.g55MxJD84331@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: Enke Chen > Cc: Gordon Wilfong , idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > In-Reply-To: <20020605214213.677367E6C1@popserv3.redback.com> > > Enke Chen writes: > > > Hi, Gordon: As you correctly pointed out: > > > > o The code has been deployment for almost 3 years that (by > > default) avoid the switch between two EBGP paths when the route > > selection goes to the "random" steps (e.g., router-id > > comparison). As a result, C1 would converge to AS1 as the best. This > > is another way to resolve this case. > > > Now you know the real reason why that step was introduced in the > > route selection :-) > > Avoiding the switch between paths doesn't avoid 'random' steps. It is > itself a 'random' step in which the factor is arrival time of the > route making it random and non-deterministic. Let me clarify: I did not mean the step is "random" (sorry). I mean the result of the step is random. For example, a BGP speaker does not have any control over what router-id an EBGP peer will use (or change). In that case, it really does not matter to the speaker which EBGP path to choose when the route selection goes all the way to comparing router-id. > > If there are cases where this seems a good idea there is an equal > number of cases where it makes things worse. Is there a specific example that avoid EBGP switch (based on router-id) makes things worse? > > I was under the impression that the "real reason" is much more related > to certain implementation choices a vendor we used to work for has in > their implementation that make it really hard for said implementation > to suppress duplicate updates ;-) No, it was not the duplicate update. It was a real churn (involving RR) seen on one of the large ISP networks in the US three years ago. Srihari was the one that logged into the routers and first identified the churn. Regards, -- Enke 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 TAA28867 for ; Wed, 5 Jun 2002 19:01:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9532C9128D; Wed, 5 Jun 2002 18:59:27 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70A5F9128B; Wed, 5 Jun 2002 18:59:27 -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 0C83591283 for ; Wed, 5 Jun 2002 18:59:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9CDB5DEC8; Wed, 5 Jun 2002 18:59:15 -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 82C005DEC6 for ; Wed, 5 Jun 2002 18:59:15 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g55MxKm91920; Wed, 5 Jun 2002 15:59:20 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g55MxJD84331; Wed, 5 Jun 2002 15:59:20 -0700 (PDT) (envelope-from roque) Date: Wed, 5 Jun 2002 15:59:20 -0700 (PDT) Message-Id: <200206052259.g55MxJD84331@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: Gordon Wilfong , idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: <20020605214213.677367E6C1@popserv3.redback.com> References: <3CFE70F4.63DE@research.bell-labs.com> <20020605214213.677367E6C1@popserv3.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Enke Chen writes: > Hi, Gordon: As you correctly pointed out: > o The code has been deployment for almost 3 years that (by > default) avoid the switch between two EBGP paths when the route > selection goes to the "random" steps (e.g., router-id > comparison). As a result, C1 would converge to AS1 as the best. This > is another way to resolve this case. > Now you know the real reason why that step was introduced in the > route selection :-) Avoiding the switch between paths doesn't avoid 'random' steps. It is itself a 'random' step in which the factor is arrival time of the route making it random and non-deterministic. If there are cases where this seems a good idea there is an equal number of cases where it makes things worse. I was under the impression that the "real reason" is much more related to certain implementation choices a vendor we used to work for has in their implementation that make it really hard for said implementation to suppress duplicate updates ;-) 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 RAA26105 for ; Wed, 5 Jun 2002 17:42:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31D4F9127D; Wed, 5 Jun 2002 17:42:14 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03A3A9127E; Wed, 5 Jun 2002 17:42:13 -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 E188B9127D for ; Wed, 5 Jun 2002 17:42:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B76885DE8E; Wed, 5 Jun 2002 17:42:07 -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 31CAA5DE88 for ; Wed, 5 Jun 2002 17:42:07 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id C4F3E1DCC77; Wed, 5 Jun 2002 14:42:13 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 677367E6C1; Wed, 5 Jun 2002 14:42:13 -0700 (PDT) To: Gordon Wilfong Cc: idr@merit.edu, enke@redback.com Subject: Re: draft-chen-rr-oscillation-reduce-00.txt In-Reply-To: Message from Gordon Wilfong of "Wed, 05 Jun 2002 16:13:40 EDT." <3CFE70F4.63DE@research.bell-labs.com> Date: Wed, 05 Jun 2002 14:42:13 -0700 From: Enke Chen Message-Id: <20020605214213.677367E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Gordon: As you correctly pointed out: > However the method discussed in draft-chen-rr-oscillation-reduce-00.txt > will not prevent this oscillation since the route reflector's best route > is always a client's route and so the method's behavior will be unchanged > from unmodified I-BGP. > The proposal presented in draft-chen-rr-oscillation-reduce-00.txt does not impact this case. However, a couple comments on this case: o In general a route oscillation within a cluster can be resolved easily by full-mesh the clients within the cluster, which does not have a scalability issue, and is a better operational model. This is one way to resolve this case. o The code has been deployment for almost 3 years that (by default) avoid the switch between two EBGP paths when the route selection goes to the "random" steps (e.g., router-id comparison). As a result, C1 would converge to AS1 as the best. This is another way to resolve this case. Now you know the real reason why that step was introduced in the route selection :-) Regards, -- Enke > Message-ID: <3CFE70F4.63DE@research.bell-labs.com> > Date: Wed, 05 Jun 2002 16:13:40 -0400 > From: Gordon Wilfong > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: draft-chen-rr-oscillation-reduce-00.txt > References: <20020605142818.050FD979C1@popserv2.redback.com> > > Unfortunately, this method can fail to > prevent persistent oscillations. > > Consider the example below that appears in a work > in progress by Tim Griffin and Gordon Wilfong. > There is a single cluster with one route reflector [RR1] and two > client routers [C1] and [C2]. The client routers > get routes from outside their AS from [AS1] and > [AS2]. The numbers in parentheses represent the > MED values. The unadorned numbers on the links between > [RR1] and its clients are the IGP metric values. > The unadorned numbers on the links from the client [C1] > to the two outside ASes represent [C1]'s preference > according to BGP tie breaking (with lower number representing > the more preferred route). > The example has the property that it suffers from persistent > route oscillations. However the method discussed in > draft-chen-rr-oscillation-reduce-00.txt will not prevent this > oscillation since the route reflector's best route is always > a client's route and so the method's behavior will be unchanged > from unmodified I-BGP. > > 4 > [RR1] ************* > * * > 1 * * > * * > * * > * * > [C1] [C2] > *** * > 2 * * 1 * > * * * > (2) * (1) * * (0) > * * * > [AS1] **[AS2] > > > > > - Gordon > > > > > > > > > > Enke Chen wrote: > > > > Hi, folks: > > Two drafts are posted: > > > > o draft-chen-rr-oscillation-reduce-00.txt > > o draft-chen-confed-oscillation-reduce-00.txt > > > > A simple proposal for Route Reflection and one for Confederration > > are presented for presistent route oscillation reduction. Based > > on our computation, they resolve all the persisitent route oscillation > > cases documented. > > > > If you have a persistent route oscillatin case that can not be resolved > > by these proposals, we will appreciate greatly if you let us know. > > > > Comments? > > > > Regards, -- Enke > > > > ------- Forwarded Message > > > > To: IETF-Announce: ; > > From: Internet-Drafts@ietf.org > > Reply-To: Internet-Drafts@ietf.org > > Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt > > Date: Wed, 05 Jun 2002 07:33:23 -0400 > > Sender: nsyracus@cnri.reston.va.us > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : BGP Route Oscillation Reduction with Route Reflection > > Author(s) : E. Chen > > Filename : draft-chen-rr-oscillation-reduce-00.txt > > Pages : 4 > > Date : 04-Jun-02 > > > > This document proposes a simple revision to Route Reflection that > > allows a Route Reflector to advertise the best path from its clients > > to other clusters when the overall best path for the RR differs. The > > availability of the routing information to other clusters helps > > achieve stable route selection, and moves route reflection closer to > > IBGP full-mesh equivalence in terms of routing information. It has > > been shown that the proposed mechanism eliminates a number of > > persistent route oscillation cases involving Route Reflection. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt > > > > ------- End of Forwarded Message 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 QAA23302 for ; Wed, 5 Jun 2002 16:14:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7FF9D9127D; Wed, 5 Jun 2002 16:13:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CCB791253; Wed, 5 Jun 2002 16:13: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 379769127E for ; Wed, 5 Jun 2002 16:13:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E729A5DDB7; Wed, 5 Jun 2002 16:13:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id ADCE05DE96 for ; Wed, 5 Jun 2002 16:13:40 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g55KDmEF043538; Wed, 5 Jun 2002 16:13:48 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g55KDfo41198; Wed, 5 Jun 2002 16:13:41 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id QAA1892716; Wed, 5 Jun 2002 16:13:41 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id QAA06628; Wed, 5 Jun 2002 16:13:40 -0400 (EDT) Message-ID: <3CFE70F4.63DE@research.bell-labs.com> Date: Wed, 05 Jun 2002 16:13:40 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: Enke Chen Cc: idr@merit.edu Subject: Re: draft-chen-rr-oscillation-reduce-00.txt References: <20020605142818.050FD979C1@popserv2.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Unfortunately, this method can fail to prevent persistent oscillations. Consider the example below that appears in a work in progress by Tim Griffin and Gordon Wilfong. There is a single cluster with one route reflector [RR1] and two client routers [C1] and [C2]. The client routers get routes from outside their AS from [AS1] and [AS2]. The numbers in parentheses represent the MED values. The unadorned numbers on the links between [RR1] and its clients are the IGP metric values. The unadorned numbers on the links from the client [C1] to the two outside ASes represent [C1]'s preference according to BGP tie breaking (with lower number representing the more preferred route). The example has the property that it suffers from persistent route oscillations. However the method discussed in draft-chen-rr-oscillation-reduce-00.txt will not prevent this oscillation since the route reflector's best route is always a client's route and so the method's behavior will be unchanged from unmodified I-BGP. 4 [RR1] ************* * * 1 * * * * * * * * [C1] [C2] *** * 2 * * 1 * * * * (2) * (1) * * (0) * * * [AS1] **[AS2] - Gordon Enke Chen wrote: > > Hi, folks: > Two drafts are posted: > > o draft-chen-rr-oscillation-reduce-00.txt > o draft-chen-confed-oscillation-reduce-00.txt > > A simple proposal for Route Reflection and one for Confederration > are presented for presistent route oscillation reduction. Based > on our computation, they resolve all the persisitent route oscillation > cases documented. > > If you have a persistent route oscillatin case that can not be resolved > by these proposals, we will appreciate greatly if you let us know. > > Comments? > > Regards, -- Enke > > ------- Forwarded Message > > To: IETF-Announce: ; > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt > Date: Wed, 05 Jun 2002 07:33:23 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : BGP Route Oscillation Reduction with Route Reflection > Author(s) : E. Chen > Filename : draft-chen-rr-oscillation-reduce-00.txt > Pages : 4 > Date : 04-Jun-02 > > This document proposes a simple revision to Route Reflection that > allows a Route Reflector to advertise the best path from its clients > to other clusters when the overall best path for the RR differs. The > availability of the routing information to other clusters helps > achieve stable route selection, and moves route reflection closer to > IBGP full-mesh equivalence in terms of routing information. It has > been shown that the proposed mechanism eliminates a number of > persistent route oscillation cases involving Route Reflection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt > > ------- End of Forwarded Message 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 KAA10878 for ; Wed, 5 Jun 2002 10:29:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0C8691270; Wed, 5 Jun 2002 10:28:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A07B391271; Wed, 5 Jun 2002 10:28:28 -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 967C791270 for ; Wed, 5 Jun 2002 10:28:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55F365DE7D; Wed, 5 Jun 2002 10:28:22 -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 1A9275DE64 for ; Wed, 5 Jun 2002 10:28:22 -0400 (EDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id D9C11FC05E; Wed, 5 Jun 2002 07:28:28 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 050FD979C1; Wed, 5 Jun 2002 07:28:17 -0700 (PDT) To: idr@merit.edu Cc: enke@redback.com Subject: draft-chen-rr-oscillation-reduce-00.txt Date: Wed, 05 Jun 2002 07:28:17 -0700 From: Enke Chen Message-Id: <20020605142818.050FD979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: Two drafts are posted: o draft-chen-rr-oscillation-reduce-00.txt o draft-chen-confed-oscillation-reduce-00.txt A simple proposal for Route Reflection and one for Confederration are presented for presistent route oscillation reduction. Based on our computation, they resolve all the persisitent route oscillation cases documented. If you have a persistent route oscillatin case that can not be resolved by these proposals, we will appreciate greatly if you let us know. Comments? Regards, -- Enke ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-rr-oscillation-reduce-00.txt Date: Wed, 05 Jun 2002 07:33:23 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Route Oscillation Reduction with Route Reflection Author(s) : E. Chen Filename : draft-chen-rr-oscillation-reduce-00.txt Pages : 4 Date : 04-Jun-02 This document proposes a simple revision to Route Reflection that allows a Route Reflector to advertise the best path from its clients to other clusters when the overall best path for the RR differs. The availability of the routing information to other clusters helps achieve stable route selection, and moves route reflection closer to IBGP full-mesh equivalence in terms of routing information. It has been shown that the proposed mechanism eliminates a number of persistent route oscillation cases involving Route Reflection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rr-oscillation-reduce-00.txt ------- End of Forwarded Message 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 QAA22048 for ; Sat, 1 Jun 2002 16:18:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B43019121F; Sat, 1 Jun 2002 16:17:36 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862C6912C0; Sat, 1 Jun 2002 16:17:36 -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 618559121F for ; Sat, 1 Jun 2002 16:17:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C1625DE2E; Sat, 1 Jun 2002 16:17:29 -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 DCE2B5DD8D for ; Sat, 1 Jun 2002 16:17:28 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 05C924BA213; Sat, 1 Jun 2002 13:17:35 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id C1A8E15D3C1; Sat, 1 Jun 2002 13:17:32 -0700 (PDT) To: "John G. Scudder" Cc: Alvaro Retana , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, enke@redback.com Subject: Re: Comments on draft-walton-bgp-add-paths-00.txt In-Reply-To: Message from "John G. Scudder" of "Sat, 01 Jun 2002 15:17:34 EDT." Date: Sat, 01 Jun 2002 13:17:31 -0700 From: Enke Chen Message-Id: <20020601201732.C1A8E15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, John: > Date: Sat, 1 Jun 2002 15:17:34 -0400 > To: Enke Chen > From: "John G. Scudder" > Subject: Re: Comments on draft-walton-bgp-add-paths-00.txt > Cc: Alvaro Retana , idr@merit.edu, > dwalton@cisco.com, dacook@cisco.com, enke@redback.com > > At 11:35 AM -0700 5/31/02, Enke Chen wrote: > >The draft specifies a way to advertise and withdraw a path for a prefix. IMO > >per-path based update would require significant additional state > >(i.e., per-path > >instead of per prefix) and memory in order to avoid spurious withdraws that we > >experienced in the past. > > > >We could avoid the additional state and simplify implementation if we treat > >all the paths of a prefix as one unit in advertisement and withdraw. By "one > >Unit" I mean that all paths are advertised (could be in multiple messages) > >together, and are withdrawn by the NLRI. > > > >This can be accomplished by introducing two additional bit flags for the > >reachable NLRIs: > > > > o First Path Bit: When set, this indicates this is the first path for > > the prefix, and any existing paths should be removed. > > (This is similar to the current implicit replacement.) > > When clear, there is no implicit replacement. > > > > o Last Path Bit: When set, this indicates this is the last path, and > > bestpath selection should be done immediately. When > > clear, the bestpath selection may be deferred. > > This would help avoid FIB churn. > > > >Please note that with this approach there is no need to change the encoding > >of unreachable NLRIs, and the path "Identifier" field in the draft is no > >longer needed. > > Enke, > > This is slightly different from my earlier understanding of your > suggestion. I had understood that you were suggesting that the > first/last path bits be optional. I'm fine with them in that context. > > However, it seems you are suggesting that the proposal be further > modified so that use of first/last path would be the ONLY way to > replace routes (this is implied by the suggestion that the ID field > be dropped). This could cause substantial inefficiency due to the > need to re-advertise unchanged paths. I'm not in favor of dropping > the ID field. There is a tradeoff between maintaing additional state with the per-path based update and the duplicate path update with per-prefix based approach. The suggestion I posted in the previous message is for "per-prefix" based update. Actually it seems to be mainly an implementation decision whether to use per-path based update or per-prefix based update. The protocol could be made flexiable to accomodate both implementations. For that purpose, we will need to define a mechanism to withdraw all paths of a prefix (w/o replacement path). This could be a via flag, or by using a special ID number (e.g., the largest). Thanks. -- Enke 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 PAA19988 for ; Sat, 1 Jun 2002 15:18:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C0D139120D; Sat, 1 Jun 2002 15:17:51 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90AEE9121F; Sat, 1 Jun 2002 15:17:51 -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 7A4C59120D for ; Sat, 1 Jun 2002 15:17:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74A9B5DE12; Sat, 1 Jun 2002 15:17:44 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id B42755DD8D for ; Sat, 1 Jun 2002 15:17:43 -0400 (EDT) Received: from [171.69.182.155] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA20755; Sat, 1 Jun 2002 15:17:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <20020531183559.0648E7E6C1@popserv3.redback.com> References: <20020531183559.0648E7E6C1@popserv3.redback.com> Date: Sat, 1 Jun 2002 15:17:34 -0400 To: Enke Chen From: "John G. Scudder" Subject: Re: Comments on draft-walton-bgp-add-paths-00.txt Cc: Alvaro Retana , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, enke@redback.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 11:35 AM -0700 5/31/02, Enke Chen wrote: >The draft specifies a way to advertise and withdraw a path for a prefix. IMO >per-path based update would require significant additional state >(i.e., per-path >instead of per prefix) and memory in order to avoid spurious withdraws that we >experienced in the past. > >We could avoid the additional state and simplify implementation if we treat >all the paths of a prefix as one unit in advertisement and withdraw. By "one >Unit" I mean that all paths are advertised (could be in multiple messages) >together, and are withdrawn by the NLRI. > >This can be accomplished by introducing two additional bit flags for the >reachable NLRIs: > > o First Path Bit: When set, this indicates this is the first path for > the prefix, and any existing paths should be removed. > (This is similar to the current implicit replacement.) > When clear, there is no implicit replacement. > > o Last Path Bit: When set, this indicates this is the last path, and > bestpath selection should be done immediately. When > clear, the bestpath selection may be deferred. > This would help avoid FIB churn. > >Please note that with this approach there is no need to change the encoding >of unreachable NLRIs, and the path "Identifier" field in the draft is no >longer needed. Enke, This is slightly different from my earlier understanding of your suggestion. I had understood that you were suggesting that the first/last path bits be optional. I'm fine with them in that context. However, it seems you are suggesting that the proposal be further modified so that use of first/last path would be the ONLY way to replace routes (this is implied by the suggestion that the ID field be dropped). This could cause substantial inefficiency due to the need to re-advertise unchanged paths. I'm not in favor of dropping the ID field. Regards, --John