From idr-bounces@ietf.org Wed Aug 09 14:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsbr-0007aQ-Bw; Wed, 09 Aug 2006 14:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsbo-0007aD-Gp; Wed, 09 Aug 2006 14:16:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAroX-0004rJ-Pe; Wed, 09 Aug 2006 13:25:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GArYy-00081g-BM; Wed, 09 Aug 2006 13:09:49 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4AF022AC40; Wed, 9 Aug 2006 17:09:18 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GArYU-0005Of-2J; Wed, 09 Aug 2006 13:09:18 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 09 Aug 2006 13:09:18 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: idr@ietf.org Subject: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'Autonomous System Confederations for BGP ' as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-05.txt Implementation Report can be accessed at http://www.ietf.org/IESG/Implementations/implem_RFC3065bis.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 09 16:22:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuYu-0007r9-Rt; Wed, 09 Aug 2006 16:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAuYt-0007qb-MR; Wed, 09 Aug 2006 16:21:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAtfS-0008L6-Bb; Wed, 09 Aug 2006 15:24:38 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAtQi-0001AN-N2; Wed, 09 Aug 2006 15:09:26 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A3B332ACA3; Wed, 9 Aug 2006 19:08:54 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAtQE-000712-Du; Wed, 09 Aug 2006 15:08:54 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG (draft-ooms-v6ops-bgp-tunnel)Reply-to: iesg@ietf.org Message-Id: Date: Wed, 09 Aug 2006 15:08:54 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: idr@ietf.org Subject: [Idr] Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-06.txt Implementation Report can be accessed at http://www.ietf.org/IESG/Implementations/Implementation_draft-levy-idr-6pe-survey.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 09 20:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAyqb-0004wU-Lf; Wed, 09 Aug 2006 20:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAyqZ-0004wP-Tm for idr@ietf.org; Wed, 09 Aug 2006 20:56:27 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAyqY-0004Bn-G9 for idr@ietf.org; Wed, 09 Aug 2006 20:56:27 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA14788; Wed, 9 Aug 2006 17:56:25 -0700 (PDT) Received: from manavLpt ([10.128.16.134]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 17:56:23 -0700 Message-ID: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: Date: Thu, 10 Aug 2006 06:26:17 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 10 Aug 2006 00:56:24.0811 (UTC) FILETIME=[CDB52BB0:01C6BC17] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Idr] Advertising Multiple Next Hop Routes in BGP X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, A revised draft of draft-bhatia-bgp-multiple-next-hops-01.txt has been posted to the internet draft repository. This revision simplifies the operation, and addresses some of the concerns expressed by IDR working group participants. The simplification comes primarily from removing a capability which analysis showed was purely informational. The previous draft amongst other things allowed for sending advertisements which differed on AS path but had the same next-hop. In discussions, it was noted that since these paths had the same next-hop, the receiver would need to combine them anyway. Therefore, the draft now requires that when sending multiple advertisements for the same NLRI, these advertisements must use differing next-hops. As a result of this, the next-hop becomes the distinguishing attribute, along with the NLRI, for the advertisement. Thus, implicit withdrawls are supported without needing to introduce additional indexing attributes. The proposal is compatible with IPv6 support, MPLS label advertisement, and BGP multi-protocol support. The text for optional support of only ECMP routes, a refinement of sending all routes with distinct next-hops for an NLRI, and the description of the constraints on how multiple advertisements are compressed when they are being used by a BGP speaker, will be folded in as a short portion of the next revision of this document or a separate draft as deemed fit by the WG. http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-01.txt Thanks, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 10 07:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB8ni-0001xp-4h; Thu, 10 Aug 2006 07:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB8nh-0001xH-A1; Thu, 10 Aug 2006 07:34:09 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB8nc-00062j-Ve; Thu, 10 Aug 2006 07:34:09 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1GB8nX-00063i-RA; Thu, 10 Aug 2006 13:33:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Date: Thu, 10 Aug 2006 13:33:58 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240BF27D@paul.adoffice.local.de.easynet.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Thread-Index: Aca74ASQNlL7g5SgSLOU3f6H+zZ/jgAj5YYg From: "Ilya Varlashkin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello, > -----Original Message----- > The IESG has received a request from the Inter-Domain Routing=20 > WG to consider the following document: >=20 > - 'Autonomous System Confederations for BGP ' > as a Draft Standard >=20 > The IESG plans to make a decision in the next few weeks, and=20 > solicits final comments on this action. Please send any=20 > comments to the iesg@ietf.org or ietf@ietf.org mailing lists=20 > by 2006-08-23. >=20 I've just went through the document and have one question. The draft specifies new segment types AS_CONFED_SEQUENCE and AS_CONFED_SET, and specifies how to handle AS_PATH containing such segment in received UPDATEs. There is also good amount of information on how AS_SEQUENCE can be introduced into AS_PATH, however it doesn't seem to be clear from the document how and when AS_CONFED_SET can and should be added to AS_PATH. Is it described somewhere else or is this provision for further development of the protocol standard? In first case it would be nice to provide reference to a document where such description could be found, and in later case it might be good idea to explicitly state that "introduction and update of segments of type AS_CONFED_SET is not yet defined". Kind regards, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 10 12:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBD5E-0000uC-E3; Thu, 10 Aug 2006 12:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBD5D-0000u7-F4 for idr@ietf.org; Thu, 10 Aug 2006 12:08:31 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBD5B-0000pN-4B for idr@ietf.org; Thu, 10 Aug 2006 12:08:31 -0400 Received: by nf-out-0910.google.com with SMTP id p48so623568nfa for ; Thu, 10 Aug 2006 09:08:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pHylZw0f3RPDCTuJPbmHoCy+rgaqWuMohfsMfO7Y516x4m9dNz+i7U4PJKhtbxRdFnaIDmdGptia/MRlkq6cOH2lWBovj8FyZya7mNy1W6r6OC89VemhZmqB7SUF2uRc7t7R9RnEEhX5V4QZHB5I6hPkUtiH6yIl1E3mN2o0In4= Received: by 10.82.98.13 with SMTP id v13mr287469bub; Thu, 10 Aug 2006 09:08:26 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Thu, 10 Aug 2006 09:08:25 -0700 (PDT) Message-ID: <92c950310608100908x4be6ad31vf99235f7797bf978@mail.gmail.com> Date: Thu, 10 Aug 2006 21:38:26 +0530 From: "Glen Kent" To: "Manav Bhatia" Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I have been following the progress of this draft as the proposal of allowing advertisement of multiple BGP paths interests me and i think its a logical next step that BGP has to take at some point of time in future. The operators may not see a glaring need now but i think the proposal has enough merits to warrant a closer inspection of what all can be achieved with it. I know the draft claims to support multi-protocol BGP but an example or some text elucidating this would be extremely illuminating for most of the readers. Glen. On 8/10/06, Manav Bhatia wrote: > Folks, > > A revised draft of draft-bhatia-bgp-multiple-next-hops-01.txt has been > posted to the internet draft repository. This revision simplifies the > operation, and addresses some of the concerns expressed by IDR working group > participants. The simplification comes primarily from removing a capability > which analysis showed was purely informational. The previous draft amongst > other things allowed for sending advertisements which differed on AS path > but had the same next-hop. In discussions, it was noted that since these > paths had the same next-hop, the receiver would need to combine them anyway. > Therefore, the draft now requires that when sending multiple advertisements > for the same NLRI, these advertisements must use differing next-hops. As a > result of this, the next-hop becomes the distinguishing attribute, along > with the NLRI, for the advertisement. Thus, implicit withdrawls are > supported without needing to introduce additional indexing attributes. > > The proposal is compatible with IPv6 support, MPLS label advertisement, and > BGP multi-protocol support. > > The text for optional support of only ECMP routes, a refinement of sending > all routes with distinct next-hops for an NLRI, and the description of the > constraints on how multiple advertisements are compressed when they are > being used by a BGP speaker, will be folded in as a short portion of the > next revision of this document or a separate draft as deemed fit by the WG. > > http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-01.txt > > Thanks, > Manav > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 05:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBThb-000749-A3; Fri, 11 Aug 2006 05:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBTha-000744-S7 for idr@ietf.org; Fri, 11 Aug 2006 05:53:14 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBThZ-000446-Dy for idr@ietf.org; Fri, 11 Aug 2006 05:53:14 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA26200; Fri, 11 Aug 2006 02:53:12 -0700 (PDT) Received: from manavLpt ([10.128.16.146]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 02:53:11 -0700 Message-ID: <013f01c6bd2b$f3961320$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Glen Kent" References: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> <92c950310608100908x4be6ad31vf99235f7797bf978@mail.gmail.com> Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP Date: Fri, 11 Aug 2006 15:22:54 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 11 Aug 2006 09:53:12.0039 (UTC) FILETIME=[F51FE770:01C6BD2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Glen, Thanks for the comments. Let me illustrate how our proposal would work with mpbgp routes. A and B are two BGP speakers that have negotiated this capability with the RM bit set. This means that A and B are both willing to accept multiple BGP paths, so the other can announce the same. Assume A receives two routes to some destination X (afi=x1, safi=x2) with mpbgp next-hops n1 and n2. It encodes the first route in MP_REACH_NLRI and advertises that route. To advertise the next route the nlri part is encoded in MP_REACH_NLRI and the nexthop is encoded in MULTIPLE_HOP attribute as shown below: MP_REACH_NLRI (as per draft-ietf-idr-rfc2858bis-10.txt) that encodes X: afi = x1 safi = x2 length of next hop address = 0 reserved = 0 nlri = X MULTIPLE_HOP is encoded as: afi = x1 safi = x2 number of nexthops = 1 length of nexthop = length of n2 network address = n2 The receiving BGP speaker B appends this route as it comes with along with the MULTIPLE_HOP path attribute. It thus now has two routes (next-hops n1 and n2) to reach X. Hope this helps. Regards, Manav ----- Original Message ----- From: "Glen Kent" To: "Manav Bhatia" Cc: Sent: Thursday, August 10, 2006 9:38 PM Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP >I have been following the progress of this draft as the proposal of > allowing advertisement of multiple BGP paths interests me and i think > its a logical next step that BGP has to take at some point of time in > future. The operators may not see a glaring need now but i think the > proposal has enough merits to warrant a closer inspection of what all > can be achieved with it. > > I know the draft claims to support multi-protocol BGP but an example > or some text elucidating this would be extremely illuminating for most > of the readers. > > Glen. > > On 8/10/06, Manav Bhatia wrote: >> Folks, >> >> A revised draft of draft-bhatia-bgp-multiple-next-hops-01.txt has been >> posted to the internet draft repository. This revision simplifies the >> operation, and addresses some of the concerns expressed by IDR working >> group >> participants. The simplification comes primarily from removing a >> capability >> which analysis showed was purely informational. The previous draft >> amongst >> other things allowed for sending advertisements which differed on AS path >> but had the same next-hop. In discussions, it was noted that since these >> paths had the same next-hop, the receiver would need to combine them >> anyway. >> Therefore, the draft now requires that when sending multiple >> advertisements >> for the same NLRI, these advertisements must use differing next-hops. As >> a >> result of this, the next-hop becomes the distinguishing attribute, along >> with the NLRI, for the advertisement. Thus, implicit withdrawls are >> supported without needing to introduce additional indexing attributes. >> >> The proposal is compatible with IPv6 support, MPLS label advertisement, >> and >> BGP multi-protocol support. >> >> The text for optional support of only ECMP routes, a refinement of >> sending >> all routes with distinct next-hops for an NLRI, and the description of >> the >> constraints on how multiple advertisements are compressed when they are >> being used by a BGP speaker, will be folded in as a short portion of the >> next revision of this document or a separate draft as deemed fit by the >> WG. >> >> http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-01.txt >> >> Thanks, >> Manav >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr >> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 13:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaSw-0000dg-Mh; Fri, 11 Aug 2006 13:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaSv-0000dZ-LQ for idr@ietf.org; Fri, 11 Aug 2006 13:06:33 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBaSt-00048G-AL for idr@ietf.org; Fri, 11 Aug 2006 13:06:33 -0400 Received: by nf-out-0910.google.com with SMTP id p48so1048675nfa for ; Fri, 11 Aug 2006 10:06:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uMVZCXdY6OgZQDVcD1kdM+XwiBvVYqHN1e80PkDKsfKIhDu/dNtvPoj/LJwaWUrKe1zV1MuRRbFqU3ho1++/Oa9w/rsosOOM6brftifsE0WYyXS06L7+VUSI5Ww6J/KxuJSU1KXAh0I0VRB7AQO8I5DUt5FQFObA91XVaMPAxkg= Received: by 10.82.112.3 with SMTP id k3mr387141buc; Fri, 11 Aug 2006 10:06:30 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Fri, 11 Aug 2006 10:06:30 -0700 (PDT) Message-ID: <92c950310608111006s1ff48154kf9daab0102f0aa81@mail.gmail.com> Date: Fri, 11 Aug 2006 22:36:30 +0530 From: "Glen Kent" To: "Manav Bhatia" Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: <013f01c6bd2b$f3961320$0201a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> <92c950310608100908x4be6ad31vf99235f7797bf978@mail.gmail.com> <013f01c6bd2b$f3961320$0201a8c0@rs.riverstonenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Manav, > MP_REACH_NLRI (as per draft-ietf-idr-rfc2858bis-10.txt) that encodes X: > > afi = x1 > safi = x2 > length of next hop address = 0 > reserved = 0 > nlri = X > > MULTIPLE_HOP is encoded as: > > afi = x1 > safi = x2 > number of nexthops = 1 > length of nexthop = length of n2 > network address = n2 All right, this would work. Thanks for the explanation. Looking at this in another light leads me to think that its now kinda possible to disassociate the AFI-SAFI (or simply the network layer protocol) of the next-hop with that of the NLRI in a more elegant and a scalable way. I have in the past expressed my displeasure at how we pad NULL RDs in 2547 when filling the next-hop information in the mp-reach-nlri path attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a reason why we need to restrict the network layer address family of the next-hop to be the same as that of the NLRI. I call it a kludge because we may land up with some applications where the address of nexthop may not align with the format of the NLRI information by mere padding. I don't know if the authors of this draft had this in mind, but a side effect of this mechanism is that we can now disassociate the two entities. And i find this useful in addition to what it already achieves. Glen > > The receiving BGP speaker B appends this route as it comes with along with > the MULTIPLE_HOP path attribute. It thus now has two routes (next-hops n1 > and n2) to reach X. > > Hope this helps. > > Regards, > Manav > > ----- Original Message ----- > From: "Glen Kent" > To: "Manav Bhatia" > Cc: > Sent: Thursday, August 10, 2006 9:38 PM > Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP > > > >I have been following the progress of this draft as the proposal of > > allowing advertisement of multiple BGP paths interests me and i think > > its a logical next step that BGP has to take at some point of time in > > future. The operators may not see a glaring need now but i think the > > proposal has enough merits to warrant a closer inspection of what all > > can be achieved with it. > > > > I know the draft claims to support multi-protocol BGP but an example > > or some text elucidating this would be extremely illuminating for most > > of the readers. > > > > Glen. > > > > On 8/10/06, Manav Bhatia wrote: > >> Folks, > >> > >> A revised draft of draft-bhatia-bgp-multiple-next-hops-01.txt has been _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 13:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaeW-0004Wz-4P; Fri, 11 Aug 2006 13:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBaeV-0004Wi-Ai; Fri, 11 Aug 2006 13:18:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBaeU-00052D-3u; Fri, 11 Aug 2006 13:18:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 13:18:30 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96268190:sNHT29705948" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BHIT5U028648; Fri, 11 Aug 2006 13:18:29 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7BHIQdq018458; Fri, 11 Aug 2006 13:18:28 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7000E71D8C525042A815432358B2F1240BF27D@paul.adoffice.local.de.easynet.net > References: <7000E71D8C525042A815432358B2F1240BF27D@paul.adoffice.local.de.easynet.net > Date: Fri, 11 Aug 2006 13:18:21 -0400 To: "Ilya Varlashkin" From: "John G. Scudder" Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1224; t=1155316709; x=1156180709; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:RE=3A=20[Idr]=20Last=20Call=3A=20'Autonomous=20System=20Confederations=2 0for=20BGP'=0A=20to=20=09Draft=20Standard=20(draft-ietf-idr-rfc3065bis) |To:=22Ilya=20Varlashkin=22=20; X=v=3Dcisco.com=3B=20h=3D6GrXqnGfFJuOqm8Zm+4q6iT2Jag=3D; b=im794U9fEHm0Os3yHHjxQTS9r6ftQ81kjfPz5KuYliXiYMJjUlFE0pwlECMrgGTPafpXkcmY lHn5ri8C72MW+1HtSrqMDpzOaWMybUhH50d9hozT8LnI2e/JQyg3G60o; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Ilya, Thanks for pointing this out. Since (as far as I know) nobody has an implementation which actually generates AS_CONFED_SETs nor does such seem likely, we're thinking that we should clarify the document by deprecating AS_CONFED_SET. Comments from the group? Anyone aware of any reason not to do this? --John At 1:33 PM +0200 8/10/06, Ilya Varlashkin wrote: >Hello, ... >I've just went through the document and have one question. The draft >specifies new segment types AS_CONFED_SEQUENCE and AS_CONFED_SET, and >specifies how to handle AS_PATH containing such segment in received >UPDATEs. There is also good amount of information on how AS_SEQUENCE can >be introduced into AS_PATH, however it doesn't seem to be clear from the >document how and when AS_CONFED_SET can and should be added to AS_PATH. >Is it described somewhere else or is this provision for further >development of the protocol standard? In first case it would be nice to >provide reference to a document where such description could be found, >and in later case it might be good idea to explicitly state that >"introduction and update of segments of type AS_CONFED_SET is not yet >defined". > >Kind regards, >iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 13:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBasg-0007aL-OK; Fri, 11 Aug 2006 13:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBasg-0007aD-6L; Fri, 11 Aug 2006 13:33:10 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBasc-0006vQ-W4; Fri, 11 Aug 2006 13:33:10 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 7ED174E804; Fri, 11 Aug 2006 13:33:06 -0400 (EDT) Date: Fri, 11 Aug 2006 13:33:06 -0400 From: Jeffrey Haas To: "John G. Scudder" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Message-ID: <20060811173306.GH13201@scc.mi.org> References: <7000E71D8C525042A815432358B2F1240BF27D@paul.adoffice.local.de.easynet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, Aug 11, 2006 at 01:18:21PM -0400, John G. Scudder wrote: > Thanks for pointing this out. Since (as far as I know) nobody has an > implementation which actually generates AS_CONFED_SETs That statement would be incorrect. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 13:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBb2i-0005py-3W; Fri, 11 Aug 2006 13:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBb2g-0005pt-8I for idr@ietf.org; Fri, 11 Aug 2006 13:43:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBb2g-0007tO-69 for idr@ietf.org; Fri, 11 Aug 2006 13:43:30 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBb2e-00024R-5x for idr@ietf.org; Fri, 11 Aug 2006 13:43:29 -0400 Received: by nf-out-0910.google.com with SMTP id p48so1059221nfa for ; Fri, 11 Aug 2006 10:43:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bXFqP/RmuM5mYxBO9x4oe6Vq+ThYFuS2i19ohhe43BRlPvXPePmy81xZw1mwuyGvknuh0wVSk6Np5bq+rSW0XqZrmXNuguZ01VHSmffDaTyRJm5rr1ugL1qO4vMm+N5y1z+qswXVAflqgyccmJ89+UsFAfJL+E65MohWForRxmM= Received: by 10.82.123.10 with SMTP id v10mr388221buc; Fri, 11 Aug 2006 10:43:24 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Fri, 11 Aug 2006 10:43:24 -0700 (PDT) Message-ID: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> Date: Fri, 11 Aug 2006 23:13:24 +0530 From: "Glen Kent" To: "John G. Scudder" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: -2.5 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John, > Thanks for pointing this out. Since (as far as I know) nobody has an > implementation which actually generates AS_CONFED_SETs nor does such I am sure there are atleast two implementations that generate CONFED_SETs, so the above statement is not really true. > seem likely, we're thinking that we should clarify the document by > deprecating AS_CONFED_SET. > > Comments from the group? Anyone aware of any reason not to do this? You cant deprecate this. How do you otherwise catch loops when you aggregate the routes within a confederation? Whats needed is some new text in the draft that describes how this path segment should be created. Glen. > > --John > > At 1:33 PM +0200 8/10/06, Ilya Varlashkin wrote: > >Hello, > ... > >I've just went through the document and have one question. The draft > >specifies new segment types AS_CONFED_SEQUENCE and AS_CONFED_SET, and > >specifies how to handle AS_PATH containing such segment in received > >UPDATEs. There is also good amount of information on how AS_SEQUENCE can > >be introduced into AS_PATH, however it doesn't seem to be clear from the > >document how and when AS_CONFED_SET can and should be added to AS_PATH. > >Is it described somewhere else or is this provision for further > >development of the protocol standard? In first case it would be nice to > >provide reference to a document where such description could be found, > >and in later case it might be good idea to explicitly state that > >"introduction and update of segments of type AS_CONFED_SET is not yet > >defined". > > > >Kind regards, > >iLya > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:07:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbPs-0003mL-2C; Fri, 11 Aug 2006 14:07:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbPr-0003mD-4Q; Fri, 11 Aug 2006 14:07:27 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbPp-00026d-SJ; Fri, 11 Aug 2006 14:07:27 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 8791D4E7F3; Fri, 11 Aug 2006 14:07:23 -0400 (EDT) Date: Fri, 11 Aug 2006 14:07:23 -0400 From: Jeffrey Haas To: Glen Kent Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Message-ID: <20060811180723.GK13201@scc.mi.org> References: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, Aug 11, 2006 at 11:13:24PM +0530, Glen Kent wrote: > Whats needed is some new text in the draft that describes how this > path segment should be created. It's been a while since I've done a semantic review of the update. In a previous pass of it, we removed a lot of the modification rules. For appending the confederation set/sequence, the behavior is expected to be identical to that of the base BGP RFC, but with a different type. One solution is to update 3065bis to be "correct" with respect to sequences and sets. Now that the base BGP specification is stable, we can probably do that. This is a "messy" operation because of the sheer number of places sets are used and would need to be copy/updated into the confederation spec. Another solution is to simply note existing base BGP behavior and point to the places where you add AS_CONFED_[SEQUENCE|SET] in place of their AS_[SEQUENCE|SET] components. I'm fine with either option. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbVX-0005z1-9F; Fri, 11 Aug 2006 14:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbVW-0005wP-2t for idr@ietf.org; Fri, 11 Aug 2006 14:13:18 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbVU-0002Or-Np for idr@ietf.org; Fri, 11 Aug 2006 14:13:18 -0400 Received: by nf-out-0910.google.com with SMTP id p48so1067486nfa for ; Fri, 11 Aug 2006 11:13:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TunU8oPHMa9UMGIvKdQtGUMheGbkBK5MCtsotDs7ntkeV8RZT/2UhTsz1kE8dwo9Urtqaz61t5hrCYW6cwHUGJUybm0XJSZgGR9wUEYYzVAuiLX9bwp74E51Ip2EsYf/8HttptiIqzrsUKT7M0ThfGkEnc4FoLtqZmegxC1CSkQ= Received: by 10.82.123.16 with SMTP id v16mr395928buc; Fri, 11 Aug 2006 11:13:15 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Fri, 11 Aug 2006 11:13:15 -0700 (PDT) Message-ID: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> Date: Fri, 11 Aug 2006 23:43:15 +0530 From: "Glen Kent" To: "Jeffrey Haas" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) In-Reply-To: <20060811180723.GK13201@scc.mi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> <20060811180723.GK13201@scc.mi.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Would the following text work? When a BGP confederation speaker aggregates several routes for the purpose of advertisement to a particular confederation peer, the AS_PATH of the aggregated route normally includes an AS_CONFED_SET formed from the set of ASes from which the aggregate was formed. Glen On 8/11/06, Jeffrey Haas wrote: > On Fri, Aug 11, 2006 at 11:13:24PM +0530, Glen Kent wrote: > > Whats needed is some new text in the draft that describes how this > > path segment should be created. > > It's been a while since I've done a semantic review of the update. > In a previous pass of it, we removed a lot of the modification rules. > For appending the confederation set/sequence, the behavior is > expected to be identical to that of the base BGP RFC, but with > a different type. > > One solution is to update 3065bis to be "correct" with respect > to sequences and sets. Now that the base BGP specification is > stable, we can probably do that. This is a "messy" operation > because of the sheer number of places sets are used and would > need to be copy/updated into the confederation spec. > > Another solution is to simply note existing base BGP behavior > and point to the places where you add AS_CONFED_[SEQUENCE|SET] > in place of their AS_[SEQUENCE|SET] components. > > I'm fine with either option. > > -- Jeff > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbYN-0001e9-E0; Fri, 11 Aug 2006 14:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbYM-0001e1-2a; Fri, 11 Aug 2006 14:16:14 -0400 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbYK-00030Y-O2; Fri, 11 Aug 2006 14:16:14 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id B545230DB; Fri, 11 Aug 2006 18:16:10 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27X) with ESMTP id 595kHksqH0151Mo2; Fri, 11 Aug 2006 18:16:09 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27X) with ESMTP id 591kHksqg0151Mo2; Fri, 11 Aug 2006 18:16:06 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27X); Fri, 11 Aug 2006 18:16:06 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID198kHksqg8931Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 12:16:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Date: Fri, 11 Aug 2006 12:16:03 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0206515878@VS4.EXCHPROD.USA.NET> In-Reply-To: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Thread-Index: Aca9cduclxrD8IMrSfetkPaRzo6wpAAAEW5A From: "Susan Hares" To: "Glen Kent" , "Jeffrey Haas" X-OriginalArrivalTime: 11 Aug 2006 18:16:05.0866 (UTC) FILETIME=[362084A0:01C6BD72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Glenn: Suggest where you'd like it to be put in the text for context. sue -----Original Message----- From: Glen Kent [mailto:glen.kent@gmail.com]=20 Sent: Friday, August 11, 2006 2:13 PM To: Jeffrey Haas Cc: John G. Scudder; iesg@ietf.org; idr@ietf.org Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Would the following text work? When a BGP confederation speaker aggregates several routes for the purpose of advertisement to a particular confederation peer, the AS_PATH of the aggregated route normally includes an AS_CONFED_SET formed from the set of ASes from which the aggregate was formed. Glen On 8/11/06, Jeffrey Haas wrote: > On Fri, Aug 11, 2006 at 11:13:24PM +0530, Glen Kent wrote: > > Whats needed is some new text in the draft that describes how this > > path segment should be created. > > It's been a while since I've done a semantic review of the update. > In a previous pass of it, we removed a lot of the modification rules. > For appending the confederation set/sequence, the behavior is > expected to be identical to that of the base BGP RFC, but with > a different type. > > One solution is to update 3065bis to be "correct" with respect > to sequences and sets. Now that the base BGP specification is > stable, we can probably do that. This is a "messy" operation > because of the sheer number of places sets are used and would > need to be copy/updated into the confederation spec. > > Another solution is to simply note existing base BGP behavior > and point to the places where you add AS_CONFED_[SEQUENCE|SET] > in place of their AS_[SEQUENCE|SET] components. > > I'm fine with either option. > > -- Jeff > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbhH-0000sG-G0; Fri, 11 Aug 2006 14:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbhF-0000s1-MQ for idr@ietf.org; Fri, 11 Aug 2006 14:25:25 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbhE-0003L0-Ah for idr@ietf.org; Fri, 11 Aug 2006 14:25:25 -0400 Received: by nf-out-0910.google.com with SMTP id p48so1070921nfa for ; Fri, 11 Aug 2006 11:25:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fSI+aes84F40mLPbr5iJIEMXW/XQGWXVmCZJ+BHA/oMOpI/TYYbpxsYYdUPmm9DVg4XUTQMDXr30fei7+6Ip95F8vXDb+Bmg+0/Sny3CvAwY+cR3Jr8GoHH67WtrWangYOV1O0NrKMeLlDQd5tDejIqRcIca/Bp4On/5vX3ffIU= Received: by 10.82.127.15 with SMTP id z15mr394236buc; Fri, 11 Aug 2006 11:25:23 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Fri, 11 Aug 2006 11:25:23 -0700 (PDT) Message-ID: <92c950310608111125x16cc6725o84de55707490da3b@mail.gmail.com> Date: Fri, 11 Aug 2006 23:55:23 +0530 From: "Glen Kent" To: "Susan Hares" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F0206515878@VS4.EXCHPROD.USA.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> <6F44D7F6B24A8F4DA0AB46C9BE924F0206515878@VS4.EXCHPROD.USA.NET> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Sue, Sec 4.1 under the text for "When a BGP speaker originates a route:" Aggregating the route is like originating a route and i think its a proper place to put the suggested text. I have slightly modified the text as: d) the originating speaker that aggregates several routes for the purpose of advertisement to a particular confederation peer SHALL include an AS_CONFED_SET segment of the AS_PATH attribute formed from the set of ASes from which the aggregate was formed. Glen On 8/11/06, Susan Hares wrote: > Glenn: > > Suggest where you'd like it to be put in the text for context. > > sue > > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com] > Sent: Friday, August 11, 2006 2:13 PM > To: Jeffrey Haas > Cc: John G. Scudder; iesg@ietf.org; idr@ietf.org > Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' > toDraft Standard (draft-ietf-idr-rfc3065bis) > > Would the following text work? > > When a BGP confederation speaker aggregates several routes for the > purpose of advertisement to a particular confederation peer, the > AS_PATH of the aggregated route normally includes an AS_CONFED_SET > formed from the set of ASes from which the aggregate was formed. > > Glen > > On 8/11/06, Jeffrey Haas wrote: > > On Fri, Aug 11, 2006 at 11:13:24PM +0530, Glen Kent wrote: > > > Whats needed is some new text in the draft that describes how this > > > path segment should be created. > > > > It's been a while since I've done a semantic review of the update. > > In a previous pass of it, we removed a lot of the modification rules. > > For appending the confederation set/sequence, the behavior is > > expected to be identical to that of the base BGP RFC, but with > > a different type. > > > > One solution is to update 3065bis to be "correct" with respect > > to sequences and sets. Now that the base BGP specification is > > stable, we can probably do that. This is a "messy" operation > > because of the sheer number of places sets are used and would > > need to be copy/updated into the confederation spec. > > > > Another solution is to simply note existing base BGP behavior > > and point to the places where you add AS_CONFED_[SEQUENCE|SET] > > in place of their AS_[SEQUENCE|SET] components. > > > > I'm fine with either option. > > > > -- Jeff > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbkE-0003kw-Ux; Fri, 11 Aug 2006 14:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbkD-0003ko-5q; Fri, 11 Aug 2006 14:28:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbkB-0003Zi-VX; Fri, 11 Aug 2006 14:28:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 14:28:28 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96279607:sNHT28695872" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BISRQB029044; Fri, 11 Aug 2006 14:28:27 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7BISQdq008496; Fri, 11 Aug 2006 14:28:27 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> References: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> Date: Fri, 11 Aug 2006 14:28:13 -0400 To: "Glen Kent" From: "John G. Scudder" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=425; t=1155320907; x=1156184907; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Last=20Call=3A=20'Autonomous=20System=20Confederations=2 0for=20BGP'=0A=20to=20=09Draft=20Standard=20(draft-ietf-idr-rfc3065bis) |To:=22Glen=20Kent=22=20; X=v=3Dcisco.com=3B=20h=3DwltDrwTHGcg4NXB4OrTFCRBrNMk=3D; b=b4CGmxsYIE3k/5iaX+2DcEe9Pr2gnMPls34Zd9SYF1SLqSeaJy1zTsUMk3gaqWMo6/bTGQMB IY/rRLrhAg8eNedcrmPCMmTaIg/ccFMJo+aGjBfQBB4oaIqhD5oj674g; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 11:13 PM +0530 8/11/06, Glen Kent wrote: >You cant deprecate this. How do you otherwise catch loops when you >aggregate the routes within a confederation? By the way, this is a common fallacy. As long as you aggregate (i.e., form a shorter prefix) whenever you trim the AS path, and as long as no de-aggregation occurs, any loop will eventually be broken. That's what ATOMIC_AGGREGATE is all about. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc0r-000862-UZ; Fri, 11 Aug 2006 14:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc0q-00084Y-8c for idr@ietf.org; Fri, 11 Aug 2006 14:45:40 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbqf-0004QZ-V7 for idr@ietf.org; Fri, 11 Aug 2006 14:35:13 -0400 Received: by nf-out-0910.google.com with SMTP id p48so1073642nfa for ; Fri, 11 Aug 2006 11:35:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q5B6Jva4V70p+ikPHhZni100BPgSMYXMx6CxgCnikuMs2WvlyjUan/ZVBLf1Cy7Vsfqnms5U1ItGleRZMX7XyamDE7rOel8w9s6vztnagNH8H9ufm+XsrPkzFohFsXlGnJincIne5NeOzyjK/74DtMM/M7AZq2sLiKTzE3rhQ8k= Received: by 10.82.102.5 with SMTP id z5mr397802bub; Fri, 11 Aug 2006 11:35:08 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Fri, 11 Aug 2006 11:35:08 -0700 (PDT) Message-ID: <92c950310608111135i497d14c2jd49ea9997a3c4040@mail.gmail.com> Date: Sat, 12 Aug 2006 00:05:08 +0530 From: "Glen Kent" To: "John G. Scudder" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John, When you trim the AS path you lose the AS_SET and thats where you use the ATOMIC_AGGREGATE. If thats the case then we need to deprecate AS_SET too. Are you suggesting that the SETs have no utility at all? > By the way, this is a common fallacy. As long as you aggregate > (i.e., form a shorter prefix) whenever you trim the AS path, and as > long as no de-aggregation occurs, any loop will eventually be broken. > That's what ATOMIC_AGGREGATE is all about. > > --John > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc1D-0008Mh-AR; Fri, 11 Aug 2006 14:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc1B-0008Jn-3q for idr@ietf.org; Fri, 11 Aug 2006 14:46:01 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbnW-0004Ah-Fw for idr@ietf.org; Fri, 11 Aug 2006 14:31:55 -0400 Received: by nf-out-0910.google.com with SMTP id p48so1072710nfa for ; Fri, 11 Aug 2006 11:31:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jK8tjZJdEYWyxSy+KkqBCQYxd9BMiyIwrRGzl1ZUpPnYf0ckj+STBOf2hskDluyWPBbistWGeKROo/uhJ3uj4Rg5iiRViKdECp6ZqvINFE7TT0yiO4IVmAuXCcoD8I7J/E9tyERbqu5iEjHjzPAMRb2UrhLsfKE+C8C4Ypj9Om8= Received: by 10.82.103.11 with SMTP id a11mr396307buc; Fri, 11 Aug 2006 11:31:53 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Fri, 11 Aug 2006 11:31:53 -0700 (PDT) Message-ID: <92c950310608111131m54b85a38h1ccc8196c3327ac8@mail.gmail.com> Date: Sat, 12 Aug 2006 00:01:53 +0530 From: "Glen Kent" To: "Ilya Varlashkin" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) In-Reply-To: <7000E71D8C525042A815432358B2F1240BF2D0@paul.adoffice.local.de.easynet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> <7000E71D8C525042A815432358B2F1240BF2D0@paul.adoffice.local.de.easynet.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org llya, > Wouldn't this leave backdoor for misinterpretation that foreign (to > given AS) prefixes can also be aggregated this way? This is obviously Then the text needs to be modified to say that only the routes learnt from confederation peers should be aggregated. But is this correct? Is this even a requirement? Glen. > dangerous since when such aggregate propagated outside of the AS and > AS_CONFED_SET removed (as per this draft), then information is lost. > > /iLya > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:46:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc20-0000H9-6a; Fri, 11 Aug 2006 14:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc1z-0000Gx-L3; Fri, 11 Aug 2006 14:46:51 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBc1y-00063C-BW; Fri, 11 Aug 2006 14:46:51 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1GBc1w-0005Co-TP; Fri, 11 Aug 2006 20:46:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Date: Fri, 11 Aug 2006 20:46:48 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240BF2D1@paul.adoffice.local.de.easynet.net> In-Reply-To: <92c950310608111131m54b85a38h1ccc8196c3327ac8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Thread-Index: Aca9dGxw/FdvhwHsRLK+HlJ8xxfI9AAANShA From: "Ilya Varlashkin" To: "Glen Kent" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com]=20 > Sent: Friday, August 11, 2006 8:32 PM > To: Ilya Varlashkin > Cc: John G. Scudder; iesg@ietf.org; idr@ietf.org; Jeffrey Haas > Subject: Re: [Idr] Last Call: 'Autonomous System=20 > Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) >=20 > llya, >=20 > > Wouldn't this leave backdoor for misinterpretation that foreign (to=20 > > given AS) prefixes can also be aggregated this way? This is=20 > obviously >=20 > Then the text needs to be modified to say that only the=20 > routes learnt from confederation peers should be aggregated.=20 > But is this correct? Is this even a requirement? >=20 The first way (AS_CONFED_SET is only for AS internal routes) seems to be easiest, but I don't know if those implementations that already use AS_CONFED_SET would be compliant with such requirement. If we assume that it's ok to aggregate even AS external routes, then according to section 9.1.4 of RFC4271 (page 84, second paragraph from the top): "... If a BGP speaker chooses to aggregate, then it SHOULD either include all ASes used to form the aggregate in an AS_SET, or add the ATOMIC_AGGREGATE attribute to the route. ..." The draft calls for simply removing AS_CONFED_SET. Would it automatically mean (per RFC4271) that such implementation will either translate AS_CONFED_SET to AS_SET (this operation is not defined neither in draft nor in RFC4271) or will it set ATOMIC_AGGREGATE? /iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 14:46:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc26-0000b8-Mu; Fri, 11 Aug 2006 14:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBc25-0000Yk-Co; Fri, 11 Aug 2006 14:46:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBc24-00063O-6f; Fri, 11 Aug 2006 14:46:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2006 14:46:56 -0400 X-IronPort-AV: i="4.08,115,1154923200"; d="scan'208"; a="96283004:sNHT29331116" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BIkuve005979; Fri, 11 Aug 2006 14:46:56 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7BIktdq013929; Fri, 11 Aug 2006 14:46:55 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <92c950310608111135i497d14c2jd49ea9997a3c4040@mail.gmail.com> References: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> <92c950310608111135i497d14c2jd49ea9997a3c4040@mail.gmail.com> Date: Fri, 11 Aug 2006 14:42:13 -0400 To: "Glen Kent" From: "John G. Scudder" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=584; t=1155322016; x=1156186016; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Last=20Call=3A=20'Autonomous=20System=20Confederations=2 0for=20BGP'=0A=20to=20Draft=20Standard=20(draft-ietf-idr-rfc3065bis) |To:=22Glen=20Kent=22=20; X=v=3Dcisco.com=3B=20h=3DwltDrwTHGcg4NXB4OrTFCRBrNMk=3D; b=HkdTAgZeRftgQQODDAIY1443iTOlZlTN06XzKumYmPiRmq17QDWV7TEELSHyJp2GkVM/CBX3 i2jmOFRMQiY1Y860CL/wZAqLdyAUeKHBWyFhXDxUZGaaSYfLawOa4OW+; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 12:05 AM +0530 8/12/06, Glen Kent wrote: >When you trim the AS path you lose the AS_SET and thats where you use >the ATOMIC_AGGREGATE. That's one case when you use it, yes. Technically, you use it any time any of the AS numbers in any constituent route isn't included in an aggregate. >If thats the case then we need to deprecate >AS_SET too. I don't follow you. >Are you suggesting that the SETs have no utility at all? No, I'm not suggesting that. I should have added the disclaimer that my point was tangential to the original conversation. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 15:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcoJ-0003a1-JM; Fri, 11 Aug 2006 15:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcoH-0003Zt-SK; Fri, 11 Aug 2006 15:36:45 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBcoG-00018i-LT; Fri, 11 Aug 2006 15:36:45 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 3D8034E517; Fri, 11 Aug 2006 15:36:42 -0400 (EDT) Date: Fri, 11 Aug 2006 15:36:42 -0400 From: Jeffrey Haas To: Glen Kent Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Message-ID: <20060811193642.GN13201@scc.mi.org> References: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> <7000E71D8C525042A815432358B2F1240BF2D0@paul.adoffice.local.de.easynet.net> <92c950310608111131m54b85a38h1ccc8196c3327ac8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92c950310608111131m54b85a38h1ccc8196c3327ac8@mail.gmail.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Sat, Aug 12, 2006 at 12:01:53AM +0530, Glen Kent wrote: > Then the text needs to be modified to say that only the routes learnt > from confederation peers should be aggregated. But is this correct? Is > this even a requirement? Consider AS_PATH-A and AS_PATH-B If some AS aggregates AS_PATH-A and AS_PATH-B, we will have a new AS_PATH, AS_PATH-C which will include that AS as the leading AS. Components of -A and -B will be aggregated per the RFC 4271 aggregation rules. If this AS is running confederations, logically aggregation of these two paths within the confederation must, on out-of-confederation advertisement, result in -C. (Or, -C must be able to result from normal aggregation.) Aggregation-wise, this can be done by aggregating the non-confederation and the confederation components separately. This is done using the same rules for sets and sequences, but applying them to only the same types; i.e.confeds with confeds, non-confeds with non-confeds. I'll take a stab at wordsmithing something about this using the base spec as the reference. I'll try to finish this in the next couple of days. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 16:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBe5x-0005IM-AF; Fri, 11 Aug 2006 16:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBe5w-0005Dt-8d; Fri, 11 Aug 2006 16:59:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBblU-0003hG-3M; Fri, 11 Aug 2006 14:29:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBbdU-0002gr-Cd; Fri, 11 Aug 2006 14:21:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2006 11:21:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,115,1154934000"; d="scan'208"; a="35732938:sNHT22969652" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BILVYF028978; Fri, 11 Aug 2006 14:21:31 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id k7BILTe3005741; Fri, 11 Aug 2006 14:21:30 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> References: <92c950310608111043o69596f78va6505b0dac25d55d@mail.gmail.com> <20060811180723.GK13201@scc.mi.org> <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> Date: Fri, 11 Aug 2006 14:21:06 -0400 To: "Glen Kent" From: "John G. Scudder" Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1748; t=1155320491; x=1156184491; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Last=20Call=3A=20'Autonomous=20System=20Confederations=2 0for=20BGP'=0A=20to=20Draft=20Standard=20(draft-ietf-idr-rfc3065bis) |To:=22Glen=20Kent=22=20; X=v=3Dcisco.com=3B=20h=3DwltDrwTHGcg4NXB4OrTFCRBrNMk=3D; b=EVuEaLgHycgu2YLkzqgM5CRtmTSpHGhQ4Vv89t3jCb0OgBq32NPrQWC16/oYVeZTZc84Ku7U zUIGYSJmqaEhWUooJTwi7Ohl+N/iboUTu15jNV+/1VGPf81zyqd1gxSy; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.3 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org No, I think if we wanted to fully spec how to build an AS_CONFED_SET we'd have to do it much more completely than that -- which is why I like Jeff's suggestion that we simply point to the base spec. That way we can write fewer words and keep the window for error much smaller. --John At 11:43 PM +0530 8/11/06, Glen Kent wrote: >Would the following text work? > >When a BGP confederation speaker aggregates several routes for the >purpose of advertisement to a particular confederation peer, the >AS_PATH of the aggregated route normally includes an AS_CONFED_SET >formed from the set of ASes from which the aggregate was formed. > >Glen > >On 8/11/06, Jeffrey Haas wrote: >>On Fri, Aug 11, 2006 at 11:13:24PM +0530, Glen Kent wrote: >>> Whats needed is some new text in the draft that describes how this >>> path segment should be created. >> >>It's been a while since I've done a semantic review of the update. >>In a previous pass of it, we removed a lot of the modification rules. >>For appending the confederation set/sequence, the behavior is >>expected to be identical to that of the base BGP RFC, but with >>a different type. >> >>One solution is to update 3065bis to be "correct" with respect >>to sequences and sets. Now that the base BGP specification is >>stable, we can probably do that. This is a "messy" operation >>because of the sheer number of places sets are used and would >>need to be copy/updated into the confederation spec. >> >>Another solution is to simply note existing base BGP behavior >>and point to the places where you add AS_CONFED_[SEQUENCE|SET] >>in place of their AS_[SEQUENCE|SET] components. >> >>I'm fine with either option. >> >>-- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 20:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBgz3-0007xA-5c; Fri, 11 Aug 2006 20:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBgz1-0007x2-S8; Fri, 11 Aug 2006 20:04:07 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBgz0-0006rK-Md; Fri, 11 Aug 2006 20:04:07 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 6CCB184DE; Fri, 11 Aug 2006 20:04:06 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k7C046dK017262; Fri, 11 Aug 2006 17:04:06 -0700 From: Bill Fenner Message-Id: <200608120004.k7C046dK017262@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Brian Carpenter References: <44DCA14C.5030304@zurich.ibm.com> Date: Fri, 11 Aug 2006 17:04:06 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: idr@ietf.org, IESG Subject: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >But it is v6ops, not idr, that has the overview of >IPv4/IPv6 coexistence solutions. Brian, In 2004, the v6ops WG had consensus to go forward with this solution, and asked idr to progress with it because v6ops didn't have the BGP expertise. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 20:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBh4Q-0001Oq-Nw; Fri, 11 Aug 2006 20:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBh4P-0001NV-JI; Fri, 11 Aug 2006 20:09:41 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBh4O-00070q-Dj; Fri, 11 Aug 2006 20:09:41 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 42CBD8147; Fri, 11 Aug 2006 20:09:40 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k7C09eoZ017428; Fri, 11 Aug 2006 17:09:40 -0700 From: Bill Fenner Message-Id: <200608120009.k7C09eoZ017428@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: "John G. Scudder" Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) References: <7000E71D8C525042A815432358B2F1240BF27D@paul.adoffice.local.de.easynet.net > Date: Fri, 11 Aug 2006 17:09:40 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.6 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >(as far as I know) nobody has an >implementation which actually generates AS_CONFED_SETs nor does such >seem likely, we're thinking that we should clarify the document by >deprecating AS_CONFED_SET. Oops! In fact, when advancing to Draft Standard, that's exactly what's required - if nobody's implemented something, it *has* to get dropped from the spec. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 11 21:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBicm-00075k-V3; Fri, 11 Aug 2006 21:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBicm-00075E-84; Fri, 11 Aug 2006 21:49:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBblT-0003hG-TP; Fri, 11 Aug 2006 14:29:47 -0400 Received: from softy.ision.net ([194.163.250.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GBbdY-0002gl-Aq; Fri, 11 Aug 2006 14:21:39 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1GBbdH-0004WB-0h; Fri, 11 Aug 2006 20:21:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Date: Fri, 11 Aug 2006 20:21:18 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240BF2D0@paul.adoffice.local.de.easynet.net> In-Reply-To: <92c950310608111113n2ff17f69o9016a34a13c789f0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Last Call: 'Autonomous System Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) Thread-Index: Aca9cddMJ6h9pqf4TcCyVLzvEP1Z1QAALISQ From: "Ilya Varlashkin" To: "Glen Kent" X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com]=20 > Sent: Friday, August 11, 2006 8:13 PM > To: Jeffrey Haas > Cc: John G. Scudder; iesg@ietf.org; idr@ietf.org > Subject: Re: [Idr] Last Call: 'Autonomous System=20 > Confederations for BGP' toDraft Standard (draft-ietf-idr-rfc3065bis) >=20 > Would the following text work? >=20 > When a BGP confederation speaker aggregates several routes=20 > for the purpose of advertisement to a particular=20 > confederation peer, the AS_PATH of the aggregated route=20 > normally includes an AS_CONFED_SET formed from the set of=20 > ASes from which the aggregate was formed. >=20 Glen, Wouldn't this leave backdoor for misinterpretation that foreign (to given AS) prefixes can also be aggregated this way? This is obviously dangerous since when such aggregate propagated outside of the AS and AS_CONFED_SET removed (as per this draft), then information is lost. /iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 13 02:10:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC9AZ-0008WJ-JQ; Sun, 13 Aug 2006 02:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GC9AX-0008Vr-JD; Sun, 13 Aug 2006 02:09:53 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GC9A5-0008W3-9n; Sun, 13 Aug 2006 02:09:26 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id XAA15290; Sat, 12 Aug 2006 23:09:16 -0700 (PDT) Received: from manavLpt ([10.128.16.149]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 12 Aug 2006 23:09:15 -0700 Message-ID: <004101c6be9f$0179e100$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Ilya Varlashkin" References: <7000E71D8C525042A815432358B2F1240BF2D1@paul.adoffice.local.de.easynet.net> Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP'toDraft Standard (draft-ietf-idr-rfc3065bis) Date: Sun, 13 Aug 2006 11:39:11 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 13 Aug 2006 06:09:16.0272 (UTC) FILETIME=[019C0F00:01C6BE9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi iLya, > The draft calls for simply removing AS_CONFED_SET. Would it > automatically mean (per RFC4271) that such implementation will either > translate AS_CONFED_SET to AS_SET (this operation is not defined neither This cant be done as you would not want to leak the member AS numbers outside the confederation. > in draft nor in RFC4271) or will it set ATOMIC_AGGREGATE? Presence of ATOMIC_AGGREGATE informs the downstream neighbors that the AS_PATH information may be incomplete and/or in a nonordered set. This is not applicable for BGP confederation speakers that strip of the AS_CONFED_* segments when advertising routes to non-confederation peers as these peers dont anyways expect to see confederation member AS numbers in the AS_PATH. Note that non-confed peers are unaware that the neighboring AS is running confederations. There is thus no loss of any AS_PATH information here and therefore no need of an ATOMIC_AGGREGATE. Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 13 07:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCEQi-0001MO-Nf; Sun, 13 Aug 2006 07:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCEQh-0001M9-TM; Sun, 13 Aug 2006 07:46:55 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCEQg-00024A-Js; Sun, 13 Aug 2006 07:46:55 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1GCEQW-0007RZ-30; Sun, 13 Aug 2006 13:46:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] Last Call: 'Autonomous System Confederations for BGP'toDraft Standard (draft-ietf-idr-rfc3065bis) Date: Sun, 13 Aug 2006 13:46:43 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240BF2D3@paul.adoffice.local.de.easynet.net> In-Reply-To: <004101c6be9f$0179e100$0201a8c0@rs.riverstonenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Last Call: 'Autonomous System Confederations for BGP'toDraft Standard (draft-ietf-idr-rfc3065bis) Thread-Index: Aca+nwdXGYc3qGG3QLukvPdwIfT3GAALmmXw From: "Ilya Varlashkin" To: "Manav Bhatia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: idr@ietf.org, iesg@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Manav, > -----Original Message----- > Hi iLya, >=20 > > The draft calls for simply removing AS_CONFED_SET. Would it=20 > > automatically mean (per RFC4271) that such implementation=20 > will either=20 > > translate AS_CONFED_SET to AS_SET (this operation is not defined=20 > > neither >=20 > This cant be done as you would not want to leak the member AS=20 > numbers outside the confederation. >=20 > > in draft nor in RFC4271) or will it set ATOMIC_AGGREGATE? >=20 > Presence of ATOMIC_AGGREGATE informs the downstream neighbors=20 > that the AS_PATH information may be incomplete and/or in a=20 > nonordered set. This is not applicable for BGP confederation=20 > speakers that strip of the AS_CONFED_* segments when=20 > advertising routes to non-confederation peers as these peers=20 > dont anyways expect to see confederation member AS numbers in=20 > the AS_PATH.=20 > Note that non-confed peers are unaware that the neighboring=20 > AS is running confederations. >=20 > There is thus no loss of any AS_PATH information here and=20 > therefore no need of an ATOMIC_AGGREGATE. >=20 All this I'm aware of. My statements were only related to situation where and if AS_CONFED_SET is/was used while aggregating foreign prefixes. First alternative was to forbid such use and that's where final document seems to be going, so above described situation won't happen and respective actions are not necessary. Kind regards, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 13 12:17:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCIe9-0008Vo-6d; Sun, 13 Aug 2006 12:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCIe7-0008Vg-Qq; Sun, 13 Aug 2006 12:17:03 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCIe6-0004Mg-Jd; Sun, 13 Aug 2006 12:17:03 -0400 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id A0C9E644F8; Sun, 13 Aug 2006 10:16:58 -0600 (MDT) In-Reply-To: <200608120009.k7C09eoZ017428@bright.research.att.com> References: <7000E71D8C525042A815432358B2F1240BF27D@paul.adoffice.local.de.easynet.net > <200608120009.k7C09eoZ017428@bright.research.att.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99994AF1-B884-416E-975A-B2A978832994@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP' to Draft Standard (draft-ietf-idr-rfc3065bis) Date: Sun, 13 Aug 2006 10:18:20 -0600 To: Bill Fenner X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "John G. Scudder" , iesg@ietf.org, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Aug 11, 2006, at 6:09 PM, Bill Fenner wrote: > >> (as far as I know) nobody has an >> implementation which actually generates AS_CONFED_SETs nor does such >> seem likely, we're thinking that we should clarify the document by >> deprecating AS_CONFED_SET. > > Oops! In fact, when advancing to Draft Standard, that's exactly > what's > required - if nobody's implemented something, it *has* to get dropped > from the spec. Interestingly enough, I didn't decouple AS_CONFED_SET and AS_CONFED_SEQUENCE in the implementation report, though it was asked more/less explicitly whether reporting implementations support AS_CONFED_SET. I'll synch with John and Jeff to work up some next text that will hopefully accommodate this, thanks for the [belated] comments folks... -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 13 21:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCR58-0002pn-Ns; Sun, 13 Aug 2006 21:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCR56-0002nI-Qw for idr@ietf.org; Sun, 13 Aug 2006 21:17:28 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCR56-00022i-F8 for idr@ietf.org; Sun, 13 Aug 2006 21:17:28 -0400 Received: by py-out-1112.google.com with SMTP id m51so246623pye for ; Sun, 13 Aug 2006 18:17:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pyOBl8QyMiatZ+nB/dyEJ5GYPZKBGttkYjJJ3LxAg1N5Qa07rOI1IFjIE/xhm7oLUmOeQOlvNCY/Ce31zp3ZaJHCU9Ykk0Wo1Zs7sRxNb/rQxYpht/IRqBB8s1ThSiqTKuaC7986uNSPJOepSRDphqUq3U2wliY8bjcurB9oAyg= Received: by 10.64.193.8 with SMTP id q8mr6276782qbf; Sun, 13 Aug 2006 18:17:28 -0700 (PDT) Received: by 10.65.11.16 with HTTP; Sun, 13 Aug 2006 18:17:27 -0700 (PDT) Message-ID: <22e2bdee0608131817r44f5e7dg681beb9e8d39f20f@mail.gmail.com> Date: Mon, 14 Aug 2006 06:47:27 +0530 From: "Deepak Pandey" To: "Manav Bhatia" , joel@stevecrocker.com, paul.jakma@sun.com Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: <013f01c6bd2b$f3961320$0201a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> <92c950310608100908x4be6ad31vf99235f7797bf978@mail.gmail.com> <013f01c6bd2b$f3961320$0201a8c0@rs.riverstonenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, I think i understand the answer but just making sure that i am in synch .. To advertise multiple BGP paths we would need to change our decision process. That is, at some point of time we would say that all candidate routes left must be announced to the remote speaker if it had the RM bit set when it did the multiple_hop capability negotiation. I dont see you guys discussing this anywhere in your draft. Is it because the draft doesnt care as to WHEN one announces the multiple paths but rather deals with HOW one can do it? If its the latter, then its application dependent on when one would advertise multiple paths. Thus to solve the MED problem one would not look at the Router ID for tie breaking and would instead advertise all the remaining routes to the remote peer. Is this the case? If so, then i trust that there is value in adding this to the draft. If not, then i would want to see the details of when an implementation decides to announce multiple BGP paths. Warm Regards, Deepak On 8/11/06, Manav Bhatia wrote: > Hi Glen, > > Thanks for the comments. > > Let me illustrate how our proposal would work with mpbgp routes. > > A and B are two BGP speakers that have negotiated this capability with the > RM bit set. This means that A and B are both willing to accept multiple BGP > paths, so the other can announce the same. > > Assume A receives two routes to some destination X (afi=x1, safi=x2) with > mpbgp next-hops n1 and n2. It encodes the first route in MP_REACH_NLRI and > advertises that route. > > To advertise the next route the nlri part is encoded in MP_REACH_NLRI and > the nexthop is encoded in MULTIPLE_HOP attribute as shown below: > > MP_REACH_NLRI (as per draft-ietf-idr-rfc2858bis-10.txt) that encodes X: > > afi = x1 > safi = x2 > length of next hop address = 0 > reserved = 0 > nlri = X > > MULTIPLE_HOP is encoded as: > > afi = x1 > safi = x2 > number of nexthops = 1 > length of nexthop = length of n2 > network address = n2 > > The receiving BGP speaker B appends this route as it comes with along with > the MULTIPLE_HOP path attribute. It thus now has two routes (next-hops n1 > and n2) to reach X. > > Hope this helps. > > Regards, > Manav > > ----- Original Message ----- > From: "Glen Kent" > To: "Manav Bhatia" > Cc: > Sent: Thursday, August 10, 2006 9:38 PM > Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP > > > >I have been following the progress of this draft as the proposal of > > allowing advertisement of multiple BGP paths interests me and i think > > its a logical next step that BGP has to take at some point of time in > > future. The operators may not see a glaring need now but i think the > > proposal has enough merits to warrant a closer inspection of what all > > can be achieved with it. > > > > I know the draft claims to support multi-protocol BGP but an example > > or some text elucidating this would be extremely illuminating for most > > of the readers. > > > > Glen. > > > > On 8/10/06, Manav Bhatia wrote: > >> Folks, > >> > >> A revised draft of draft-bhatia-bgp-multiple-next-hops-01.txt has been > >> posted to the internet draft repository. This revision simplifies the > >> operation, and addresses some of the concerns expressed by IDR working > >> group > >> participants. The simplification comes primarily from removing a > >> capability > >> which analysis showed was purely informational. The previous draft > >> amongst > >> other things allowed for sending advertisements which differed on AS path > >> but had the same next-hop. In discussions, it was noted that since these > >> paths had the same next-hop, the receiver would need to combine them > >> anyway. > >> Therefore, the draft now requires that when sending multiple > >> advertisements > >> for the same NLRI, these advertisements must use differing next-hops. As > >> a > >> result of this, the next-hop becomes the distinguishing attribute, along > >> with the NLRI, for the advertisement. Thus, implicit withdrawls are > >> supported without needing to introduce additional indexing attributes. > >> > >> The proposal is compatible with IPv6 support, MPLS label advertisement, > >> and > >> BGP multi-protocol support. > >> > >> The text for optional support of only ECMP routes, a refinement of > >> sending > >> all routes with distinct next-hops for an NLRI, and the description of > >> the > >> constraints on how multiple advertisements are compressed when they are > >> being used by a BGP speaker, will be folded in as a short portion of the > >> next revision of this document or a separate draft as deemed fit by the > >> WG. > >> > >> http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-01.txt > >> > >> Thanks, > >> Manav > >> > >> > >> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www1.ietf.org/mailman/listinfo/idr > >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 14 23:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCpCS-0000QO-92; Mon, 14 Aug 2006 23:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCpCQ-0000Pf-JZ for idr@ietf.org; Mon, 14 Aug 2006 23:02:38 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCpCP-0003CD-7U for idr@ietf.org; Mon, 14 Aug 2006 23:02:38 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id UAA14011; Mon, 14 Aug 2006 20:02:35 -0700 (PDT) Received: from manavLpt ([10.128.16.135]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 20:02:34 -0700 Message-ID: <00a201c6c017$4202d320$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Deepak Pandey" , , References: <005301c6bc17$cdfdf480$0201a8c0@rs.riverstonenet.com> <92c950310608100908x4be6ad31vf99235f7797bf978@mail.gmail.com> <013f01c6bd2b$f3961320$0201a8c0@rs.riverstonenet.com> <22e2bdee0608131817r44f5e7dg681beb9e8d39f20f@mail.gmail.com> Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP Date: Tue, 15 Aug 2006 08:32:30 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 15 Aug 2006 03:02:35.0151 (UTC) FILETIME=[420C21F0:01C6C017] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Deepak, The draft details the procedures that a router must follow in order to advertise multiple BGP paths to a peer router. We do not mandate a logic on how a router may select multiple paths that it may want to advertise. This leaves flexibility and room for an implementation to : o advertise all the routes that it has (IXes) o advertise equal cost routes by filtering the paths fully, up until it would use router ID/peer-address based tie breakers. o advertise all routes matching some criterion (a community for example or user defined routemaps) .. the list goes on. Hope this helps. Cheers, Manav ----- Original Message ----- From: "Deepak Pandey" To: "Manav Bhatia" ; ; Cc: Sent: Monday, August 14, 2006 6:47 AM Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP > Hi, > > I think i understand the answer but just making sure that i am in synch .. > > To advertise multiple BGP paths we would need to change our decision > process. That is, at some point of time we would say that all > candidate routes left must be announced to the remote speaker if it > had the RM bit set when it did the multiple_hop capability > negotiation. I dont see you guys discussing this anywhere in your > draft. Is it because the draft doesnt care as to WHEN one announces > the multiple paths but rather deals with HOW one can do it? > > If its the latter, then its application dependent on when one would > advertise multiple paths. Thus to solve the MED problem one would not > look at the Router ID for tie breaking and would instead advertise all > the remaining routes to the remote peer. > > Is this the case? If so, then i trust that there is value in adding > this to the draft. If not, then i would want to see the details of > when an implementation decides to announce multiple BGP paths. > > Warm Regards, > Deepak > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 15 12:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1sg-0000ie-8D; Tue, 15 Aug 2006 12:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1se-0000iY-O3 for idr@ietf.org; Tue, 15 Aug 2006 12:35:04 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD1sb-0007Av-AH for idr@ietf.org; Tue, 15 Aug 2006 12:35:04 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k7FGYwX39073; Tue, 15 Aug 2006 09:35:00 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7FGYrg11065; Tue, 15 Aug 2006 09:34:53 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608151634.k7FGYrg11065@merlot.juniper.net> To: "Glen Kent" Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: Your message of "Fri, 11 Aug 2006 22:36:30 +0530." <92c950310608111006s1ff48154kf9daab0102f0aa81@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26720.1155659693.1@juniper.net> Date: Tue, 15 Aug 2006 09:34:53 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Glen, [clipped...] > All right, this would work. Thanks for the explanation. > > Looking at this in another light leads me to think that its now kinda > possible to disassociate the AFI-SAFI (or simply the network layer > protocol) of the next-hop with that of the NLRI in a more elegant and > a scalable way. > > I have in the past expressed my displeasure at how we pad NULL RDs in > 2547 when filling the next-hop information in the mp-reach-nlri path > attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a > reason why we need to restrict the network layer address family of the > next-hop to be the same as that of the NLRI. draft-ietf-idr-rfc2858bis-10.txt does *not* restrict the network layer address family of the next hop to be the same as that of the NLRI. Quoting from the spec (draft-ietf-idr-rfc2858bis-10.txt): Address Family Identifier: This field in combination with the Subsequent Address Family Identifier field identifies the Network Layer protocol associated with the Network Address of Next Hop and the semantics of the Network Layer Reachability Information that follows. In other words, the same (afi, safi) tuple defines two things: (1) the network layer protocol associated with the Network Address of Next Hop, and (2) the encoding/semantics of NLRI. Nowhere in the spec there is a requirement that the encoding/semantics of Next Hop be the same as NLRI. For example let's look at VPLS auto-discovery with BGP (draft-ietf-l2vpn-signaling-08.txt). Quoting from the spec: In summary, the BGP advertisement for a particular VSI at a given PE will contain: o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr o a BGP next hop equal to the loopback address of the PE Here you have AFI = L2VPN, yet the next hop contains a plain IPv4 address. So, clearly for a given (afi,safi) one could place a plain IPv4 address in the Next Hop, yet carry some non IPv4 NLRI, and use AFI that is not the IPv4 AFI. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 15 13:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2nL-0001Z0-M4; Tue, 15 Aug 2006 13:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2nK-0001Yv-94 for idr@ietf.org; Tue, 15 Aug 2006 13:33:38 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2nI-0001iP-1K for idr@ietf.org; Tue, 15 Aug 2006 13:33:38 -0400 Received: by wx-out-0506.google.com with SMTP id t4so845862wxc for ; Tue, 15 Aug 2006 10:33:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MpKhBejiwTFtpUCRG2TUeQLRZx5d0y5T+i7yDHKGJDHFsQArONtvFXZUIblBXNQodc1HIbR0deuv56XuX6z99rfcHByc6+/PnQnwGFQjOm0nnb/xyrqUWxtU71C5jVB/ZwmBc4U/YxJJBM3BRp+8WpAlKPE4lKRMnyAllF/V5XE= Received: by 10.49.26.18 with SMTP id d18mr1647301nfj; Tue, 15 Aug 2006 10:33:35 -0700 (PDT) Received: by 10.82.131.17 with HTTP; Tue, 15 Aug 2006 10:33:34 -0700 (PDT) Message-ID: <92c950310608151033l3010229dkb1706fde73e0d808@mail.gmail.com> Date: Tue, 15 Aug 2006 23:03:34 +0530 From: "Glen Kent" To: "Yakov Rekhter" Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: <200608151634.k7FGYrg11065@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92c950310608111006s1ff48154kf9daab0102f0aa81@mail.gmail.com> <200608151634.k7FGYrg11065@merlot.juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov, Certainly one can do this by creating new AFI and SAFI types. But then that tuple can only be used for that particular nexthop and NLRI set. So each time we require a new permutation we need to request IANA for getting more code points. Taking your own example, if the PE uses IPv6 then i would need a different AFI, SAFI to convey the information. But Yes, it will work with the existing mechanisms. Affably, Glen On 8/15/06, Yakov Rekhter wrote: > Glen, > > [clipped...] > > > All right, this would work. Thanks for the explanation. > > > > Looking at this in another light leads me to think that its now kinda > > possible to disassociate the AFI-SAFI (or simply the network layer > > protocol) of the next-hop with that of the NLRI in a more elegant and > > a scalable way. > > > > I have in the past expressed my displeasure at how we pad NULL RDs in > > 2547 when filling the next-hop information in the mp-reach-nlri path > > attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a > > reason why we need to restrict the network layer address family of the > > next-hop to be the same as that of the NLRI. > > draft-ietf-idr-rfc2858bis-10.txt does *not* restrict the network > layer address family of the next hop to be the same as that of the NLRI. > Quoting from the spec (draft-ietf-idr-rfc2858bis-10.txt): > > Address Family Identifier: > > This field in combination with the Subsequent Address Family > Identifier field identifies the Network Layer protocol associated > with the Network Address of Next Hop and the semantics of > the Network Layer Reachability Information that follows. > > In other words, the same (afi, safi) tuple defines two things: (1) > the network layer protocol associated with the Network Address of > Next Hop, and (2) the encoding/semantics of NLRI. > > Nowhere in the spec there is a requirement that the encoding/semantics > of Next Hop be the same as NLRI. For example let's look at > VPLS auto-discovery with BGP (draft-ietf-l2vpn-signaling-08.txt). > Quoting from the spec: > > In summary, the BGP advertisement for a particular VSI at a given PE > will contain: > > o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr > > o a BGP next hop equal to the loopback address of the PE > > Here you have AFI = L2VPN, yet the next hop contains a plain IPv4 > address. > > So, clearly for a given (afi,safi) one could place a plain IPv4 > address in the Next Hop, yet carry some non IPv4 NLRI, and use AFI > that is not the IPv4 AFI. > > Yakov. > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 15 14:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3eL-0002JW-0t; Tue, 15 Aug 2006 14:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3eI-0002Io-WA for idr@ietf.org; Tue, 15 Aug 2006 14:28:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3YF-0004zj-Dm for idr@ietf.org; Tue, 15 Aug 2006 14:22:07 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GD3JU-0005RC-JD for idr@ietf.org; Tue, 15 Aug 2006 14:06:58 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k7FI6nX40781; Tue, 15 Aug 2006 11:06:49 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7FI6hg32019; Tue, 15 Aug 2006 11:06:43 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608151806.k7FI6hg32019@merlot.juniper.net> To: "Glen Kent" Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: Your message of "Tue, 15 Aug 2006 23:03:34 +0530." <92c950310608151033l3010229dkb1706fde73e0d808@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33198.1155665203.1@juniper.net> Date: Tue, 15 Aug 2006 11:06:43 -0700 From: Yakov Rekhter X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Glen, > Yakov, > > Certainly one can do this by creating new AFI and SAFI types. > > But then that tuple can only be used for that particular > nexthop and NLRI set. So each time we require a new permutation we > need to request IANA for getting more code points. Using a distinct for a particular nexthop and NLRI set is one possible way, but *not* the only one possible (more on this below). > Taking your own example, if the PE uses IPv6 then i would need a > different AFI, SAFI to convey the information. You could use a different . But you can also use the same , and distinguish between IPv6 and IPv4 PE by using the nexthop length. Yakov. > But Yes, it will work with the existing mechanisms. > > Affably, > Glen > > On 8/15/06, Yakov Rekhter wrote: > > Glen, > > > > [clipped...] > > > > > All right, this would work. Thanks for the explanation. > > > > > > Looking at this in another light leads me to think that its now kinda > > > possible to disassociate the AFI-SAFI (or simply the network layer > > > protocol) of the next-hop with that of the NLRI in a more elegant and > > > a scalable way. > > > > > > I have in the past expressed my displeasure at how we pad NULL RDs in > > > 2547 when filling the next-hop information in the mp-reach-nlri path > > > attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a > > > reason why we need to restrict the network layer address family of the > > > next-hop to be the same as that of the NLRI. > > > > draft-ietf-idr-rfc2858bis-10.txt does *not* restrict the network > > layer address family of the next hop to be the same as that of the NLRI. > > Quoting from the spec (draft-ietf-idr-rfc2858bis-10.txt): > > > > Address Family Identifier: > > > > This field in combination with the Subsequent Address Family > > Identifier field identifies the Network Layer protocol associated > > with the Network Address of Next Hop and the semantics of > > the Network Layer Reachability Information that follows. > > > > In other words, the same (afi, safi) tuple defines two things: (1) > > the network layer protocol associated with the Network Address of > > Next Hop, and (2) the encoding/semantics of NLRI. > > > > Nowhere in the spec there is a requirement that the encoding/semantics > > of Next Hop be the same as NLRI. For example let's look at > > VPLS auto-discovery with BGP (draft-ietf-l2vpn-signaling-08.txt). > > Quoting from the spec: > > > > In summary, the BGP advertisement for a particular VSI at a given PE > > will contain: > > > > o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr > > > > o a BGP next hop equal to the loopback address of the PE > > > > Here you have AFI = L2VPN, yet the next hop contains a plain IPv4 > > address. > > > > So, clearly for a given (afi,safi) one could place a plain IPv4 > > address in the Next Hop, yet carry some non IPv4 NLRI, and use AFI > > that is not the IPv4 AFI. > > > > Yakov. > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 15 18:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD78j-0005Gi-6H; Tue, 15 Aug 2006 18:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD78h-0005CZ-QM for idr@ietf.org; Tue, 15 Aug 2006 18:11:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD78g-0006T7-Bb for idr@ietf.org; Tue, 15 Aug 2006 18:11:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Aug 2006 15:11:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FMBvVk017204; Tue, 15 Aug 2006 15:11:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7FMBvlR002697; Tue, 15 Aug 2006 15:11:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Aug 2006 15:11:53 -0700 Received: from [10.10.10.93] ([10.25.90.226]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 15:11:53 -0700 Message-ID: <44E246A6.5080604@cisco.com> Date: Tue, 15 Aug 2006 15:11:50 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP References: <200608151806.k7FI6hg32019@merlot.juniper.net> In-Reply-To: <200608151806.k7FI6hg32019@merlot.juniper.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Aug 2006 22:11:53.0306 (UTC) FILETIME=[D04F8BA0:01C6C0B7] DKIM-Signature: a=rsa-sha1; q=dns; l=3818; t=1155679917; x=1156543917; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Advertising=20Multiple=20Next=20Hop=20Routes=20in=20BGP; X=v=3Dcisco.com=3B=20h=3DiNTEwLpEepK9hus3iZTF/oFYOSs=3D; b=Ftm5bW/i2pWULD/fPGJevzEL0Spn0SgFAg20Vzvte7w+w4RKcHMYjuPXSc6CRfJXvZDZmRLW AMwZ9Kvq+MmoHcCweZlpJGqOIc3itossb0H3HmDcr62JQy85u7bQDuVu; Authentication-Results: sj-dkim-3.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Yakov, > You could use a different . But you can also use the > same , and distinguish between IPv6 and IPv4 PE by using > the nexthop length. One could also observe that what you indicated is exactly the approach we took when defining new AFI/SAFI NLRI & NH for RT-Constrain. http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt Cheers, R. > Glen, > >> Yakov, >> >> Certainly one can do this by creating new AFI and SAFI types. >> >> But then that tuple can only be used for that particular >> nexthop and NLRI set. So each time we require a new permutation we >> need to request IANA for getting more code points. > > Using a distinct for a particular nexthop and NLRI set > is one possible way, but *not* the only one possible (more on this > below). > >> Taking your own example, if the PE uses IPv6 then i would need a >> different AFI, SAFI to convey the information. > > You could use a different . But you can also use the > same , and distinguish between IPv6 and IPv4 PE by using > the nexthop length. > > Yakov. > >> But Yes, it will work with the existing mechanisms. >> >> Affably, >> Glen >> >> On 8/15/06, Yakov Rekhter wrote: >>> Glen, >>> >>> [clipped...] >>> >>>> All right, this would work. Thanks for the explanation. >>>> >>>> Looking at this in another light leads me to think that its now kinda >>>> possible to disassociate the AFI-SAFI (or simply the network layer >>>> protocol) of the next-hop with that of the NLRI in a more elegant and >>>> a scalable way. >>>> >>>> I have in the past expressed my displeasure at how we pad NULL RDs in >>>> 2547 when filling the next-hop information in the mp-reach-nlri path >>>> attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a >>>> reason why we need to restrict the network layer address family of the >>>> next-hop to be the same as that of the NLRI. >>> draft-ietf-idr-rfc2858bis-10.txt does *not* restrict the network >>> layer address family of the next hop to be the same as that of the NLRI. >>> Quoting from the spec (draft-ietf-idr-rfc2858bis-10.txt): >>> >>> Address Family Identifier: >>> >>> This field in combination with the Subsequent Address Family >>> Identifier field identifies the Network Layer protocol associated >>> with the Network Address of Next Hop and the semantics of >>> the Network Layer Reachability Information that follows. >>> >>> In other words, the same (afi, safi) tuple defines two things: (1) >>> the network layer protocol associated with the Network Address of >>> Next Hop, and (2) the encoding/semantics of NLRI. >>> >>> Nowhere in the spec there is a requirement that the encoding/semantics >>> of Next Hop be the same as NLRI. For example let's look at >>> VPLS auto-discovery with BGP (draft-ietf-l2vpn-signaling-08.txt). >>> Quoting from the spec: >>> >>> In summary, the BGP advertisement for a particular VSI at a given PE >>> will contain: >>> >>> o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr >>> >>> o a BGP next hop equal to the loopback address of the PE >>> >>> Here you have AFI = L2VPN, yet the next hop contains a plain IPv4 >>> address. >>> >>> So, clearly for a given (afi,safi) one could place a plain IPv4 >>> address in the Next Hop, yet carry some non IPv4 NLRI, and use AFI >>> that is not the IPv4 AFI. >>> >>> Yakov. >>> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 15 18:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD7Ao-00067A-RQ; Tue, 15 Aug 2006 18:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD7An-000675-EB for idr@ietf.org; Tue, 15 Aug 2006 18:14:09 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD7Am-0006Ye-0O for idr@ietf.org; Tue, 15 Aug 2006 18:14:09 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7FME51Z039077; Tue, 15 Aug 2006 15:14:05 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7FME5g88821; Tue, 15 Aug 2006 15:14:05 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608152214.k7FME5g88821@merlot.juniper.net> To: raszuk@cisco.com Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: Your message of "Tue, 15 Aug 2006 15:11:50 PDT." <44E246A6.5080604@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58779.1155680045.1@juniper.net> Date: Tue, 15 Aug 2006 15:14:05 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Robert, > Hi Yakov, > > > You could use a different . But you can also use the > > same , and distinguish between IPv6 and IPv4 PE by using > > the nexthop length. > > One could also observe that what you indicated is exactly the approach > we took when defining new AFI/SAFI NLRI & NH for RT-Constrain. > > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt You are absolutely correct. Thanks for pointing this out. Yakov. > > Cheers, > R. > > > > > Glen, > > > >> Yakov, > >> > >> Certainly one can do this by creating new AFI and SAFI types. > >> > >> But then that tuple can only be used for that particular > >> nexthop and NLRI set. So each time we require a new permutation we > >> need to request IANA for getting more code points. > > > > Using a distinct for a particular nexthop and NLRI set > > is one possible way, but *not* the only one possible (more on this > > below). > > > >> Taking your own example, if the PE uses IPv6 then i would need a > >> different AFI, SAFI to convey the information. > > > > You could use a different . But you can also use the > > same , and distinguish between IPv6 and IPv4 PE by using > > the nexthop length. > > > > Yakov. > > > >> But Yes, it will work with the existing mechanisms. > >> > >> Affably, > >> Glen > >> > >> On 8/15/06, Yakov Rekhter wrote: > >>> Glen, > >>> > >>> [clipped...] > >>> > >>>> All right, this would work. Thanks for the explanation. > >>>> > >>>> Looking at this in another light leads me to think that its now kinda > >>>> possible to disassociate the AFI-SAFI (or simply the network layer > >>>> protocol) of the next-hop with that of the NLRI in a more elegant and > >>>> a scalable way. > >>>> > >>>> I have in the past expressed my displeasure at how we pad NULL RDs in > >>>> 2547 when filling the next-hop information in the mp-reach-nlri path > >>>> attribute. To me mp-reach-nlri/2547 is a big kludge and i dont see a > >>>> reason why we need to restrict the network layer address family of the > >>>> next-hop to be the same as that of the NLRI. > >>> draft-ietf-idr-rfc2858bis-10.txt does *not* restrict the network > >>> layer address family of the next hop to be the same as that of the NLRI. > >>> Quoting from the spec (draft-ietf-idr-rfc2858bis-10.txt): > >>> > >>> Address Family Identifier: > >>> > >>> This field in combination with the Subsequent Address Family > >>> Identifier field identifies the Network Layer protocol associated > >>> with the Network Address of Next Hop and the semantics of > >>> the Network Layer Reachability Information that follows. > >>> > >>> In other words, the same (afi, safi) tuple defines two things: (1) > >>> the network layer protocol associated with the Network Address of > >>> Next Hop, and (2) the encoding/semantics of NLRI. > >>> > >>> Nowhere in the spec there is a requirement that the encoding/semantics > >>> of Next Hop be the same as NLRI. For example let's look at > >>> VPLS auto-discovery with BGP (draft-ietf-l2vpn-signaling-08.txt). > >>> Quoting from the spec: > >>> > >>> In summary, the BGP advertisement for a particular VSI at a given PE > >>> will contain: > >>> > >>> o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr > >>> > >>> o a BGP next hop equal to the loopback address of the PE > >>> > >>> Here you have AFI = L2VPN, yet the next hop contains a plain IPv4 > >>> address. > >>> > >>> So, clearly for a given (afi,safi) one could place a plain IPv4 > >>> address in the Next Hop, yet carry some non IPv4 NLRI, and use AFI > >>> that is not the IPv4 AFI. > >>> > >>> Yakov. > >>> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www1.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 16 18:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTNL-0001p6-Lp; Wed, 16 Aug 2006 17:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTNK-0001nA-6Q for idr@ietf.org; Wed, 16 Aug 2006 17:56:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDMj7-0005Rj-TM for idr@ietf.org; Wed, 16 Aug 2006 10:50:37 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDMj0-00064j-JA for idr@ietf.org; Wed, 16 Aug 2006 10:50:31 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 019A24E544; Wed, 16 Aug 2006 10:50:29 -0400 (EDT) Date: Wed, 16 Aug 2006 10:50:29 -0400 From: Jeffrey Haas To: idr@ietf.org Subject: Re: [Idr] Last Call: 'Autonomous System Confederations for BGP'toDraft Standard (draft-ietf-idr-rfc3065bis) Message-ID: <20060816145029.GD13263@scc.mi.org> References: <7000E71D8C525042A815432358B2F1240BF2D1@paul.adoffice.local.de.easynet.net> <004101c6be9f$0179e100$0201a8c0@rs.riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004101c6be9f$0179e100$0201a8c0@rs.riverstonenet.com> User-Agent: Mutt/1.3.28i X-Spam-Score: -1.3 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Sun, Aug 13, 2006 at 11:39:11AM +0530, Manav Bhatia wrote: > >in draft nor in RFC4271) or will it set ATOMIC_AGGREGATE? > > Presence of ATOMIC_AGGREGATE informs the downstream neighbors that the > AS_PATH information may be incomplete and/or in a nonordered set. This is > not applicable for BGP confederation speakers that strip of the AS_CONFED_* > segments when advertising routes to non-confederation peers as these peers > dont anyways expect to see confederation member AS numbers in the AS_PATH. > Note that non-confed peers are unaware that the neighboring AS is running > confederations. In the instance where a set of routes are aggregated within a confederation and ATOMIC_AGGREGATE is set for some reason, it should stay set when readvertising the route outside of the confederation. There is the possibility that the original contributing routes, when aggregated at the confederation edge would not have yielded ATOMIC_AGGREGATE. However, we can't know this. This is a better safe than sorry situation. I find it likely that people who are generating AS_CONFED_SETs aren't likely to do lossy (AS_PATH truncation) based aggregation. This, however, is just an opinion. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 16 18:10:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTZp-00075L-Q4; Wed, 16 Aug 2006 18:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTZo-00075D-IS for idr@ietf.org; Wed, 16 Aug 2006 18:09:28 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDTZn-0000hG-8n for idr@ietf.org; Wed, 16 Aug 2006 18:09:28 -0400 Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1GDTZk-0001Bu-AW for idr@ietf.org; Thu, 17 Aug 2006 00:09:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Aug 2006 00:09:23 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240BF3A7@paul.adoffice.local.de.easynet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP confederations and MED Thread-Index: AcbBgKD2vb3Uug6+QTSrvXUdSM0Ovw== From: "Ilya Varlashkin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Idr] BGP confederations and MED X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello, I was went through several BGP-related RFC (4271, 3065, 3345) looking for info on how MED should be treated within confederation, but could find definetive answer. Consider a confederation consisting of AS 65001, 65002 and 65003 and peers with external AS100. A router within AS65003 has learned following: 192.168.1.0/24 AS_PATH: (65001) 100 MED 10 NEXT_HOP_IGP_COST 10 192.168.1.0/24 AS_PATH: (65002) 100 MED 20 NEXT_HOP_IGP_COST 5 Is it valid to compare MED of this two path's? I know that at least in one implementation with default configuration only exteral peer AS will be use to decide whether MED are comparable or not, therefore in above situation first path (65001) 100 will be selected. Is this is universal behaviour or not? The closest related info I could find in RFC was that a) AS_CONFED_SEQUENCE influences AS_PATH length for decision purpose; b) using confederations one should be careful selecting MED values; c) avoid BGP route selection based on MED. But none of this really says whether it's first AS in first AS_SEQUENCE (i.e. real external AS) should be the same or first AS must be the same including AS in AS_CONFED_SEQUENCE if that happens to be first (i.e. MED compared only for routes learned from the same member AS peer). Concern here is consistency between implementations - if one implementation requires only external peer AS to be the same for comparing MED, while another takes also into account confederation member AS, then routing loops may occur. Looks like it makes more sense to require only external AS to be the same and perhaps all current implementations are compliant with this behaviour, but I thought it may make sense mention somewhere about such process just to ensure consistency. RFC3065, and therefore draft rfc3065bis, seems to be appropriate place for it, though beeing in last call I guess it's too late to make such addition. Kind regards, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 17 23:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvPu-0008Cs-TM; Thu, 17 Aug 2006 23:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvPt-0008Ch-Qy for idr@ietf.org; Thu, 17 Aug 2006 23:53:05 -0400 Received: from 221x112x165x182.ap221.ftth.ucom.ne.jp ([221.112.165.182] helo=chez.maem.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDvPs-0003jw-G0 for idr@ietf.org; Thu, 17 Aug 2006 23:53:05 -0400 Received: from MAEMURA-X40 (localhost.maem.org [127.0.0.1]) by chez.maem.org (Postfix) with ESMTP id C0658B8AC; Fri, 18 Aug 2006 12:52:50 +0900 (JST) To: idr@ietf.org From: MAEMURA Akinori Message-Id: <200608181252.CHH65179.FNNB@maem.org> X-Mailer: Winbiff [Version 2.51 beta1] X-Accept-Language: ja,en Date: Fri, 18 Aug 2006 12:52:55 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Idr] 4byteASN? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, draft-ietf-idr-as4bytes-12.txt was to be expired in May 2006. I'm not a regular IETF participant, then my only information sources are idr@ietf and ietf@ietf. I haven't seen any discussion since then, nor I cannot find anything in rfc- queue. Can someone tell me what the status for this draft? Since RIRs move forward assignment of 4byte ASN - e.g. APNIC >from January 2007 on-demand, I'd like to think about experimental assignment like net39 class-A subnetting before 4byte ASN is widely used. Regards, Akinori ----- MAEMURA Akinori maem@maem.org _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 01:18:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDwih-0002nG-DW; Fri, 18 Aug 2006 01:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDwif-0002kc-R5 for idr@ietf.org; Fri, 18 Aug 2006 01:16:33 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDwid-0003hf-Fl for idr@ietf.org; Fri, 18 Aug 2006 01:16:33 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2006 22:16:31 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7I5GUp1005620; Thu, 17 Aug 2006 22:16:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7I5GO1G024774; Thu, 17 Aug 2006 22:16:30 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Aug 2006 22:16:28 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Aug 2006 22:16:28 -0700 Message-ID: <44E54D26.7090706@cisco.com> Date: Thu, 17 Aug 2006 22:16:22 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MAEMURA Akinori Subject: Re: [Idr] 4byteASN? References: <200608181252.CHH65179.FNNB@maem.org> In-Reply-To: <200608181252.CHH65179.FNNB@maem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2006 05:16:28.0605 (UTC) FILETIME=[75992ED0:01C6C285] DKIM-Signature: a=rsa-sha1; q=dns; l=1114; t=1155878190; x=1156742190; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=204byteASN?; X=v=3Dcisco.com=3B=20h=3DqeJ/kQU679WAgnW8G7eLUL6hUII=3D; b=qztP/w8i01J2REgl21VZsoC8sMjVF937orjwSRxCzCdflw8j41RV0MqmnZ+KNpcfE2Pqvd8k VUdp0I2Jha+RM/jFN1oEYWvG5b4FQHLJosUjMgA4hgUKDQnUXAZ3+KCG; Authentication-Results: sj-dkim-1.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The draft finished the IDR WG last call, and was submitted to the IESG for review last November. The current status of the draft is "AD Evaluation" according to the IESG status page: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6498&rfc_flag=0 -- Enke MAEMURA Akinori wrote: >Folks, > >draft-ietf-idr-as4bytes-12.txt was to be expired in May 2006. > >I'm not a regular IETF participant, then my only information >sources are idr@ietf and ietf@ietf. I haven't seen any >discussion since then, nor I cannot find anything in rfc- >queue. > >Can someone tell me what the status for this draft? > > >Since RIRs move forward assignment of 4byte ASN - e.g. APNIC >>from January 2007 on-demand, I'd like to think about >experimental assignment like net39 class-A subnetting before >4byte ASN is widely used. > > >Regards, >Akinori > >----- >MAEMURA Akinori maem@maem.org > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 01:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDwxX-0002ss-Cq; Fri, 18 Aug 2006 01:31:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDwxV-0002sm-IF for idr@ietf.org; Fri, 18 Aug 2006 01:31:53 -0400 Received: from 221x112x165x182.ap221.ftth.ucom.ne.jp ([221.112.165.182] helo=chez.maem.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDwxU-0006K6-5x for idr@ietf.org; Fri, 18 Aug 2006 01:31:53 -0400 Received: from MAEMURA-X40 (localhost.maem.org [127.0.0.1]) by chez.maem.org (Postfix) with ESMTP id E8E25B8AC; Fri, 18 Aug 2006 14:31:37 +0900 (JST) To: enkechen@cisco.com Subject: Re: [Idr] 4byteASN? From: MAEMURA Akinori References: <200608181252.CHH65179.FNNB@maem.org> <44E54D26.7090706@cisco.com> In-Reply-To: <44E54D26.7090706@cisco.com> Message-Id: <200608181431.DGD82352.FNBN@maem.org> X-Mailer: Winbiff [Version 2.51 beta1] X-Accept-Language: ja,en Date: Fri, 18 Aug 2006 14:31:43 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Thanks Enke. Only I needed to learn was this datatracker... :-( Regards, Akinori In message <44E54D26.7090706@cisco.com> "Re: [Idr] 4byteASN?" "Enke Chen " wrote: | The draft finished the IDR WG last call, and was submitted to the IESG | for review last November. | | The current status of the draft is "AD Evaluation" according to the IESG | status page: | | | https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6498&rfc_flag=0 | | -- Enke | | MAEMURA Akinori wrote: | | >Folks, | > | >draft-ietf-idr-as4bytes-12.txt was to be expired in May 2006. | > | >I'm not a regular IETF participant, then my only information | >sources are idr@ietf and ietf@ietf. I haven't seen any | >discussion since then, nor I cannot find anything in rfc- | >queue. | > | >Can someone tell me what the status for this draft? | > | > | >Since RIRs move forward assignment of 4byte ASN - e.g. APNIC | >>from January 2007 on-demand, I'd like to think about | >experimental assignment like net39 class-A subnetting before | >4byte ASN is widely used. | > | > | >Regards, | >Akinori | > | >----- | >MAEMURA Akinori maem@maem.org | > | >_______________________________________________ | >Idr mailing list | >Idr@ietf.org | >https://www1.ietf.org/mailman/listinfo/idr | > | > | _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 08:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE3jM-0000eE-G9; Fri, 18 Aug 2006 08:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE3jL-0000a4-Dv for idr@ietf.org; Fri, 18 Aug 2006 08:45:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE3jL-000651-CU for idr@ietf.org; Fri, 18 Aug 2006 08:45:43 -0400 Received: from ns02.chl.net ([64.95.32.37] helo=smtp.ttec.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GE3jI-0002FB-GF for idr@ietf.org; Fri, 18 Aug 2006 08:45:43 -0400 Received: from [192.168.0.2] (joe.ttec.com [192.168.0.2] (may be forged)) (authenticated bits=0) by smtp.ttec.com (8.13.6/8.13.6) with ESMTP id k7ICjYeF007632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2006 08:45:35 -0400 Message-ID: <44E5B66E.5050109@ttec.com> Date: Fri, 18 Aug 2006 08:45:34 -0400 From: Joe Maimon User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728 MultiZilla/1.7.0.1j X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Idr] unknown BGP capability X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello All, I have been advised that this post http://www.merit.edu/mail.archives/nanog/msg01754.html would be on topic for this email list, and in accordance with that advice, I am hoping to query this list for an answer. To recap: Peer A went down after being up for a while. When it came back up and tried to peer with B, A received a capability 64 and then sent a NOTIFICATION to B of Unsupported Capability. Is A's behavior proper/reasonable? I have attempted to read this situation into rfc3392 but all I see there is a scenario where A peers with B and sends B a capability 64. If A does not receive capability 64 from B, A may decide to send a notification. If A sends the notification, neither A nor B should attempt to automaticaly retry the connection. Thanks, Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 09:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4Aj-0004nF-Dl; Fri, 18 Aug 2006 09:14:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4Ai-0004n1-PO for idr@ietf.org; Fri, 18 Aug 2006 09:14:00 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4Af-00016V-Hq for idr@ietf.org; Fri, 18 Aug 2006 09:14:00 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 2DA884E7DF; Fri, 18 Aug 2006 09:13:49 -0400 (EDT) Date: Fri, 18 Aug 2006 09:13:49 -0400 From: Jeffrey Haas To: Joe Maimon Subject: Re: [Idr] unknown BGP capability Message-ID: <20060818131349.GG30708@scc.mi.org> References: <44E5B66E.5050109@ttec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E5B66E.5050109@ttec.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joe, On Fri, Aug 18, 2006 at 08:45:34AM -0400, Joe Maimon wrote: > Peer A went down after being up for a while. When it came back up and > tried to peer with B, A received a capability 64 and then sent a > NOTIFICATION to B of Unsupported Capability. > > Is A's behavior proper/reasonable? > > I have attempted to read this situation into rfc3392 but all I see there > is a scenario where A peers with B and sends B a capability 64. If A > does not receive capability 64 from B, A may decide to send a > notification. If A sends the notification, neither A nor B should > attempt to automaticaly retry the connection. http://www.iana.org/assignments/capability-codes will show you that 64 is graceful restart. Ironically, it's trying to be better about how the session deals with resetting. :-) Not re-establishing the connection automatically is the spec compliant behavior. In this case, call your provider and tell them to turn off GR if you're unable to support it. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 09:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4Gx-0007Wc-Nr; Fri, 18 Aug 2006 09:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4Gw-0007WX-92 for idr@ietf.org; Fri, 18 Aug 2006 09:20:26 -0400 Received: from smtp.ttec.com ([64.95.32.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4Gu-0001od-1T for idr@ietf.org; Fri, 18 Aug 2006 09:20:26 -0400 Received: from [192.168.0.2] (joe.ttec.com [192.168.0.2] (may be forged)) (authenticated bits=0) by smtp.ttec.com (8.13.6/8.13.6) with ESMTP id k7IDK6rd009762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2006 09:20:07 -0400 Message-ID: <44E5BE86.7040501@ttec.com> Date: Fri, 18 Aug 2006 09:20:06 -0400 From: Joe Maimon User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728 MultiZilla/1.7.0.1j X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: [Idr] unknown BGP capability References: <44E5B66E.5050109@ttec.com> <20060818131349.GG30708@scc.mi.org> In-Reply-To: <20060818131349.GG30708@scc.mi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Jeffrey Haas wrote: > Joe, > > Not re-establishing the connection automatically is the spec > compliant behavior. > But is terminating the connection (our equipment) spec compliant behavior? Good idea? Bad idea? > In this case, call your provider and tell them to turn off GR > if you're unable to support it. :-) They took it off long enough for us to come back up, but we will probably have some time convincing them to disable BGP SSO/NSF on their router which will affect all their other customers. > > -- Jeff Thanks for your reply. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 09:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4eQ-0001TJ-De; Fri, 18 Aug 2006 09:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE4eP-0001TA-Bh for idr@ietf.org; Fri, 18 Aug 2006 09:44:41 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4eO-00048I-2x for idr@ietf.org; Fri, 18 Aug 2006 09:44:41 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 0FC02E0431; Fri, 18 Aug 2006 09:44:38 -0400 (EDT) Date: Fri, 18 Aug 2006 09:44:38 -0400 From: John Leslie To: Joe Maimon Subject: Re: [Idr] unknown BGP capability Message-ID: <20060818134437.GC48924@verdi> References: <44E5B66E.5050109@ttec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E5B66E.5050109@ttec.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.6 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joe Maimon wrote: > > http://www.merit.edu/mail.archives/nanog/msg01754.html > > To recap: > > Peer A went down after being up for a while. When it came back up and > tried to peer with B, A received a capability 64 and then sent a > NOTIFICATION to B of Unsupported Capability. > > Is A's behavior proper/reasonable? No. (Unless A is actually objecting to the _absence_ of some other capability.) The original message is clearer than the recap... ] ] If A tries to peer with B, and B sends a BGP capability 64 to A, ] if A does not support that capability what would proper and/or ] reasonable behavior for A be? Per rfc3392: } } A BGP speaker that supports a particular capability may use this } capability with its peer after the speaker determines (as described } above) that the peer supports this capability. Receiving a capability advertisement is permissive only: it creates no obligation to use that capability. ] a) send ] ] unsupported capability code 64 lengh 6 No. This is a misreading of 3392 -- understandable because of the unfortunate choice of name for the subcode. "Unsupported Capability", as I understand it, is intended for cases where a BGP speaker cannot carry on with a peer which does not support some capability _it_ advertised. (Whether this should happen at all is perhaps worthy of discussion; but I'll merely say that such an action is unfriendly at best and downright nasty in a case where peering has been routine for an extended period.) b) ignore it Yes. > I have attempted to read this situation into rfc3392 but all I see there > is a scenario where A peers with B and sends B a capability 64. If A > does not receive capability 64 from B, A may decide to send a > notification. If A sends the notification, neither A nor B should > attempt to automaticaly retry the connection. (You shouldn't confuse the issue by who goes first. Otherwise, your reading is quite correct.) Incidentally, I do not read into 3392 any requirement that A is obligated to _ever_ send a capability advertisement if it receives a capability advertisement which does not contain some capability it insists upon. Thus, the actual content of the Notification only means that administrators of both ends need to talk to each other to find out what the incompatibility is. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 10:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE58D-0006ut-0H; Fri, 18 Aug 2006 10:15:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE58B-0006uo-OX for idr@ietf.org; Fri, 18 Aug 2006 10:15:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE589-0000IJ-H4 for idr@ietf.org; Fri, 18 Aug 2006 10:15:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2006 07:15:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,145,1154934000"; d="scan'208"; a="36891803:sNHT21494796" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7IEFP9k004045; Fri, 18 Aug 2006 10:15:25 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7IEFOdM006061; Fri, 18 Aug 2006 10:15:24 -0400 (EDT) Message-Id: <200608181415.k7IEFOdM006061@rtp-core-1.cisco.com> To: raszuk@cisco.com Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-reply-to: Your message of Tue, 15 Aug 2006 15:11:50 -0700. <44E246A6.5080604@cisco.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 Aug 2006 10:15:24 -0400 From: Eric Rosen DKIM-Signature: a=rsa-sha1; q=dns; l=1039; t=1155910525; x=1156774525; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:Eric=20Rosen=20 |Subject:Re=3A=20[Idr]=20Advertising=20Multiple=20Next=20Hop=20Routes=20in=20BGP= 20 |To:raszuk@cisco.com; X=v=3Dcisco.com=3B=20h=3Drz5SzN6MnfRxcEcwaUL/zdw0u40=3D; b=oqeJquoynnfMY3neUXZyzf3RnQRP4TemTVX70LHSal33DMxw2nckRsDC/bJI1Eu5FRJueLB+ 16vYt1kr8LZk0/4Nu1aM3cnIZx9TY6LEhguLNAd78AVsFzJFB07xi9NB; Authentication-Results: rtp-dkim-2.cisco.com; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov> you can also use the same , and distinguish between IPv6 Yakov> and IPv4 PE by using the nexthop length. Robert> One could also observe that what you indicated is exactly the approach Robert> we took when defining new AFI/SAFI NLRI & NH for RT-Constrain. For new AFI/SAFI's we can define what we want, but what if we want to be able to have a v6 NH for a v4 NLRI, or a v4 NH for a v6 NLRI? I don't think it makes much sense to define new SAFIs for these cases. But I also don't think we can just change the interpretation of the NH field of an existing AFI/SAFI without defining a corresponding BGP capability; after all, we need to know whether a given peer can deal with the fact that a v4 NLRI now has a v6 NH. Once we have a capability which means "I can handle an IPv4 or IPv6 NLRI which has a NH in a different address family", I'm not sure I see the great advantage of using the length (rather than a type field) to indicate the address family of the next hop. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 11:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5n4-0007IK-OU; Fri, 18 Aug 2006 10:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5n3-0007Gk-Fy for idr@ietf.org; Fri, 18 Aug 2006 10:57:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE4l2-0004qr-LW for idr@ietf.org; Fri, 18 Aug 2006 09:51:32 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GE4WL-0003Uk-Li for idr@ietf.org; Fri, 18 Aug 2006 09:36:22 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 2DFF34E79E; Fri, 18 Aug 2006 09:36:19 -0400 (EDT) Date: Fri, 18 Aug 2006 09:36:19 -0400 From: Jeffrey Haas To: Joe Maimon Subject: Re: [Idr] unknown BGP capability Message-ID: <20060818133619.GH30708@scc.mi.org> References: <44E5B66E.5050109@ttec.com> <20060818131349.GG30708@scc.mi.org> <44E5BE86.7040501@ttec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E5BE86.7040501@ttec.com> User-Agent: Mutt/1.3.28i X-Spam-Score: -1.9 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joe, On Fri, Aug 18, 2006 at 09:20:06AM -0400, Joe Maimon wrote: > But is terminating the connection (our equipment) spec compliant > behavior? Good idea? Bad idea? Well, I did mention it was spec compliant. Here it is: RFC 3392, Section 3: If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer, and terminate peering (see Section "Extensions to Error Handling" for more details). The Error Subcode in the message is set to Unsupported Capability. The message SHOULD contain the capability (capabilities) that causes the speaker to send the message. The decision to send the message and terminate peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically. It is arguable that for certain capabilities it is possible to "negotiate" a capability away, much like PPP will negotiate a number of parameters. For example, the fact your router said "I don't understand this capability 64 thing" could be enough for the remote router to attempt to re-establish the connection without that capability. The connection would come up and you'd be happy. Negotiation, however, is often a bad idea. It means that regardless of what each side configures, you may not end up with the expected effective configuration. For routers, this is usually a Bad Thing. The trend has been "bring initial misconfigurations to the operator's attention by not allowing the session to come up". > >In this case, call your provider and tell them to turn off GR > >if you're unable to support it. :-) > > They took it off long enough for us to come back up, but we will > probably have some time convincing them to disable BGP SSO/NSF on their > router which will affect all their other customers. I'd be shocked if this isn't a per-peer configuration item on their box. Just because they support NSF doesn't mean they have to advertise it to you. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 11:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE6Ei-0002sH-9g; Fri, 18 Aug 2006 11:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE6Eh-0002o6-6d for idr@ietf.org; Fri, 18 Aug 2006 11:26:15 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE6Ee-0000Jt-S9 for idr@ietf.org; Fri, 18 Aug 2006 11:26:15 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k7IFQCX01776; Fri, 18 Aug 2006 08:26:12 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7IFQ6g64570; Fri, 18 Aug 2006 08:26:06 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608181526.k7IFQ6g64570@merlot.juniper.net> To: erosen@cisco.com Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-Reply-To: Your message of "Fri, 18 Aug 2006 10:15:24 EDT." <200608181415.k7IEFOdM006061@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <87986.1155914766.1@juniper.net> Date: Fri, 18 Aug 2006 08:26:06 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: raszuk@cisco.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Eric, > Yakov> you can also use the same , and distinguish between IPv6 > Yakov> and IPv4 PE by using the nexthop length. > > Robert> One could also observe that what you indicated is exactly the approach > Robert> we took when defining new AFI/SAFI NLRI & NH for RT-Constrain. > > For new AFI/SAFI's we can define what we want, but what if we want to be > able to have a v6 NH for a v4 NLRI, or a v4 NH for a v6 NLRI? I don't think > it makes much sense to define new SAFIs for these cases. What are the *existing* AFI/SAFI's that you are referring to in the above ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 11:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE6EQ-0002TX-LY; Fri, 18 Aug 2006 11:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE6EO-0002TP-On for idr@ietf.org; Fri, 18 Aug 2006 11:25:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE6EN-0000JW-H6 for idr@ietf.org; Fri, 18 Aug 2006 11:25:56 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2006 08:25:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,146,1154934000"; d="scan'208"; a="36904575:sNHT22104672" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7IFPti5005925; Fri, 18 Aug 2006 11:25:55 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id k7IFPruJ027302; Fri, 18 Aug 2006 11:25:54 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060818134437.GC48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> Date: Fri, 18 Aug 2006 11:25:51 -0400 To: John Leslie From: "John G. Scudder" Subject: Re: [Idr] unknown BGP capability Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2018; t=1155914755; x=1156778755; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20unknown=20BGP=20capability |To:John=20Leslie=20; X=v=3Dcisco.com=3B=20h=3DDBfHBqmQWimlEVyHkJwyzflaEm8=3D; b=mOPTGS1HcjuocgoIdcT58BXkyUJPZh4aPvxf58Hq4Hjg/vfsiYO/Re42NOoKT3eHaZoC8Xag zUIYb2xIZK7lSl9RIvmwvyBJVx+EQ5YKMn3XtOJueRwjJ0A8sFocoIiw; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In short, I agree with John's analysis. A's behavior as described isn't per spec. A few more comments below: At 9:44 AM -0400 8/18/06, John Leslie wrote: > This is a misreading of 3392 -- understandable because of the >unfortunate choice of name for the subcode. "Unsupported Capability", >as I understand it, is intended for cases where a BGP speaker cannot >carry on with a peer which does not support some capability _it_ >advertised. I apologize for the choice of nomenclature. Unfortunately it would probably cause more confusion than it would benefit to rename "Unsupported Capability" to something else at this late date. > (Whether this should happen at all is perhaps worthy of discussion; >but I'll merely say that such an action is unfriendly at best and >downright nasty in a case where peering has been routine for an >extended period.) "This" being "drop the session if a capability you require isn't supported by your peer"? I agree it's a heavy hammer; however one can posit cases where it's necessary. A reasonable implementation wouldn't do this unless, as you say, the lack of support by the peer makes the peering impossible (either by policy or for some fundamental technical reason). In such a case (which I *believe* is purely hypothetical at present) I don't see a better option than to drop the session. > Incidentally, I do not read into 3392 any requirement that A is >obligated to _ever_ send a capability advertisement if it receives >a capability advertisement which does not contain some capability >it insists upon. I don't understand this sentence. >Thus, the actual content of the Notification only >means that administrators of both ends need to talk to each other >to find out what the incompatibility is. That seems like a fair characterization. (One could imagine automatically doing something on the basis of the notification, but such schemes are usually better left in the imagination.) --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 12:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7Sb-0004uW-K6; Fri, 18 Aug 2006 12:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7Sa-0004uR-1W for idr@ietf.org; Fri, 18 Aug 2006 12:44:40 -0400 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GE7SX-0001Eb-Md for idr@ietf.org; Fri, 18 Aug 2006 12:44:40 -0400 Received: (qmail 7046 invoked from network); 18 Aug 2006 16:44:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.2 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 18 Aug 2006 16:44:27 -0000 Received: from LIPC ([192.168.1.159]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 09:43:39 -0700 From: "Tony Li" To: , Subject: RE: [Idr] Advertising Multiple Next Hop Routes in BGP Date: Fri, 18 Aug 2006 09:43:33 -0700 Message-ID: <002101c6c2e5$7193d190$9f01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <200608181415.k7IEFOdM006061@rtp-core-1.cisco.com> Thread-Index: AcbC0Sfmeis2/FI8Rw6f4DWmNgr+MwAExruw X-OriginalArrivalTime: 18 Aug 2006 16:43:39.0646 (UTC) FILETIME=[7536C1E0:01C6C2E5] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Yakov Rekhter' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > For new AFI/SAFI's we can define what we want, but what if > we want to be > able to have a v6 NH for a v4 NLRI, or a v4 NH for a v6 NLRI? Before we worry too much about the how's, I think we ought to first consider the why's. I actually had an opportunity to look into this in a previous life and found some of the issues truly frightening. For example: suppose that you do have a v6 prefix with a v4 NH. How do you resolve that NH? Does the v6 BGP code look into the v4 routing table? Do you end up putting a v4 NH into your v6 routing table? How do you deal with little issues like ARP table lookups in your v6 forwarding path? Fundamentally, we have worked towards a ships in the night separation of v4 and v6, modulo some obvious fuzziness around using one for transport of the other. This is an instance where we are threatening to drastically lower the separation between the two and add another order of magnitude in architectural and implementation complexity. I am concerned. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 17:12:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBbQ-0004MV-7x; Fri, 18 Aug 2006 17:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBbP-0004Lf-5S for idr@ietf.org; Fri, 18 Aug 2006 17:10:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEBbP-0000Wp-3u for idr@ietf.org; Fri, 18 Aug 2006 17:10:03 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEBYY-0005i6-0n for idr@ietf.org; Fri, 18 Aug 2006 17:07:06 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id DA1D6E042B; Fri, 18 Aug 2006 17:07:03 -0400 (EDT) Date: Fri, 18 Aug 2006 17:07:03 -0400 From: John Leslie To: "John G. Scudder" Subject: Re: [Idr] unknown BGP capability Message-ID: <20060818210703.GE48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John G. Scudder wrote: > At 9:44 AM -0400 8/18/06, John Leslie wrote: > >> This is a misreading of 3392 -- understandable because of the >> unfortunate choice of name for the subcode. "Unsupported Capability", >> as I understand it, is intended for cases where a BGP speaker cannot >> carry on with a peer which does not support some capability _it_ >> advertised. > > I apologize for the choice of nomenclature. Unfortunately it would > probably cause more confusion than it would benefit to rename > "Unsupported Capability" to something else at this late date. I quite agree. >> (Whether this should happen at all is perhaps worthy of discussion; >> but I'll merely say that such an action is unfriendly at best and >> downright nasty in a case where peering has been routine for an >> extended period.) > > "This" being "drop the session if a capability you require isn't > supported by your peer"? I was thinking more in terms of "this" meaning an implementation requiring some extended capability to talk at all; regardless, I can certainly imagine a legitimate need -- one example being a BGP speaker assigned a 4-byte ASN. > I agree it's a heavy hammer; however one can posit cases where it's > necessary. Agreed. By "worthy of discussion" I meant only to suggest that perhaps not all of us understand _why_ it might be necessary: perhaps understanding the necessity would make the spec easier to understand. > A reasonable implementation wouldn't do this unless, as you say, > the lack of support by the peer makes the peering impossible > (either by policy or for some fundamental technical reason). In > such a case (which I *believe* is purely hypothetical at present) > I don't see a better option than to drop the session. Nor do I. >> Incidentally, I do not read into 3392 any requirement that A is >> obligated to _ever_ send a capability advertisement if it receives >> a capability advertisement which does not contain some capability >> it insists upon. > > I don't understand this sentence. The issue at hand is whether a particular extended capability is needed for BGP speaker A to peer with B. This in no way depends upon whether B has seen A's advertisement of capabilities. Indeed, if A receives an Open _without_ an advertisement of a capability it needs, it "knows" immediately that the session B is requesting is doomed. I do not read 3392 as prohibiting A from sending the Notification _before_ it sends an Open. (This distinction would be pointless, except that I meant to call attention to the fact that A might be sending the Notification to B not because it didn't support capability 64, but because it _required_ some capability not advertised by B. That, IMHO, would be in-spec, albeit confusing.) -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 18:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECnx-0007se-Gs; Fri, 18 Aug 2006 18:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECnw-0007sY-9B for idr@ietf.org; Fri, 18 Aug 2006 18:27:04 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GECnu-00020s-Uj for idr@ietf.org; Fri, 18 Aug 2006 18:27:04 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=c9UrWUmzkqkgG0JXG2Vn6FCS3sFBo5rO+KyHxvTxfWksYGx1jg59kZKm8GQFhJ9T; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.88.39] (helo=earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GECnn-0002tu-Dm; Fri, 18 Aug 2006 18:26:55 -0400 Message-ID: <44E63E03.9D54BB79@earthlink.net> Date: Fri, 18 Aug 2006 15:24:03 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Leslie Subject: Re: [Idr] unknown BGP capability References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7912c047cfac8dca492bdcc9868af72d69350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "John G. Scudder" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Ok, Inquiring minds want to know.. Is "Unsupported Capability": 1) A capability not currently configured on this interface? 2) A capability not currently configured on this router? 3) A capability that can't be configured? 4) A capability that requires all peers to support, thus because 1 peer doesn't support it, it isn't supported? 5) A resource specific capability that can be exausted? 6) A non-negotiated capability? 7) A 1-way or a 2-way capability? ie: 1-way: we can only import or export that functionality. A combination of the above or none of the above? IMO, it is a very generic term that can mean 1 or more things and in the past could have had a better definition. Mitchell Erblich ----------------- John Leslie wrote: > > John G. Scudder wrote: > > At 9:44 AM -0400 8/18/06, John Leslie wrote: > > > >> This is a misreading of 3392 -- understandable because of the > >> unfortunate choice of name for the subcode. "Unsupported Capability", > >> as I understand it, is intended for cases where a BGP speaker cannot > >> carry on with a peer which does not support some capability _it_ > >> advertised. > > > > I apologize for the choice of nomenclature. Unfortunately it would > > probably cause more confusion than it would benefit to rename > > "Unsupported Capability" to something else at this late date. > > I quite agree. > > >> (Whether this should happen at all is perhaps worthy of discussion; > >> but I'll merely say that such an action is unfriendly at best and > >> downright nasty in a case where peering has been routine for an > >> extended period.) > > > > "This" being "drop the session if a capability you require isn't > > supported by your peer"? > > I was thinking more in terms of "this" meaning an implementation > requiring some extended capability to talk at all; regardless, I can > certainly imagine a legitimate need -- one example being a BGP speaker > assigned a 4-byte ASN. > > > I agree it's a heavy hammer; however one can posit cases where it's > > necessary. > > Agreed. By "worthy of discussion" I meant only to suggest that > perhaps not all of us understand _why_ it might be necessary: perhaps > understanding the necessity would make the spec easier to understand. > > > A reasonable implementation wouldn't do this unless, as you say, > > the lack of support by the peer makes the peering impossible > > (either by policy or for some fundamental technical reason). In > > such a case (which I *believe* is purely hypothetical at present) > > I don't see a better option than to drop the session. > > Nor do I. > > >> Incidentally, I do not read into 3392 any requirement that A is > >> obligated to _ever_ send a capability advertisement if it receives > >> a capability advertisement which does not contain some capability > >> it insists upon. > > > > I don't understand this sentence. > > The issue at hand is whether a particular extended capability is > needed for BGP speaker A to peer with B. This in no way depends upon > whether B has seen A's advertisement of capabilities. Indeed, if A > receives an Open _without_ an advertisement of a capability it needs, > it "knows" immediately that the session B is requesting is doomed. > > I do not read 3392 as prohibiting A from sending the Notification > _before_ it sends an Open. > > (This distinction would be pointless, except that I meant to call > attention to the fact that A might be sending the Notification to B > not because it didn't support capability 64, but because it _required_ > some capability not advertised by B. That, IMHO, would be in-spec, > albeit confusing.) > > -- > John Leslie > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 19:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEAd-0004dp-Ew; Fri, 18 Aug 2006 19:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEAb-0004dj-KH for idr@ietf.org; Fri, 18 Aug 2006 19:54:33 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEEAZ-0007gI-BS for idr@ietf.org; Fri, 18 Aug 2006 19:54:33 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 56902E0434; Fri, 18 Aug 2006 19:54:25 -0400 (EDT) Date: Fri, 18 Aug 2006 19:54:25 -0400 From: John Leslie To: Erblichs Subject: Re: [Idr] unknown BGP capability Message-ID: <20060818235425.GF48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E63E03.9D54BB79@earthlink.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Erblichs wrote: > > Is "Unsupported Capability": > > 1) A capability not currently configured on this > interface? > > 2) A capability not currently configured on this > router? > > 3) A capability that can't be configured? "Unsupported Capability" is merely the title given to one error subcode. It means that a capability "required" by the BGP speaker sending the Notification is not supported by the prospective peer. (It may or may not have anything to do with configuration of any interface; it certainly _is_ a capability not currently configured on the BGP speaker _receiving_ the Notification.) Alas, the Notification includes no information on what particular capability is "unsupported"... > 4) A capability that requires all peers to support, > thus because 1 peer doesn't support it, it isn't > supported? There are only two peers involved in the session in question. Generally "Unsupported Capability" will result from a capability supported on the router sending the Notification, but not supported on the router receiving the Notification. However, this is not _necessarily_ the case. > 5) A resource specific capability that can be exausted? Unlikely. All "capabilities" are extension to the basic BGP-4. They might deal with what to do when some resource is in danger of being exhausted, but only in order to avoid having to abort the session. > 6) A non-negotiated capability? There is no meaningful "negotiation" here. The example I like is that if you are assigned a 4-byte AS number, you can't peer with anyone who doesn't support the 4-byte-ASN extension. > 7) A 1-way or a 2-way capability? ie: 1-way: we can only > import or export that functionality. There is nothing which is necessarily 2-way here. It's perfectly possible for one BGP speaker to send updates in accordance with an extension, while not advertising that capability itself because it can't handle all cases. (No, I'm not aware of any current implementation which does this!) > A combination of the above or none of the above? None of your descritions caught the essence of it. > IMO, it is a very generic term that can mean 1 or more > things and in the past could have had a better definition. I quite agree it could have had a better _name_. I also agree with John Scudder that it's too late to change the name. I don't agree that its "definition" is deficient. Perhaps I could write a better one; but I didn't volunteer at the time RFC 3392 was written, so I won't criticize the definition in RFC 3392. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 19:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEE8g-0003kj-IG; Fri, 18 Aug 2006 19:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEE8e-0003ea-BF for idr@ietf.org; Fri, 18 Aug 2006 19:52:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEDTj-00087p-VV for idr@ietf.org; Fri, 18 Aug 2006 19:10:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEDEV-0007Yl-LS for idr@ietf.org; Fri, 18 Aug 2006 18:54:33 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Aug 2006 18:54:31 -0400 X-IronPort-AV: i="4.08,147,1154923200"; d="scan'208"; a="97557164:sNHT30465620" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7IMsVNf011734; Fri, 18 Aug 2006 18:54:31 -0400 Received: from [10.0.1.5] (ssh-rtp-1.cisco.com [161.44.11.166]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7IMsSuJ009761; Fri, 18 Aug 2006 18:54:29 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <44E63E03.9D54BB79@earthlink.net> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> Date: Fri, 18 Aug 2006 18:54:23 -0400 To: Erblichs From: "John G. Scudder" Subject: Re: [Idr] unknown BGP capability Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2340; t=1155941671; x=1156805671; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20unknown=20BGP=20capability |To:Erblichs=20; X=v=3Dcisco.com=3B=20h=3DDBfHBqmQWimlEVyHkJwyzflaEm8=3D; b=gt6kcVrB/fw4w7E7M9FhjD5HG3s4iolXdbbY+BP63gkVmKh80T873WLlff0K3o/Jtr1C3nqd wDi24++jz2JVW5ubwMjRTip4WNuN7D8sDHJL69MW1B1rVjxg5LhE1tIM; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Mitchell, None of the above. As John Leslie previously pointed out, and I agreed with, "Unsupported Capability" [...] is intended for cases where a BGP speaker cannot carry on with a peer which does not support some capability _it_ [the BGP speaker] advertised. In the subsequent discussion, I said, A reasonable implementation wouldn't do this unless [...] the lack of support by the peer makes the peering impossible (either by policy or for some fundamental technical reason). So, once again: "Unsupported Capability X" means "I am complaining that you have not advertised capability X to me, and I require it." As for why you might choose to terminate the session instead of carrying on as best you can in such a situation, as I said this is currently a hypothetical and I don't think it would be productive to get into enumerating all the situations in which it might come into play. I'll give you one imaginary example, though, in hopes that it makes matters clearer. Suppose someone decided to make a BGP implementation that supported only the multiprotocol BGP NLRI encoding and not the classic encoding. If it didn't see capability code 1 from its peer, then it'd have no choice but to drop the session. IMO RFC 3392 is unambiguous on this point, though I agree that the choice of name for "Unsupported Capability" was regrettable. Hope this helps. --John At 3:24 PM -0700 8/18/06, Erblichs wrote: >Ok, > > Inquiring minds want to know.. > > Is "Unsupported Capability": > > 1) A capability not currently configured on this > interface? > > 2) A capability not currently configured on this > router? > > 3) A capability that can't be configured? > > 4) A capability that requires all peers to support, > thus because 1 peer doesn't support it, it isn't > supported? > > 5) A resource specific capability that can be exausted? > > 6) A non-negotiated capability? > > 7) A 1-way or a 2-way capability? ie: 1-way: we can only > import or export that functionality. > > A combination of the above or none of the above? > > IMO, it is a very generic term that can mean 1 or more > things and in the past could have had a better definition. > > > Mitchell Erblich > ----------------- > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 20:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvS-00006B-6o; Fri, 18 Aug 2006 20:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvQ-00005u-OW for idr@ietf.org; Fri, 18 Aug 2006 20:42:57 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEEnC-0001Py-QQ for idr@ietf.org; Fri, 18 Aug 2006 20:34:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KzF/VXEx3mw2IsAXCdOwGhayVDALrnpta8Lm8pZONONSE9b+Ph5XMqS8cxbxecb1; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.88.39] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GEEn2-0001JX-8I; Fri, 18 Aug 2006 20:34:16 -0400 Message-ID: <44E65A62.2D0DC12@earthlink.net> Date: Fri, 18 Aug 2006 17:25:06 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Leslie Subject: Re: [Idr] unknown BGP capability References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> <20060818235425.GF48924@verdi> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79396bdfab5dde3c16e6bfdaa8642ad7dd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Heys guys, Yes, I know what you guys are saying, but the default expectation seems to be dependent on the implementation. Here is a re-statement of the first two items... 1) Can two peers be requesting "X" at the same time on the same interface and ONLY 1 gets an Unsupported Capability? 2) Can two peers be requesting "X" at the same time on different interfaces and BECAUSE they are on different interfaces recieve different types of replies? These first two questions actually deal with configuring "Capabilities" on a per nbr, per intf, or per rtr. In my experience, I have seen implementations that differ on each of the items, because some implementations allow different scopes (nbr/peer, intf, and rtr). Thus, I feel that if a document is reviewing "Capabilities", that some type of "BEST PRACTICE/scope" document be specified to improve on the consistency. Mitchell Erblich ----------------------- John Leslie wrote: > > Erblichs wrote: > > > > Is "Unsupported Capability": > > > > 1) A capability not currently configured on this > > interface? > > > > 2) A capability not currently configured on this > > router? > > > > 3) A capability that can't be configured? > > "Unsupported Capability" is merely the title given to one error > subcode. It means that a capability "required" by the BGP speaker > sending the Notification is not supported by the prospective peer. > > (It may or may not have anything to do with configuration of any > interface; it certainly _is_ a capability not currently configured > on the BGP speaker _receiving_ the Notification.) > > Alas, the Notification includes no information on what particular > capability is "unsupported"... > > > 4) A capability that requires all peers to support, > > thus because 1 peer doesn't support it, it isn't > > supported? > > There are only two peers involved in the session in question. > Generally "Unsupported Capability" will result from a capability > supported on the router sending the Notification, but not > supported on the router receiving the Notification. However, this > is not _necessarily_ the case. > > > 5) A resource specific capability that can be exausted? > > Unlikely. All "capabilities" are extension to the basic BGP-4. > They might deal with what to do when some resource is in danger > of being exhausted, but only in order to avoid having to abort the > session. > > > 6) A non-negotiated capability? > > There is no meaningful "negotiation" here. The example I like > is that if you are assigned a 4-byte AS number, you can't peer > with anyone who doesn't support the 4-byte-ASN extension. > > > 7) A 1-way or a 2-way capability? ie: 1-way: we can only > > import or export that functionality. > > There is nothing which is necessarily 2-way here. It's perfectly > possible for one BGP speaker to send updates in accordance with > an extension, while not advertising that capability itself because > it can't handle all cases. (No, I'm not aware of any current > implementation which does this!) > > > A combination of the above or none of the above? > > None of your descritions caught the essence of it. > > > IMO, it is a very generic term that can mean 1 or more > > things and in the past could have had a better definition. > > I quite agree it could have had a better _name_. I also agree > with John Scudder that it's too late to change the name. > > I don't agree that its "definition" is deficient. Perhaps > I could write a better one; but I didn't volunteer at the time > RFC 3392 was written, so I won't criticize the definition in > RFC 3392. > > -- > John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 20:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvb-0000Aa-05; Fri, 18 Aug 2006 20:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvZ-000089-7Q for idr@ietf.org; Fri, 18 Aug 2006 20:43:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEEiq-0007eL-4Z for idr@ietf.org; Fri, 18 Aug 2006 20:29:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2006 17:29:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,147,1154934000"; d="scan'208"; a="36971779:sNHT21689264" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7J0Tt3K008772; Fri, 18 Aug 2006 20:29:55 -0400 Received: from [10.0.1.5] (ssh-rtp-1.cisco.com [161.44.11.166]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7J0TqdN003569; Fri, 18 Aug 2006 20:29:53 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060818235425.GF48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> <20060818235425.GF48924@verdi> Date: Fri, 18 Aug 2006 20:29:46 -0400 To: John Leslie From: "John G. Scudder" Subject: Re: [Idr] unknown BGP capability Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=570; t=1155947395; x=1156811395; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20unknown=20BGP=20capability |To:John=20Leslie=20; X=v=3Dcisco.com=3B=20h=3DDBfHBqmQWimlEVyHkJwyzflaEm8=3D; b=K/uFw3hG6/s+2jMxNUpLaXxFmgWmEl1PHYpQoXvQR/1ekLXcjIZgeXprB6OyjWSw/jC4eSWv tNmSrg69/oNTh6r1/JiRM/HR0sYSoGVNm1MA6PEURbvY3SxLlK6gD63L; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 7:54 PM -0400 8/18/06, John Leslie wrote: > Alas, the Notification includes no information on what particular >capability is "unsupported"... It ought to. From 3392 section 5, The Data field in the NOTIFICATION message SHOULD list the set of capabilities that cause the speaker to send the message. Each such capability is encoded the same way as it would be encoded in the OPEN message. That is, you're supposed to tell your peer which capability you're complaining about the lack of. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 20:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvS-00006B-6o; Fri, 18 Aug 2006 20:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvQ-00005u-OW for idr@ietf.org; Fri, 18 Aug 2006 20:42:57 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEEnC-0001Py-QQ for idr@ietf.org; Fri, 18 Aug 2006 20:34:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KzF/VXEx3mw2IsAXCdOwGhayVDALrnpta8Lm8pZONONSE9b+Ph5XMqS8cxbxecb1; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.88.39] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GEEn2-0001JX-8I; Fri, 18 Aug 2006 20:34:16 -0400 Message-ID: <44E65A62.2D0DC12@earthlink.net> Date: Fri, 18 Aug 2006 17:25:06 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Leslie Subject: Re: [Idr] unknown BGP capability References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> <20060818235425.GF48924@verdi> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79396bdfab5dde3c16e6bfdaa8642ad7dd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Heys guys, Yes, I know what you guys are saying, but the default expectation seems to be dependent on the implementation. Here is a re-statement of the first two items... 1) Can two peers be requesting "X" at the same time on the same interface and ONLY 1 gets an Unsupported Capability? 2) Can two peers be requesting "X" at the same time on different interfaces and BECAUSE they are on different interfaces recieve different types of replies? These first two questions actually deal with configuring "Capabilities" on a per nbr, per intf, or per rtr. In my experience, I have seen implementations that differ on each of the items, because some implementations allow different scopes (nbr/peer, intf, and rtr). Thus, I feel that if a document is reviewing "Capabilities", that some type of "BEST PRACTICE/scope" document be specified to improve on the consistency. Mitchell Erblich ----------------------- John Leslie wrote: > > Erblichs wrote: > > > > Is "Unsupported Capability": > > > > 1) A capability not currently configured on this > > interface? > > > > 2) A capability not currently configured on this > > router? > > > > 3) A capability that can't be configured? > > "Unsupported Capability" is merely the title given to one error > subcode. It means that a capability "required" by the BGP speaker > sending the Notification is not supported by the prospective peer. > > (It may or may not have anything to do with configuration of any > interface; it certainly _is_ a capability not currently configured > on the BGP speaker _receiving_ the Notification.) > > Alas, the Notification includes no information on what particular > capability is "unsupported"... > > > 4) A capability that requires all peers to support, > > thus because 1 peer doesn't support it, it isn't > > supported? > > There are only two peers involved in the session in question. > Generally "Unsupported Capability" will result from a capability > supported on the router sending the Notification, but not > supported on the router receiving the Notification. However, this > is not _necessarily_ the case. > > > 5) A resource specific capability that can be exausted? > > Unlikely. All "capabilities" are extension to the basic BGP-4. > They might deal with what to do when some resource is in danger > of being exhausted, but only in order to avoid having to abort the > session. > > > 6) A non-negotiated capability? > > There is no meaningful "negotiation" here. The example I like > is that if you are assigned a 4-byte AS number, you can't peer > with anyone who doesn't support the 4-byte-ASN extension. > > > 7) A 1-way or a 2-way capability? ie: 1-way: we can only > > import or export that functionality. > > There is nothing which is necessarily 2-way here. It's perfectly > possible for one BGP speaker to send updates in accordance with > an extension, while not advertising that capability itself because > it can't handle all cases. (No, I'm not aware of any current > implementation which does this!) > > > A combination of the above or none of the above? > > None of your descritions caught the essence of it. > > > IMO, it is a very generic term that can mean 1 or more > > things and in the past could have had a better definition. > > I quite agree it could have had a better _name_. I also agree > with John Scudder that it's too late to change the name. > > I don't agree that its "definition" is deficient. Perhaps > I could write a better one; but I didn't volunteer at the time > RFC 3392 was written, so I won't criticize the definition in > RFC 3392. > > -- > John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 20:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvb-0000Aa-05; Fri, 18 Aug 2006 20:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEEvZ-000089-7Q for idr@ietf.org; Fri, 18 Aug 2006 20:43:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEEiq-0007eL-4Z for idr@ietf.org; Fri, 18 Aug 2006 20:29:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2006 17:29:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,147,1154934000"; d="scan'208"; a="36971779:sNHT21689264" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7J0Tt3K008772; Fri, 18 Aug 2006 20:29:55 -0400 Received: from [10.0.1.5] (ssh-rtp-1.cisco.com [161.44.11.166]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7J0TqdN003569; Fri, 18 Aug 2006 20:29:53 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060818235425.GF48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> <20060818235425.GF48924@verdi> Date: Fri, 18 Aug 2006 20:29:46 -0400 To: John Leslie From: "John G. Scudder" Subject: Re: [Idr] unknown BGP capability Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=570; t=1155947395; x=1156811395; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20unknown=20BGP=20capability |To:John=20Leslie=20; X=v=3Dcisco.com=3B=20h=3DDBfHBqmQWimlEVyHkJwyzflaEm8=3D; b=K/uFw3hG6/s+2jMxNUpLaXxFmgWmEl1PHYpQoXvQR/1ekLXcjIZgeXprB6OyjWSw/jC4eSWv tNmSrg69/oNTh6r1/JiRM/HR0sYSoGVNm1MA6PEURbvY3SxLlK6gD63L; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 7:54 PM -0400 8/18/06, John Leslie wrote: > Alas, the Notification includes no information on what particular >capability is "unsupported"... It ought to. From 3392 section 5, The Data field in the NOTIFICATION message SHOULD list the set of capabilities that cause the speaker to send the message. Each such capability is encoded the same way as it would be encoded in the OPEN message. That is, you're supposed to tell your peer which capability you're complaining about the lack of. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 21:24:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEFWa-00005q-NE; Fri, 18 Aug 2006 21:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEFWZ-00005l-Ct for idr@ietf.org; Fri, 18 Aug 2006 21:21:19 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEFWW-0008LF-5s for idr@ietf.org; Fri, 18 Aug 2006 21:21:19 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 62DEDE042B; Fri, 18 Aug 2006 21:21:12 -0400 (EDT) Date: Fri, 18 Aug 2006 21:21:12 -0400 From: John Leslie To: "John G. Scudder" Subject: Re: [Idr] unknown BGP capability Message-ID: <20060819012112.GH48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> <20060818235425.GF48924@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John G. Scudder wrote: > At 7:54 PM -0400 8/18/06, John Leslie wrote: > >> Alas, the Notification includes no information on what particular >> capability is "unsupported"... > > It ought to. From 3392 section 5, > > The Data field in the NOTIFICATION message SHOULD list the set of > capabilities that cause the speaker to send the message. I read carelessly. :^( I saw the "SHOULD" and thought, "I can't depend on anything". I saw "set of capabilities that cause" and thought "the set of capabilities as received." I agree your reading is more reasonable. I have no idea how this is actually implemented by different router vendors... -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 18 21:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEFrF-0008OJ-U9; Fri, 18 Aug 2006 21:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEFrE-0008O8-1h for idr@ietf.org; Fri, 18 Aug 2006 21:42:40 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEFrC-0002Yl-QG for idr@ietf.org; Fri, 18 Aug 2006 21:42:40 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id 2FB30E042F; Fri, 18 Aug 2006 21:42:39 -0400 (EDT) Date: Fri, 18 Aug 2006 21:42:39 -0400 From: John Leslie To: Erblichs Subject: Re: [Idr] unknown BGP capability Message-ID: <20060819014239.GI48924@verdi> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <20060818210703.GE48924@verdi> <44E63E03.9D54BB79@earthlink.net> <20060818235425.GF48924@verdi> <44E65A62.2D0DC12@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E65A62.2D0DC12@earthlink.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Erblichs wrote: > > 1) Can two peers be requesting "X" at the same time on the > same interface and ONLY 1 gets an Unsupported Capability? I don't think you get it. :^( A Capabilities Advertisement is not a "request" for anything. It is rather a promise to support something. Apparently there are implementations that think it's a request. They are non-compliant. I wouldn't begin to guess what various non-compliant implementations might do. > 2) Can two peers be requesting "X" at the same time on > different interfaces and BECAUSE they are on different > interfaces recieve different types of replies? This seems unlikely (ignoring the "requesting" misnomer). At first blush, I can't think of a case where the requirement for a capability would vary by interface. > These first two questions actually deal with configuring "Capabilities" > on a per nbr, per intf, or per rtr. No. While "configuring" which capabilities to advertise may be possible, it's done mostly to kludge around incompatibilities. While not all of these are actual non-compliance issues, it's just as hard to guess what incompatibilities one may be trying to rectify by "configuring" capabilities. > In my experience, I have seen implementations that differ > on each of the items, because some implementations allow > different scopes (nbr/peer, intf, and rtr). I'm not surprised that implementations differ. I do not believe it is appropriate for Standards-Track RFCs to discuss how implementations actually differ. (The information changes too quickly, for one thing...) > Thus, I feel that if a document is reviewing "Capabilities", > that some type of "BEST PRACTICE/scope" document be specified to > improve on the consistency. "Best practices" also change. Such a discussion would be helpful, I agree, if it can be kept up-to-date. I can't think how to ensure this; nor do I see an acceptable path for publication as an RFC. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 11:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBwD-0006Wk-Al; Mon, 21 Aug 2006 11:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBwC-0006Wc-Bo for idr@ietf.org; Mon, 21 Aug 2006 11:43:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF8eb-0001On-0w for idr@ietf.org; Mon, 21 Aug 2006 08:13:17 -0400 Received: from ns02.chl.net ([64.95.32.37] helo=smtp.ttec.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF8bq-0005ti-HU for idr@ietf.org; Mon, 21 Aug 2006 08:10:29 -0400 Received: from [192.168.0.2] (joe.ttec.com [192.168.0.2] (may be forged)) (authenticated bits=0) by smtp.ttec.com (8.13.6/8.13.6) with ESMTP id k7LCAKjG021197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 08:10:21 -0400 Message-ID: <44E9A2AC.4040207@ttec.com> Date: Mon, 21 Aug 2006 08:10:20 -0400 From: Joe Maimon User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728 MultiZilla/1.7.0.1j X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: John Leslie Subject: Re: [Idr] unknown BGP capability References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> In-Reply-To: <20060818134437.GC48924@verdi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John Leslie wrote: > Joe Maimon wrote: > > This is a misreading of 3392 -- understandable because of the > unfortunate choice of name for the subcode. "Unsupported Capability", > as I understand it, is intended for cases where a BGP speaker cannot > carry on with a peer which does not support some capability _it_ > advertised. > Incidentally, I do not read into 3392 any requirement that A is > obligated to _ever_ send a capability advertisement if it receives > a capability advertisement which does not contain some capability > it insists upon. Thus, the actual content of the Notification only > means that administrators of both ends need to talk to each other > to find out what the incompatibility is. > Is some kind of update to rfc3392 in order? Perhaps something along the lines that specifies that Capability Unknown should not be sent when a BGP speaker receives a capability anouncement it does not support, but rather when it does not receive a capability announcement that is locally determined to be essential for peering? An explanation to such required behavior could be that this allows for expansion of BGP features via capabilities without requiring interoperability for all new features. In that manner Unsupported Capability should rather be named Required Capability. As it stands, apparently sending notification when receiving a unsupported capability announcment is not within spec -- since it is unspecified and illogical, but not because the spec discusses this behavior one way or the other. I can take to my vendor that rfc3392 only "authorizes" the sending of Unsupported Capability when a required capability is not received from the peer, but that may not be enough for them or for others. Thanks all, Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 12:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCM5-00087f-QR; Mon, 21 Aug 2006 12:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCM4-000863-RU for idr@ietf.org; Mon, 21 Aug 2006 12:10:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCLW-0003Yx-QT for idr@ietf.org; Mon, 21 Aug 2006 12:09:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2006 12:09:50 -0400 X-IronPort-AV: i="4.08,152,1154923200"; d="scan'208"; a="97827001:sNHT31078988" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LG9oQw023401; Mon, 21 Aug 2006 12:09:50 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7LG9odM007467; Mon, 21 Aug 2006 12:09:50 -0400 (EDT) Message-Id: <200608211609.k7LG9odM007467@rtp-core-1.cisco.com> To: tony.li@tony.li Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-reply-to: Your message of Fri, 18 Aug 2006 09:43:33 -0700. <002101c6c2e5$7193d190$9f01a8c0@tropos.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 21 Aug 2006 12:09:50 -0400 From: Eric Rosen DKIM-Signature: a=rsa-sha1; q=dns; l=871; t=1156176590; x=1157040590; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:Eric=20Rosen=20 |Subject:Re=3A=20[Idr]=20Advertising=20Multiple=20Next=20Hop=20Routes=20in=20BGP= 20 |To:tony.li@tony.li; X=v=3Dcisco.com=3B=20h=3Drz5SzN6MnfRxcEcwaUL/zdw0u40=3D; b=muy40XKDdTWRGWdF92BPTtBN3wY5rMxi16ciYSUotRK1QB2ARpop9ZdJNsTlBax7TpmrwlTi oZ9neuGCExDlNgv7ApUQ+VSIlvW2Hz8elLe1YoyGt1Z3zSj5LdCjiKpP; Authentication-Results: rtp-dkim-1.cisco.com; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: raszuk@cisco.com, 'Yakov Rekhter' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > suppose that you do have a v6 prefix with a v4 NH. How do > you resolve that NH? Does the v6 BGP code look into the v4 routing > table? Do you end up putting a v4 NH into your v6 routing table? How > do you deal with little issues like ARP table lookups in your v6 > forwarding path? The "v6 forwarding path" should be able to forward v6 packets through v4 tunnels, and that already raises all the same issues. > I think we ought to first consider the why's. In forwarding (tunneling) v6 through a v4 core, or v4 through a v6 core, it makes sense for the nh to be of the AF supported by the core. > Fundamentally, we have worked towards a ships in the night separation of > v4 and v6, modulo some obvious fuzziness around using one for transport > of the other. Yes, they're completely separate, except for when they aren't ;-) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 13:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDJ1-0004JZ-V2; Mon, 21 Aug 2006 13:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDIt-00048Z-Mu for idr@ietf.org; Mon, 21 Aug 2006 13:11:11 -0400 Received: from iceblock01.tropos.com ([12.108.168.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFD8S-0006yA-PH for idr@ietf.org; Mon, 21 Aug 2006 13:00:26 -0400 Received: (qmail 32639 invoked from network); 21 Aug 2006 17:00:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.2 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 21 Aug 2006 17:00:33 -0000 Received: from LIPC ([192.168.1.158]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 10:00:23 -0700 From: "Tony Li" To: , Subject: RE: [Idr] Advertising Multiple Next Hop Routes in BGP Date: Mon, 21 Aug 2006 10:00:19 -0700 Message-ID: <001b01c6c543$488eb2f0$9b01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200608211609.k7LG9odM007467@rtp-core-1.cisco.com> Thread-Index: AcbFPG6Li+QKq2M0RiCLPWTTgSN+JgABbInQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 21 Aug 2006 17:00:23.0104 (UTC) FILETIME=[4A8F8C00:01C6C543] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: raszuk@cisco.com, 'Yakov Rekhter' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > The "v6 forwarding path" should be able to forward v6 > packets through v4 > tunnels, and that already raises all the same issues. Not necessarily. In some implementations, the notion of a tunnel is presented to layer 3 protocols as an abstraction of an "interface". The transport protocol (the one providing the tunneling service) is then wholly isolated from the payload protocol. This makes it possible, for example, to carry AppleTalk over a GRE tunnel without modifying the AppleTalk implementation. Similarly, it makes it possible to resolve IPv4 next hops and pass them across an MPLS LSP without having to resolve v4 routes against MPLS next hops. > In forwarding (tunneling) v6 through a v4 core, or v4 > through a v6 core, it > makes sense for the nh to be of the AF supported by the core. I have to disagree. If a tunneling layer is providing a transport service, it is architecturally smart for it to be unaware of the protocols that it is transporting. Next hop resolution should be done by the payload protocol running its own independent routing on top of the transport layer. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 14:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEVR-0005bK-Fu; Mon, 21 Aug 2006 14:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEVQ-0005bF-2I for idr@ietf.org; Mon, 21 Aug 2006 14:28:12 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEVK-00055s-MF for idr@ietf.org; Mon, 21 Aug 2006 14:28:12 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2006 11:28:06 -0700 X-IronPort-AV: i="4.08,152,1154934000"; d="scan'208"; a="1849342417:sNHT33749816" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LIS6XC008255; Mon, 21 Aug 2006 11:28:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7LIS66W006566; Mon, 21 Aug 2006 11:28:06 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 11:28:05 -0700 Received: from [10.21.153.176] ([10.21.153.176]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 11:28:00 -0700 Message-ID: <44E9FB2A.80409@cisco.com> Date: Mon, 21 Aug 2006 11:27:54 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: tony.li@tony.li, erosen@cisco.com Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP References: <001b01c6c543$488eb2f0$9b01a8c0@tropos.com> In-Reply-To: <001b01c6c543$488eb2f0$9b01a8c0@tropos.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 18:28:01.0807 (UTC) FILETIME=[88FDF1F0:01C6C54F] DKIM-Signature: a=rsa-sha1; q=dns; l=2224; t=1156184886; x=1157048886; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Advertising=20Multiple=20Next=20Hop=20Routes=20in=20BGP; X=v=3Dcisco.com=3B=20h=3DiNTEwLpEepK9hus3iZTF/oFYOSs=3D; b=m7085mucJXYRMdqW7ACpibg/sRJE+3O3GW7Mgn2ZnGC+Z8CqwsBE6DcVIlFX2uxkuPGrSHy2 a0COvN79gFW+expxqe6SAi1lotfKtj8Kp2Uqgge3Zx82xwX7EeZWpAwH; Authentication-Results: sj-dkim-8.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'Yakov Rekhter' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I have to agree with Tony here. Tunneling means very different things to different people depending who you ask. And part of the mess has been introduced with 2.5 OSI layer tunnels in the past :)). In this no one really know if MPLS LSP is L2 or L3 pipe and different commercial implementations in regards to BGP NH resolution treat it in very different ways. I think (my personal opinion) the best approach to carry address families X over address family Y would with providing the overlay tunneling layer where control plane would be fully separated from transport layer. In that scheme the NH resolution or verification have no issues. Remote node failures are signaled from FIB tunnel tracking engine up to L3 in an event driven fashion. BGP is not affected by any need of changes. So my recommendation to this list would be to let the topic mature and consider all options before committing to any protocol change which may have any negative consequence of today's operational networks. Rgs, R. >> The "v6 forwarding path" should be able to forward v6 >> packets through v4 >> tunnels, and that already raises all the same issues. > > Not necessarily. > > In some implementations, the notion of a tunnel is presented to layer 3 > protocols as an abstraction of an "interface". The transport protocol > (the one providing the tunneling service) is then wholly isolated from > the payload protocol. This makes it possible, for example, to carry > AppleTalk over a GRE tunnel without modifying the AppleTalk > implementation. Similarly, it makes it possible to resolve IPv4 next > hops and pass them across an MPLS LSP without having to resolve v4 > routes against MPLS next hops. > > >> In forwarding (tunneling) v6 through a v4 core, or v4 >> through a v6 core, it >> makes sense for the nh to be of the AF supported by the core. > > > I have to disagree. If a tunneling layer is providing a transport > service, it is architecturally smart for it to be unaware of the > protocols that it is transporting. Next hop resolution should be done > by the payload protocol running its own independent routing on top of > the transport layer. > > Regards, > Tony > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 15:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFBs-0004SA-2f; Mon, 21 Aug 2006 15:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFBq-0004S5-9g for idr@ietf.org; Mon, 21 Aug 2006 15:12:02 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFFBp-0005Xc-2o for idr@ietf.org; Mon, 21 Aug 2006 15:12:02 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 8B6324F2DC; Mon, 21 Aug 2006 15:11:44 -0400 (EDT) Date: Mon, 21 Aug 2006 15:11:44 -0400 From: Jeffrey Haas To: Joe Maimon Subject: Re: [Idr] unknown BGP capability Message-ID: <20060821191144.GA14005@scc.mi.org> References: <44E5B66E.5050109@ttec.com> <20060818134437.GC48924@verdi> <44E9A2AC.4040207@ttec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E9A2AC.4040207@ttec.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: idr@ietf.org, John Leslie X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Mon, Aug 21, 2006 at 08:10:20AM -0400, Joe Maimon wrote: > In that manner Unsupported Capability should rather be named Required > Capability. I tend to think of this as "unacceptable capability set". This covers the case where you require it and it isn't sent, or you are sent the capability and you can't live with it for some weird reason. > As it stands, apparently sending notification when receiving a > unsupported capability announcment is not within spec -- since it is > unspecified and illogical, but not because the spec discusses this > behavior one way or the other. It's mostly out of scope of the spec. It depends on the capability and the features supported by the implementation. I have to apologize for my previous comments on this thread. I was mostly addressing the protocol correctness component of it rather than "does this make sense". > I can take to my vendor that rfc3392 only "authorizes" the sending of > Unsupported Capability when a required capability is not received from > the peer, but that may not be enough for them or for others. Noting the point of view in the wording helps make this a bit more clear: If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, I.e. "If *you* support a capability, but determine that *they* don't". This means that you know the capability. It is also possible that your vendor's implementation may be from the days when the feature was called "capability negotiation" and there was confusion as to whether the unsupported capability functionality was used to converge on a set of acceptable capability (like PPP). -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 16:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGpz-0001ou-RS; Mon, 21 Aug 2006 16:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGpy-0001om-PN for idr@ietf.org; Mon, 21 Aug 2006 16:57:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEBq-0001Jv-MJ for idr@ietf.org; Mon, 21 Aug 2006 14:07:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFDz5-0006zO-61 for idr@ietf.org; Mon, 21 Aug 2006 13:54:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2006 13:54:47 -0400 X-IronPort-AV: i="4.08,152,1154923200"; d="scan'208"; a="97847201:sNHT49869268" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7LHskjf015606; Mon, 21 Aug 2006 13:54:46 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7LHskuI028931; Mon, 21 Aug 2006 13:54:46 -0400 (EDT) Message-Id: <200608211754.k7LHskuI028931@rtp-core-2.cisco.com> To: tony.li@tony.li Subject: Re: [Idr] Advertising Multiple Next Hop Routes in BGP In-reply-to: Your message of Mon, 21 Aug 2006 10:00:19 -0700. <001b01c6c543$488eb2f0$9b01a8c0@tropos.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 21 Aug 2006 13:54:46 -0400 From: Eric Rosen DKIM-Signature: a=rsa-sha1; q=dns; l=1270; t=1156182886; x=1157046886; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:Eric=20Rosen=20 |Subject:Re=3A=20[Idr]=20Advertising=20Multiple=20Next=20Hop=20Routes=20in=20BGP= 20 |To:tony.li@tony.li; X=v=3Dcisco.com=3B=20h=3Drz5SzN6MnfRxcEcwaUL/zdw0u40=3D; b=DYXJb9lse1noqNRXo3poFozaRzJdnz7Opc1pL2lfMcYd/elaMczH9DTSYc/Xwkkoz3ly62D/ ZP6Xm3lKsjWrSDX01mOvV8OdkkmCyLYnNhBWW9dxaDmga8eflctKIeM9; Authentication-Results: rtp-dkim-2.cisco.com; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: raszuk@cisco.com, 'Yakov Rekhter' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > In some implementations, the notion of a tunnel is presented to layer 3 > protocols as an abstraction of an "interface". That's one possible implementation strategy, but certainly not the only one. Protocol-specific overlay models have numerous disadvantages. > This makes it possible, for example, to carry AppleTalk over a GRE tunnel > without modifying the AppleTalk implementation. If you want a fast Appletalk switching path, you need a piece of code to produce some sort of forwarding table data structure which contains the GRE header and the L2 header. So the piece of code which generates the Appletalk forwarding table entries needs to be able to get the IP and the L2 info. It doesn't much matter what you call this piece of code. > If a tunneling layer is providing a transport service, it is > architecturally smart for it to be unaware of the protocols that it is > transporting. But what we're talking about is the other way around, viz., the extent to which the protocols being transported need to be aware of the transporting protocol. It is very common for a higher layer protocol to define special procedures for interfacing with a lower layer. For example, ARP. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 21 17:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHaw-0001gv-1Z; Mon, 21 Aug 2006 17:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHau-0001dx-Q0 for idr@ietf.org; Mon, 21 Aug 2006 17:46:04 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFHat-0005na-EY for idr@ietf.org; Mon, 21 Aug 2006 17:46:04 -0400 Received: (qmail 30986 invoked from network); 21 Aug 2006 21:46:09 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.2 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 21 Aug 2006 21:46:09 -0000 Received: from LIPC ([192.168.1.106]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 14:45:59 -0700 From: "Tony Li" To: , Subject: RE: [Idr] Advertising Multiple Next Hop Routes in BGP Date: Mon, 21 Aug 2006 14:45:55 -0700 Message-ID: <002801c6c56b$2e249600$9b01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200608211754.k7LHskuI028931@rtp-core-2.cisco.com> Thread-Index: AcbFSvQWhXezS69MQZ6PsvXXl0S+8AAH6UFA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 21 Aug 2006 21:45:59.0995 (UTC) FILETIME=[30F198B0:01C6C56B] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: raszuk@cisco.com, 'Yakov Rekhter' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > > In some implementations, the notion of a tunnel is > presented to layer 3 > > protocols as an abstraction of an "interface". > > That's one possible implementation strategy, but certainly > not the only > one. True, but it's a common one, including brand C, J and the former brand P implementations. > Protocol-specific overlay models have numerous disadvantages. I agree completely! Why are you proposing one? > If you want a fast Appletalk switching path, you need a > piece of code to > produce some sort of forwarding table data structure which > contains the GRE > header and the L2 header. So the piece of code which > generates the > Appletalk forwarding table entries needs to be able to get > the IP and the L2 > info. It doesn't much matter what you call this piece of code. If you want to have a fast Appletalk switching path that supports tunneling, you end up caching an encaps string that is opaque to Appletalk. You don't need to modify Appletalk to carry IPv4 next hops. > > If a tunneling layer is providing a transport > service, it is > > architecturally smart for it to be unaware of the > protocols that it is > > transporting. > > But what we're talking about is the other way around, Exactly. Why? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 05:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSDq-0002pR-VD; Tue, 22 Aug 2006 05:06:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSDp-0002oP-7Q for idr@ietf.org; Tue, 22 Aug 2006 05:06:57 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFSDn-0003Cz-U2 for idr@ietf.org; Tue, 22 Aug 2006 05:06:57 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 3C58A2400D; Tue, 22 Aug 2006 11:06:45 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 1702A23F22 for ; Tue, 22 Aug 2006 11:06:45 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 04A8B2F592; Tue, 22 Aug 2006 11:06:44 +0200 (CEST) Message-Id: <7.0.1.0.2.20060822105158.03521e78@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 22 Aug 2006 11:06:35 +0200 To: idr@ietf.org, asn32@ripe.net From: Henk Uijterwaal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -4.4 X-RIPE-Signature: f0a35ed317aa48d3b43c470c35ceb36b X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Idr] 4byte ASN support in RFC4273 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org IDR List, RFC4273 says: bgpPathAttrASPAth OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2..255)) [...] EAch AS is represented as a pair of octets according to the following algorithm: first-byte-of-pair = ASNumber / 256 second-byte-of-pair = ASNumber & 255; And similar for bgp4PathAttrASPathSegment. Question: what will happen when 4byte ASN are deployed? Can I just replace the Octet string by 4 octets (ASN/(265^3), ASN/(256^2), ASN/256, ASN%255) (and assume that things will continue to work)? Or does this need an update of the RFC? The same RFC says: bgpPeerRemoteAs OBJECT-TYPE SYNTAX Integer32 (0...65535) Same question. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 06:25:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFTPz-0001Hm-BA; Tue, 22 Aug 2006 06:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFTPx-0001Gx-Cc for idr@ietf.org; Tue, 22 Aug 2006 06:23:33 -0400 Received: from smtp-vbr12.xs4all.nl ([194.109.24.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFTPw-0005Um-0C for idr@ietf.org; Tue, 22 Aug 2006 06:23:33 -0400 Received: from spa.averei.net (at3a.xs4all.nl [82.92.172.5]) by smtp-vbr12.xs4all.nl (8.13.6/8.13.6) with ESMTP id k7MANQwe051282; Tue, 22 Aug 2006 12:23:27 +0200 (CEST) (envelope-from tgen@netphreax.net) Received: by spa.averei.net (Postfix, from userid 1009) id 4FEBDEC864; Tue, 22 Aug 2006 12:23:26 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on spa.averei.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [10.64.2.8] (ns0.netphreax.net [84.83.37.40]) by spa.averei.net (Postfix) with ESMTP id 492EAEC860; Tue, 22 Aug 2006 12:23:24 +0200 (CEST) Message-ID: <44EADB17.8070601@netphreax.net> Date: Tue, 22 Aug 2006 10:23:19 +0000 From: "Thomas E. Spanjaard" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051118) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henk Uijterwaal Subject: Re: [Idr] 4byte ASN support in RFC4273 References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> In-Reply-To: <7.0.1.0.2.20060822105158.03521e78@ripe.net> X-Enigmail-Version: 0.93.0.0 X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: idr@ietf.org, asn32@ripe.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tgen@netphreax.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1472431013==" Errors-To: idr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1472431013== Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigEB48E106C7F41D92636019DE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB48E106C7F41D92636019DE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Henk Uijterwaal wrote: > RFC4273 says: > EAch AS is represented as a pair of octets according to the following > algorithm: > first-byte-of-pair = ASNumber / 256 > second-byte-of-pair = ASNumber & 255; > And similar for bgp4PathAttrASPathSegment. > Question: what will happen when 4byte ASN are deployed? Can I just > replace the Octet string by 4 octets (ASN/(265^3), ASN/(256^2), ASN/256, > ASN%255) (and assume that things will continue to work)? Or does this > need an update of the RFC? I think draft-ietf-idr-as4bytes-12.txt states that the ASPath should only be interpreted as 4-octet AS numbers when your peer advertises the 4byte AS capability and the other peer does so as well. Otherwise, it should interpret the AS_PATH as 2-octet AS numbers. > The same RFC says: > bgpPeerRemoteAs OBJECT-TYPE > SYNTAX Integer32 (0...65535) The 4-octet AS number of the NEW BGP peer is 'advertised' as the Capability Value of the Capability Optional Parameter of the Four-octet AS Number Capability, sized 4 octets (or if you will, an unsigned 32bits integer). The 2-octet AS to use by 4-octet AS peers is AS_TRANS, which is defined by IANA. Cheers, -- Thomas E. Spanjaard tgen@netphreax.net --------------enigEB48E106C7F41D92636019DE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iD8DBQFE6tsc6xCMwBJ+1+sRAwRyAJ9sP937ZYrQYiPOKUiE1kDiB/crfgCeOWgL B2hhH1kyVS7dappFyLjBOH0= =ZPx7 -----END PGP SIGNATURE----- --------------enigEB48E106C7F41D92636019DE-- --===============1472431013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============1472431013==-- From idr-bounces@ietf.org Tue Aug 22 09:28:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFWH2-0006Jy-4Y; Tue, 22 Aug 2006 09:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFWGz-0006Hu-WA for idr@ietf.org; Tue, 22 Aug 2006 09:26:30 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFWGy-0003yB-LM for idr@ietf.org; Tue, 22 Aug 2006 09:26:29 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id GAA08229; Tue, 22 Aug 2006 06:16:22 -0700 (PDT) Received: from manavLpt ([10.128.16.148]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 06:16:19 -0700 Message-ID: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: Date: Tue, 22 Aug 2006 18:46:12 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 22 Aug 2006 13:16:20.0230 (UTC) FILETIME=[28658260:01C6C5ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: skh@nexthop.com, Yakov Rekhter , "Joel M. Halpern" , Paul Jakma Subject: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt addresses all of the concerns and suggestions that were given in the past IETFs and the mailing list and we believe its in a reasonable form to be progressed further in the WG. The proposal is compatible with IPv6 support, MPLS label advertisement, and BGP multi-protocol support. We would like to ask for the working group status for this document, so that the working group may determine what revisions it wishes to make. Thanks, Joel, Paul and Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 12:24:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZ0J-0006Bq-OI; Tue, 22 Aug 2006 12:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZ0I-0006Bk-QH for idr@ietf.org; Tue, 22 Aug 2006 12:21:26 -0400 Received: from nz-out-0102.google.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZ0H-0005Ud-JP for idr@ietf.org; Tue, 22 Aug 2006 12:21:26 -0400 Received: by nz-out-0102.google.com with SMTP id i1so958773nzh for ; Tue, 22 Aug 2006 09:21:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ouAsEJUbsctotG1z/dmsrJ93gP75f6qTcwj+PDYGYP56x6uGBCFs8lAKuMBt+B9C2Rf2w1Tb3gFSXnayHhbBSv/DNpdWXrj4DdF47XM+1InUCYJ+J+1ZdhL6ssWsdu2AEEm6Tdkp4NN4039ndWcznBSbuJ9tdebN04PGn7VHsPI= Received: by 10.65.219.4 with SMTP id w4mr8707012qbq; Tue, 22 Aug 2006 09:21:25 -0700 (PDT) Received: by 10.65.163.7 with HTTP; Tue, 22 Aug 2006 09:21:25 -0700 (PDT) Message-ID: <92c950310608220921j5e337404j98c437aa59e9fb39@mail.gmail.com> Date: Tue, 22 Aug 2006 21:51:25 +0530 From: "Glen Kent" To: "Manav Bhatia" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: skh@nexthop.com, idr@ietf.org, Paul Jakma , "Joel M. Halpern" , Yakov Rekhter X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I support this. On 8/22/06, Manav Bhatia wrote: > Hi, > > The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt addresses > all of the concerns and suggestions that were given in the past IETFs and > the mailing list and we believe its in a reasonable form to be progressed > further in the WG. > > The proposal is compatible with IPv6 support, MPLS label advertisement, and > BGP multi-protocol support. > > > We would like to ask for the working group status for this document, so that > the working group may determine what revisions it wishes to make. > > Thanks, > > Joel, Paul and Manav > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 12:44:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZLc-0005Y9-3k; Tue, 22 Aug 2006 12:43:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZLb-0005Y4-F9 for idr@ietf.org; Tue, 22 Aug 2006 12:43:27 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZLa-0000MJ-8p for idr@ietf.org; Tue, 22 Aug 2006 12:43:27 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id E27444F2B7; Tue, 22 Aug 2006 12:43:21 -0400 (EDT) Date: Tue, 22 Aug 2006 12:43:21 -0400 From: Jeffrey Haas To: Henk Uijterwaal Subject: Re: [Idr] 4byte ASN support in RFC4273 Message-ID: <20060822164321.GA3647@scc.mi.org> References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060822105158.03521e78@ripe.net> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: idr@ietf.org, asn32@ripe.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Tue, Aug 22, 2006 at 11:06:35AM +0200, Henk Uijterwaal wrote: > IDR List, > > RFC4273 says: > > bgpPathAttrASPAth OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (2..255)) > [...] > EAch AS is represented as a pair of octets according to the following > algorithm: > first-byte-of-pair = ASNumber / 256 > second-byte-of-pair = ASNumber & 255; > > And similar for bgp4PathAttrASPathSegment. > > Question: what will happen when 4byte ASN are deployed? Can I just > replace the Octet string by 4 octets (ASN/(265^3), ASN/(256^2), ASN/256, > ASN%255) (and assume that things will continue to work)? Or does this > need an update of the RFC? > > The same RFC says: > > bgpPeerRemoteAs OBJECT-TYPE > SYNTAX Integer32 (0...65535) > > Same question. Answer: New MIB needed. BGP MIBv2, as previously published, didn't get a lot of support from people due to excess complexity. At the request of the WG chairs, I've factored a lot of that complexity out. Unfortunately, I'm stuck on getting functional conformance statements for it. Once I have those compiling, I have several drafts to publish. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 16:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcZc-0006pk-FF; Tue, 22 Aug 2006 16:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcZb-0006pc-90 for idr@ietf.org; Tue, 22 Aug 2006 16:10:07 -0400 Received: from web60725.mail.yahoo.com ([209.73.178.213]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFcZW-0001Fo-Ne for idr@ietf.org; Tue, 22 Aug 2006 16:10:07 -0400 Received: (qmail 3143 invoked by uid 60001); 22 Aug 2006 20:09:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Z0qtBVaBimsWRngsdSN6vasE6svU/tyXtdd6svm8uSg4PSiku+5LlZUgd4D2o4R4Fab6R/eL4DxS4suv9yDEu2M8VVPyMf2uVuaxPSVXQ04FMNj+HcBdsAVQ66da8PiTEjMYi59guaNtV7xILUQJDUSeUH1jU+soze9EH9zc5TU= ; Message-ID: <20060822200947.3141.qmail@web60725.mail.yahoo.com> Received: from [125.22.38.236] by web60725.mail.yahoo.com via HTTP; Tue, 22 Aug 2006 13:09:47 PDT Date: Tue, 22 Aug 2006 13:09:47 -0700 (PDT) From: Tulip Rasputin Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt To: manav@riverstonenet.com, idr@ietf.org In-Reply-To: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: skh@nexthop.com, yakov@juniper.net, joel@stevecrocker.com, paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tulip Rasputin List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Its got my vote as i think there is a lot that we can explore with this. For one, we have only been suggesting kludges to fix the MED oscillation problem and i think this is the first real attempt to actually fix the problem in the protocol itself. Then it helps in the classical case where the route reflector has to choose one best route from the available equally valid choices. Best Regards, Tulip ----- Original Message ---- From: Manav Bhatia To: idr@ietf.org Cc: skh@nexthop.com; Yakov Rekhter ; Joel M. Halpern ; Paul Jakma Sent: Tuesday, August 22, 2006 6:46:12 PM Subject: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Hi, The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt addresses all of the concerns and suggestions that were given in the past IETFs and the mailing list and we believe its in a reasonable form to be progressed further in the WG. The proposal is compatible with IPv6 support, MPLS label advertisement, and BGP multi-protocol support. We would like to ask for the working group status for this document, so that the working group may determine what revisions it wishes to make. Thanks, Joel, Paul and Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 17:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdcp-0007kz-3K; Tue, 22 Aug 2006 17:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdco-0007ku-1C for idr@ietf.org; Tue, 22 Aug 2006 17:17:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdcj-0004wb-K4 for idr@ietf.org; Tue, 22 Aug 2006 17:17:30 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Aug 2006 14:17:25 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7MLHORD015665; Tue, 22 Aug 2006 14:17:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7MLHM1Y010496; Tue, 22 Aug 2006 14:17:24 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 14:17:22 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 14:17:21 -0700 Message-ID: <44EB7461.9090101@cisco.com> Date: Tue, 22 Aug 2006 14:17:21 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tulip Rasputin Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> In-Reply-To: <20060822200947.3141.qmail@web60725.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2006 21:17:21.0890 (UTC) FILETIME=[5B495420:01C6C630] DKIM-Signature: a=rsa-sha1; q=dns; l=2113; t=1156281445; x=1157145445; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3D1TvTQ4hEIHLcURaCM+jLeUnTslg=3D; b=SWC5NBxLwxZb7OPu0yUpAJgnwPy+8o/DJbaodvrMlSjsOhE/MKm9hDh7QZuq4OiytO6inBVY KhyOM44B7h6yNWGN4zSwtPV+A7KZ3VcMVIMnrpHqLNnzuY1Nwf2XtmQ5; Authentication-Results: sj-dkim-4.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: skh@nexthop.com, idr@ietf.org, joel@stevecrocker.com, manav@riverstonenet.com, yakov@juniper.net, paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Tulip: Your statement "this is the first real attempt to actually fix the problem in the protocol itself" got me interested :-) I am not sure if you are aware of the "add-path" draft (draft-walton-bgp-add-paths-05.txt) that proposes a protocol revision to advertise multiple paths in BGP. The protocol work in the draft was completed years ago. IMO the add-path proposal is more flexible, and has few changes to BGP and how it is operates. -- Enke Tulip Rasputin wrote: >Its got my vote as i think there is a lot that we can explore with this. For one, we have only been suggesting kludges to fix the MED oscillation problem and i think this is the first real attempt to actually fix the problem in the protocol itself. Then it helps in the classical case where the route reflector has to choose one best route from the available equally valid choices. > >Best Regards, > >Tulip > >----- Original Message ---- >From: Manav Bhatia >To: idr@ietf.org >Cc: skh@nexthop.com; Yakov Rekhter ; Joel M. Halpern ; Paul Jakma >Sent: Tuesday, August 22, 2006 6:46:12 PM >Subject: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt > > >Hi, > >The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt addresses >all of the concerns and suggestions that were given in the past IETFs and >the mailing list and we believe its in a reasonable form to be progressed >further in the WG. > >The proposal is compatible with IPv6 support, MPLS label advertisement, and >BGP multi-protocol support. > > >We would like to ask for the working group status for this document, so that >the working group may determine what revisions it wishes to make. > >Thanks, > >Joel, Paul and Manav > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 20:58:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFh3A-0007md-F5; Tue, 22 Aug 2006 20:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFh38-0007mY-UI for idr@ietf.org; Tue, 22 Aug 2006 20:56:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFh37-0001dq-ID for idr@ietf.org; Tue, 22 Aug 2006 20:56:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2006 17:56:53 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7N0uqqj007258; Tue, 22 Aug 2006 17:56:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7N0uqQV023643; Tue, 22 Aug 2006 17:56:52 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 17:56:52 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 17:56:52 -0700 Message-ID: <44EBA7D4.1080002@cisco.com> Date: Tue, 22 Aug 2006 17:56:52 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> In-Reply-To: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 00:56:52.0442 (UTC) FILETIME=[058C13A0:01C6C64F] DKIM-Signature: a=rsa-sha1; q=dns; l=2739; t=1156294613; x=1157158613; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=xS70uVOgfzSqU99TfFVmhtoYjZ9pRiln5tGoxuf7Q3RI8b10f+ztpOwnItHr9B2gzJRiP4hW AJiUhanRWQ3YDmlOx1wmVDpBKvxnSyEAvtbiqXgF+kD7dFZtGJiGcuqd; Authentication-Results: sj-dkim-2.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Manav: Manav Bhatia wrote: > Hi Enke, > >> (draft-walton-bgp-add-paths-05.txt) that proposes a protocol revision >> to advertise multiple paths in BGP. The protocol work in the draft >> was completed years ago. >> IMO the add-path proposal is more flexible, and has few changes to >> BGP and how it is operates. > > > I would be interested in knowing as to what makes you think that this > proposal is any less flexible? The add-path draft introduces a path identifier so that a path from a neighbor can be identified by (prefix, path identifier), and the implicit replacement/withdraw behavior (and thus the update efficiency) in BGP is maintained. The path identifier can be a neighbor-AS, or a router-id, or an opaque number suitable for a particular application. It is not clear to me how the implicit replacement/withdraw can be achieved with your proposal. -- Enke > > Manav > >> >> -- Enke >> >> Tulip Rasputin wrote: >> >>> Its got my vote as i think there is a lot that we can explore with >>> this. For one, we have only been suggesting kludges to fix the MED >>> oscillation problem and i think this is the first real attempt to >>> actually fix the problem in the protocol itself. Then it helps in >>> the classical case where the route reflector has to choose one best >>> route from the available equally valid choices. >>> Best Regards, >>> Tulip >>> >>> ----- Original Message ---- >>> From: Manav Bhatia >>> To: idr@ietf.org >>> Cc: skh@nexthop.com; Yakov Rekhter ; Joel M. >>> Halpern ; Paul Jakma >>> Sent: Tuesday, August 22, 2006 6:46:12 PM >>> Subject: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt >>> >>> >>> Hi, >>> >>> The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt >>> addresses all of the concerns and suggestions that were given in the >>> past IETFs and the mailing list and we believe its in a reasonable >>> form to be progressed further in the WG. >>> >>> The proposal is compatible with IPv6 support, MPLS label >>> advertisement, and BGP multi-protocol support. >>> >>> >>> We would like to ask for the working group status for this document, >>> so that the working group may determine what revisions it wishes to >>> make. >>> >>> Thanks, >>> >>> Joel, Paul and Manav >>> >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www1.ietf.org/mailman/listinfo/idr >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www1.ietf.org/mailman/listinfo/idr >>> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 21:04:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhAb-0002rH-8P; Tue, 22 Aug 2006 21:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhAZ-0002ph-LL for idr@ietf.org; Tue, 22 Aug 2006 21:04:35 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFhAY-0003fO-AI for idr@ietf.org; Tue, 22 Aug 2006 21:04:35 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id SAA08422; Tue, 22 Aug 2006 18:04:33 -0700 (PDT) Received: from manavLpt ([10.128.16.170]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 18:04:32 -0700 Message-ID: <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Enke Chen" References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Wed, 23 Aug 2006 06:34:29 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 23 Aug 2006 01:04:33.0337 (UTC) FILETIME=[18431290:01C6C650] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Enke, > > The add-path draft introduces a path identifier so that a path from a > neighbor can be identified by (prefix, path identifier), and the implicit > replacement/withdraw behavior (and thus the update efficiency) in BGP is > maintained. The path identifier can be a neighbor-AS, or a router-id, or > an opaque number suitable for a particular application. > > It is not clear to me how the implicit replacement/withdraw can be > achieved with your proposal. Simple. You look at the prefix and the nexthop to perform implicit withdraw as this tuple would always be uniquely learnt from each BGP speaker. Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 21:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhir-0008PF-SE; Tue, 22 Aug 2006 21:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFhir-0008Ov-2L for idr@ietf.org; Tue, 22 Aug 2006 21:40:01 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFhip-0003eB-L9 for idr@ietf.org; Tue, 22 Aug 2006 21:40:00 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7N1dt1Z039417; Tue, 22 Aug 2006 18:39:59 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7N1dog62530; Tue, 22 Aug 2006 18:39:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608230139.k7N1dog62530@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61720.1156297190.1@juniper.net> Date: Tue, 22 Aug 2006 18:39:50 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: skh@nexthop.com Subject: [Idr] draft-bhatia-bgp-multiple-next-hops-01.txt as an IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, We received a request to accept draft-bhatia-bgp-multiple-next-hops-01.txt as an IDR WG document. Please send comments to the list. The deadline for comments is September 6, 2006. Yakov. ------- Forwarded Message Date: Tue, 22 Aug 2006 18:46:12 +0530 From: "Manav Bhatia" To: cc: "Yakov Rekhter" , , "Joel M. Halpern" , "Paul Jakma" Subject: Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Hi, The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt addresses all of the concerns and suggestions that were given in the past IETFs and the mailing list and we believe its in a reasonable form to be progressed further in the WG. The proposal is compatible with IPv6 support, MPLS label advertisement, and BGP multi-protocol support. We would like to ask for the working group status for this document, so that the working group may determine what revisions it wishes to make. Thanks, Joel, Paul and Manav ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 22:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiM6-0000RL-0I; Tue, 22 Aug 2006 22:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiM3-0000RF-Vt for idr@ietf.org; Tue, 22 Aug 2006 22:20:31 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFiM2-00051m-Ei for idr@ietf.org; Tue, 22 Aug 2006 22:20:31 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F00CSQIW0QA@szxga03-in.huawei.com> for idr@ietf.org; Wed, 23 Aug 2006 10:28:48 +0800 (CST) Received: from M55527 ([10.111.12.134]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F00IY1IVZNH@szxga03-in.huawei.com> for idr@ietf.org; Wed, 23 Aug 2006 10:28:48 +0800 (CST) Date: Wed, 23 Aug 2006 10:18:21 +0800 From: Mach Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt To: Manav Bhatia , Enke Chen Message-id: <004b01c6c65a$67f65130$860c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Manav Please see inline. > Hi Enke, > >> >> The add-path draft introduces a path identifier so that a path from a >> neighbor can be identified by (prefix, path identifier), and the implicit >> replacement/withdraw behavior (and thus the update efficiency) in BGP is >> maintained. The path identifier can be a neighbor-AS, or a router-id, or >> an opaque number suitable for a particular application. >> >> It is not clear to me how the implicit replacement/withdraw can be >> achieved with your proposal. > > Simple. You look at the prefix and the nexthop to perform implicit withdraw > as this tuple would always be uniquely learnt from each BGP speaker. > So, how to carry the nexthop attribute , using MULTIPLE_HOP attribute or any other attribute? Could tell me the detailed procedure about implicit replacement/withdraw ? Your decription in section 3.5 is too simple, I also have same doubt as Enke Chen. Thanks, Mach > Manav > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 22:40:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFif2-00007a-7e; Tue, 22 Aug 2006 22:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFif0-00007V-MC for idr@ietf.org; Tue, 22 Aug 2006 22:40:06 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFiez-0007HA-Be for idr@ietf.org; Tue, 22 Aug 2006 22:40:06 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id TAA13067; Tue, 22 Aug 2006 19:40:04 -0700 (PDT) Received: from manavLpt ([10.128.16.155]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 19:40:00 -0700 Message-ID: <017201c6c65d$6b1d2c50$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Mach Chen" References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <004b01c6c65a$67f65130$860c6f0a@china.huawei.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Wed, 23 Aug 2006 08:09:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 23 Aug 2006 02:40:00.0899 (UTC) FILETIME=[6E27AD30:01C6C65D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Mach, > So, how to carry the nexthop attribute , using MULTIPLE_HOP attribute or > any other attribute? ^^^^^^^^^^^^^^^^^^ I am sorry I could not parse this. > > Could tell me the detailed procedure about implicit replacement/withdraw ? Try section 3.2 3.2 Withdrawal Procedures An UPDATE message which contains an IP address prefix in the WITHDRAWN ROUTES marks all the associated routes as being no longer available for use. An UPDATE message consisting of an IP address prefix in the NLRI field and only the NEXT_HOP attribute implicitly withdraws all the routes to that address prefix and replaces it with the one advertised by the NEXT_HOP. An UPDATE message which contains an IP address prefix in the WITHDRAWN ROUTES and the MULTIPLE_HOP attribute only removes the path associated with that next-hop. An UPDATE message announced with a MULTIPLE_HOP attribute for a given IP address prefix implicitly withdraws any previous route announced with the same next-hop. > > Your decription in section 3.5 is too simple, I also have same doubt as > Enke Chen. Let us know if its still unclear. We should be able to explain it to you with an aid of an example. Cheers, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 22:59:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiwY-0007F6-Pn; Tue, 22 Aug 2006 22:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFiwX-0007F1-1X for idr@ietf.org; Tue, 22 Aug 2006 22:58:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFiwW-00028f-WF for idr@ietf.org; Tue, 22 Aug 2006 22:58:13 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFiwU-0002W5-MB for idr@ietf.org; Tue, 22 Aug 2006 22:58:12 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19NuboMp+mCiZ+un2Xp0OkwI6UIJbPydsQ@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7N2vdnI002963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 03:57:51 +0100 Date: Wed, 23 Aug 2006 03:57:38 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EB7461.9090101@cisco.com> Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1713/Wed Aug 23 02:01:05 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -1.3 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: skh@nexthop.com, idr@ietf.org, joel@stevecrocker.com, yakov@juniper.net, Tulip Rasputin , manav@riverstonenet.com, paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Enke, On Tue, 22 Aug 2006, Enke Chen wrote: > I am not sure if you are aware of the "add-path" draft > (draft-walton-bgp-add-paths-05.txt) that proposes a protocol > revision to advertise multiple paths in BGP. FWIW this draft is a respin of draft-bhatia-ecmp-routes-in-bgp-00.txt, but sans detailed consideration of ECMP (which can build upon it). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Nothing will dispel enthusiasm like a small admission fee. -- Kim Hubbard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 22 23:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFjK5-000077-RL; Tue, 22 Aug 2006 23:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFjK3-00006z-Uj for idr@ietf.org; Tue, 22 Aug 2006 23:22:31 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFjK2-0004fb-6V for idr@ietf.org; Tue, 22 Aug 2006 23:22:31 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F001EWM5JHU@szxga02-in.huawei.com> for idr@ietf.org; Wed, 23 Aug 2006 11:39:19 +0800 (CST) Received: from M55527 ([10.111.12.134]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F005V4M5I6P@szxga02-in.huawei.com> for idr@ietf.org; Wed, 23 Aug 2006 11:39:19 +0800 (CST) Date: Wed, 23 Aug 2006 11:21:29 +0800 From: Mach Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt To: Manav Bhatia Message-id: <007401c6c663$39eeefa0$860c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <004b01c6c65a$67f65130$860c6f0a@china.huawei.com> <017201c6c65d$6b1d2c50$0201a8c0@rs.riverstonenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi manav, Please see below inline ----- Original Message ----- From: "Manav Bhatia" To: "Mach Chen" Cc: Sent: Wednesday, August 23, 2006 10:39 AM Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt > Hi Mach, > >> So, how to carry the nexthop attribute , using MULTIPLE_HOP attribute or >> any other attribute? > ^^^^^^^^^^^^^^^^^^ > I am sorry I could not parse this. > >> >> Could tell me the detailed procedure about implicit replacement/withdraw ? > > Try section 3.2 > > 3.2 Withdrawal Procedures > > An UPDATE message which contains an IP address prefix in the > WITHDRAWN ROUTES marks all the associated routes as being no longer > available for use. > > An UPDATE message consisting of an IP address prefix in the NLRI > field and only the NEXT_HOP attribute implicitly withdraws all the > routes to that address prefix and replaces it with the one advertised > by the NEXT_HOP. > > An UPDATE message which contains an IP address prefix in the > WITHDRAWN ROUTES and the MULTIPLE_HOP attribute only removes the path > associated with that next-hop. > > An UPDATE message announced with a MULTIPLE_HOP attribute for a given > IP address prefix implicitly withdraws any previous route announced > with the same next-hop. OK,but I want to know how to perform implicitly withdraw when partial nexthop attribute changed. > >> >> Your decription in section 3.5 is too simple, I also have same doubt as >> Enke Chen. > > Let us know if its still unclear. We should be able to explain it to you > with an aid of an example. > > Cheers, > Manav > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 00:15:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFk8L-0005TE-Pq; Wed, 23 Aug 2006 00:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFk8K-0005NX-9r for idr@ietf.org; Wed, 23 Aug 2006 00:14:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFgvU-0007Jk-CN for idr@ietf.org; Tue, 22 Aug 2006 20:49:00 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFgr1-0007y8-Ju for idr@ietf.org; Tue, 22 Aug 2006 20:44:25 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA07281; Tue, 22 Aug 2006 17:44:20 -0700 (PDT) Received: from manavLpt ([10.128.16.170]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 17:44:19 -0700 Message-ID: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Enke Chen" References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Wed, 23 Aug 2006 06:14:14 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 23 Aug 2006 00:44:19.0720 (UTC) FILETIME=[44E3D080:01C6C64D] X-Spam-Score: -2.1 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Enke, > (draft-walton-bgp-add-paths-05.txt) that proposes a protocol revision to > advertise multiple paths in BGP. The protocol work in the draft was > completed years ago. > IMO the add-path proposal is more flexible, and has few changes to BGP and > how it is operates. I would be interested in knowing as to what makes you think that this proposal is any less flexible? Manav > > -- Enke > > Tulip Rasputin wrote: > >>Its got my vote as i think there is a lot that we can explore with this. >>For one, we have only been suggesting kludges to fix the MED oscillation >>problem and i think this is the first real attempt to actually fix the >>problem in the protocol itself. Then it helps in the classical case where >>the route reflector has to choose one best route from the available >>equally valid choices. >> Best Regards, >> Tulip >> >>----- Original Message ---- >>From: Manav Bhatia >>To: idr@ietf.org >>Cc: skh@nexthop.com; Yakov Rekhter ; Joel M. Halpern >>; Paul Jakma >>Sent: Tuesday, August 22, 2006 6:46:12 PM >>Subject: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt >> >> >>Hi, >> >>The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt >>addresses all of the concerns and suggestions that were given in the past >>IETFs and the mailing list and we believe its in a reasonable form to be >>progressed further in the WG. >> >>The proposal is compatible with IPv6 support, MPLS label advertisement, >>and BGP multi-protocol support. >> >> >>We would like to ask for the working group status for this document, so >>that the working group may determine what revisions it wishes to make. >> >>Thanks, >> >>Joel, Paul and Manav >> >> >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www1.ietf.org/mailman/listinfo/idr >> _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 03:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnQt-0007dk-W1; Wed, 23 Aug 2006 03:45:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnQs-0007df-6r for idr@ietf.org; Wed, 23 Aug 2006 03:45:50 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFnQp-0005ll-Rb for idr@ietf.org; Wed, 23 Aug 2006 03:45:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2006 00:45:47 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7N7jlhk030596; Wed, 23 Aug 2006 00:45:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7N7jl1E022615; Wed, 23 Aug 2006 00:45:47 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 00:45:46 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 00:45:45 -0700 Message-ID: <44EC07A3.7000304@cisco.com> Date: Wed, 23 Aug 2006 00:45:39 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> In-Reply-To: <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 07:45:45.0564 (UTC) FILETIME=[246D69C0:01C6C688] DKIM-Signature: a=rsa-sha1; q=dns; l=2502; t=1156319147; x=1157183147; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=IEsfWvgYhCOXpawYbmUqkLiTpb34vjrR/dun/ePJcEahUIGUVXLozxk95qZiKvaskCH1VMxY l9Xvm0jVKzIWhtJ3tVPy6UvV93LfGu1b0NHFn7sI85nsef1E3hKug7ZU; Authentication-Results: sj-dkim-3.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Manav: Manav Bhatia wrote: > Hi Enke, > >> >> The add-path draft introduces a path identifier so that a path from a >> neighbor can be identified by (prefix, path identifier), and the >> implicit replacement/withdraw behavior (and thus the update >> efficiency) in BGP is maintained. The path identifier can be a >> neighbor-AS, or a router-id, or an opaque number suitable for a >> particular application. >> >> It is not clear to me how the implicit replacement/withdraw can be >> achieved with your proposal. > > > Simple. You look at the prefix and the nexthop to perform implicit > withdraw as this tuple would always be uniquely learnt from each BGP > speaker. Sorry I do not follow you, and I went back to your draft and got more confused. As you stated here, as well as in the draft, a path is identified by (prefix , nexthop-address) in your proposal. Then how can a path identified by (prefix, neighbor-As), or (prefix, router-id), or (prefix, opaque-number) be implicitly replaced/withdrawn by a mechanism that identifies a path by (prefix, nexthop-address)? Regarding the need for identifying a path by (prefix, neighbor_AS) or (prefix, route-id), I am not sure if you have read the companion draft of add-path (draft-walton-bgp-route-oscillation-stop-01.txt), which has expired unfortunately, but is still readily available on the Internet, for example: http://ietfreport.isoc.org/idref/draft-walton-bgp-route-oscillation-stop-01.txt Two approaches are presented in the draft to address the ibgp route oscillation: 1) advertise the available paths (equivalent to full ibgp mesh): in this case a path is identified by (prefix, router-id). 2) advertise the (neighboring-AS based) group bestpaths: in this case a path is identified by (prefix, neighboring-AS). They have different scaling properties, and a provider may choose to deploy one or another. In both cases, however, the nexthop addresses of the multiple paths being advertised would most likely be different. Since we are comparing the drafts, I think it is fair to ask this question: As the add-path draft has existed for a long time, and the spec is pretty simple, complete, fairly elegant (sure, relatively), I am wondering if you have spotted certain issues with it that can not be fixed, or if the solution proposed failed to address a particular problem that requires multiple paths? -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 03:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnV8-0000we-93; Wed, 23 Aug 2006 03:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnV7-0000wN-3L for idr@ietf.org; Wed, 23 Aug 2006 03:50:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFnV4-00071L-NQ for idr@ietf.org; Wed, 23 Aug 2006 03:50:13 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Aug 2006 00:50:10 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7N7oArp001406; Wed, 23 Aug 2006 00:50:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7N7oAQV025406; Wed, 23 Aug 2006 00:50:10 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 00:50:10 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 00:50:09 -0700 Message-ID: <44EC08B1.2080801@cisco.com> Date: Wed, 23 Aug 2006 00:50:09 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> In-Reply-To: <44EC07A3.7000304@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 07:50:09.0629 (UTC) FILETIME=[C1D288D0:01C6C688] DKIM-Signature: a=rsa-sha1; q=dns; l=2837; t=1156319410; x=1157183410; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=lLfVksVm6VZpfHc823Z7+ewgoJeg8aSxw/Hh1PHywMOjiu5VhzgUPTd4u5/K6AEaX0/z/mFE 7utZPeOGg2sWpdO4/DSXfxkC+ftEDkLmxbgWZZn0Y7wRUJ5c885l9wfO; Authentication-Results: sj-dkim-3.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Had a cut-n-paste error. Here is a correct pointer to the add-path application draft: http://ietfreport.isoc.org/all-ids/draft-walton-bgp-route-oscillation-stop-01.txt -- Enke Enke Chen wrote: > Hi, Manav: > > Manav Bhatia wrote: > >> Hi Enke, >> >>> >>> The add-path draft introduces a path identifier so that a path from >>> a neighbor can be identified by (prefix, path identifier), and the >>> implicit replacement/withdraw behavior (and thus the update >>> efficiency) in BGP is maintained. The path identifier can be a >>> neighbor-AS, or a router-id, or an opaque number suitable for a >>> particular application. >>> >>> It is not clear to me how the implicit replacement/withdraw can be >>> achieved with your proposal. >> >> >> >> Simple. You look at the prefix and the nexthop to perform implicit >> withdraw as this tuple would always be uniquely learnt from each BGP >> speaker. > > > > Sorry I do not follow you, and I went back to your draft and got more > confused. As you stated here, as well as in the draft, a path is > identified by (prefix , nexthop-address) in your proposal. Then how > can a path identified by (prefix, neighbor-As), or (prefix, > router-id), or (prefix, opaque-number) be implicitly > replaced/withdrawn by a mechanism that identifies a path by (prefix, > nexthop-address)? > > Regarding the need for identifying a path by (prefix, neighbor_AS) or > (prefix, route-id), I am not sure if you have read the companion > draft of add-path (draft-walton-bgp-route-oscillation-stop-01.txt), > which has expired unfortunately, but is still readily available on the > Internet, for example: > > > http://ietfreport.isoc.org/idref/draft-walton-bgp-route-oscillation-stop-01.txt > > > Two approaches are presented in the draft to address the ibgp route > oscillation: > > 1) advertise the available paths (equivalent to full ibgp mesh): > in this case a path is identified by (prefix, router-id). > 2) advertise the (neighboring-AS based) group bestpaths: in this > case a path is identified by (prefix, neighboring-AS). > > They have different scaling properties, and a provider may choose to > deploy one or another. In both cases, however, the nexthop addresses > of the multiple paths being advertised would most likely be different. > > Since we are comparing the drafts, I think it is fair to ask this > question: > > As the add-path draft has existed for a long time, and the spec is > pretty simple, complete, fairly elegant (sure, relatively), I am > wondering if you have spotted certain issues with it that can not be > fixed, or if the solution proposed failed to address a particular > problem that requires multiple paths? > > -- Enke > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 04:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnnO-0008Su-Mk; Wed, 23 Aug 2006 04:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnnN-0008Sp-NE for idr@ietf.org; Wed, 23 Aug 2006 04:09:05 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFnnM-0002fO-6Q for idr@ietf.org; Wed, 23 Aug 2006 04:09:05 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA02443; Wed, 23 Aug 2006 01:08:58 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 13:38:56 +0530 From: "Manav Bhatia" To: "'Mach Chen'" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Wed, 23 Aug 2006 13:38:54 +0530 Message-ID: <00ef01c6c68b$60915990$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbGY1xYIU5cKqB7QrmNjJYMYxCq5wAJlN/g In-Reply-To: <007401c6c663$39eeefa0$860c6f0a@china.huawei.com> X-OriginalArrivalTime: 23 Aug 2006 08:08:56.0812 (UTC) FILETIME=[61AD02C0:01C6C68B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Mach, >> An UPDATE message announced with a MULTIPLE_HOP attribute >for a given >> IP address prefix implicitly withdraws any previous route announced >> with the same next-hop. > >OK,but I want to know how to perform implicitly withdraw when >partial nexthop attribute changed. > Assume A has 3 routes to X (with next-hops N1, N2 and N3) that it wants to announce to B. A does this by sending the following UPDATE messages to B: UPDATE: feasible nlri X, next_hop N1, UPDATE: feasible nlri X, multiple_hop N2, UPDATE: feasible nlri X, multiple_hop N3, Case I: Some path attributes change for the route associated with next-hop N2 and it wants to replace the new route with the earlier announcement. A sends the following UPDATE message: UPDATE: feasible nlri X, multiple_hop N2, B upon receiving this message searches its RIB for the route associated with the tuple . If it doesn't find a route, then it appends this in its RIB. In this case, it finds the route that it had received earlier from A and considers this as an implicit withdrawal. Case II: A wants to selectively remove the route associated with the next_hop N2. A sends the following UPDATE message: UPDATE: unfeasible nlri X, multiple_next_hop N2 Hope this helps. Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 08:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrN2-0006U6-Ha; Wed, 23 Aug 2006 07:58:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFrN1-0006U1-Qt for idr@ietf.org; Wed, 23 Aug 2006 07:58:07 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFrN0-0001zJ-FR for idr@ietf.org; Wed, 23 Aug 2006 07:58:07 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GFrMx-0000o4-QO; Wed, 23 Aug 2006 07:58:04 -0400 Message-Id: <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 23 Aug 2006 07:58:02 -0400 To: Enke Chen From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EC07A3.7000304@cisco.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112022562ed0e0c6f31f5b0a0799b003fe6cdfe6209a9096b523350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Enke, I have real trouble with your characterization of your draft. You claim it is simple and elegant. From where I sit, it introduces a new identifier that must be shared between the routers. That identifier has to be assigned and managed by the advertising router in such a way that it is unique for each path that needs advertised (under all possible circumstances). But it has to be used by the receiver no matter how the sender has chosen to allocate / create it. As such, if the two happen to have the same implementation view they may find it simple. But it is quite dependent upon that implementation. While our draft makes use of information that was already being exchanged to provide the necessary disambiguation. I would argue that such is in fact both simpler and more elegant. At the same time, your claim of greater flexibility is in fact not backed up by need. We previously had support for advertising paths with different attributes but the same NLRI and the same next-hop. In discussion with folks we realized that there was no actual use case where you need the differentiation. Either the advertiser is in the path (next-hop self) in which case preserving the paths does not add information, even for the route oscillation case, or the advertiser is preserving the next-hop information in which case the next hops provide the needed differentiation. Thus, using the next-hop as an added differentiator provides exactly the flexibility needed by the problem, and is much simpler, more amenable to variations in implementations strategies, and more robust. Yours, Joel M. Halpern At 03:45 AM 8/23/2006, Enke Chen wrote: >Hi, Manav: > >Manav Bhatia wrote: > >>Hi Enke, >> >>> >>>The add-path draft introduces a path identifier so that a path >>>from a neighbor can be identified by (prefix, path identifier), >>>and the implicit replacement/withdraw behavior (and thus the >>>update efficiency) in BGP is maintained. The path identifier can >>>be a neighbor-AS, or a router-id, or an opaque number suitable for >>>a particular application. >>> >>>It is not clear to me how the implicit replacement/withdraw can be >>>achieved with your proposal. >> >> >>Simple. You look at the prefix and the nexthop to perform implicit >>withdraw as this tuple would always be uniquely learnt from each BGP speaker. > > >Sorry I do not follow you, and I went back to your draft and got >more confused. As you stated here, as well as in the draft, a >path is identified by (prefix , nexthop-address) in your >proposal. Then how can a path identified by (prefix, neighbor-As), >or (prefix, router-id), or (prefix, opaque-number) be implicitly >replaced/withdrawn by a mechanism that identifies a path by (prefix, >nexthop-address)? > >Regarding the need for identifying a path by (prefix, neighbor_AS) >or (prefix, route-id), I am not sure if you have read the companion >draft of add-path (draft-walton-bgp-route-oscillation-stop-01.txt), >which has expired unfortunately, but is still readily available on >the Internet, for example: > > >http://ietfreport.isoc.org/idref/draft-walton-bgp-route-oscillation-stop-01.txt > > >Two approaches are presented in the draft to address the ibgp route >oscillation: > > 1) advertise the available paths (equivalent to full ibgp > mesh): in this case a path is identified by (prefix, router-id). > 2) advertise the (neighboring-AS based) group bestpaths: in > this case a path is identified by (prefix, neighboring-AS). > >They have different scaling properties, and a provider may choose to >deploy one or another. In both cases, however, the nexthop addresses >of the multiple paths being advertised would most likely be different. > >Since we are comparing the drafts, I think it is fair to ask this question: > > As the add-path draft has existed for a long time, and the spec > is pretty simple, complete, fairly elegant (sure, relatively), I am > wondering if you have spotted certain issues with it that can not > be fixed, or if the solution proposed failed to address a > particular problem that requires multiple paths? > >-- Enke > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 10:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtIe-0005Ek-NL; Wed, 23 Aug 2006 10:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtId-0005Cu-0J for idr@ietf.org; Wed, 23 Aug 2006 10:01:43 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtIc-0000a8-2a for idr@ietf.org; Wed, 23 Aug 2006 10:01:42 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19Noe5JUaOqRmjEDx6ZSvWouTj6+uaLJEg@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7NE1GT1019282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 15:01:28 +0100 Date: Wed, 23 Aug 2006 15:01:16 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EBA7D4.1080002@cisco.com> Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1715/Wed Aug 23 09:25:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: "Joel M. Halpern" , Manav Bhatia , Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Enke, On Tue, 22 Aug 2006, Enke Chen wrote: > The add-path draft introduces a path identifier so that a path from > a neighbor can be identified by (prefix, path identifier), and the > implicit replacement/withdraw behavior (and thus the update > efficiency) in BGP is maintained. The path identifier can be a > neighbor-AS, or a router-id, or an opaque number suitable for a > particular application. We[1] considered that approach very carefully. It was not clear at all to us what this identifier should be from the draft. The simple approach, it seemed to us, would be to derive the Add-Path-ID in some way from the identity of the speaker the path was learnt from. This approach would work fine for route-reflectors/servers, where only a single central speaker is propogating additional paths. Such simple choice of Add-Path-ID does not though, as far as we can tell, work for propogating multiple paths further than that (e.g. between two RR or RSes, or in potential future ECMP applications). The next-hop of a path though would work. The combination of (NLRI,next-hop) serves as a natural extension of path-identity between any two speakers, we feel; reasonably stable, can be determined without reference to other paths for the NRLI, etc.. If the next-hop is a suitable additional identifier, then there is no need to encode it seperately (as add-path does). A list of next-hops would suffice (as it does for the NLRI). This also allows announcements which differ only by (NLRI,next-hop) to be bunched together into one UPDATE, where the add-path approach must send an UPDATE with full path-attributes per NRLI:Add-Path-ID. It does mean that if the next-hop of a path changes either the (NRLI,next-hop) must be withdrawn and re-announced (with all attributes) again (two UPDATEs), or all (NLRI,nexthop)'s must be implicitely withdrawn+reannounced in full (would be better, but only if it can be done in one UPDATE). This could be avoided by adding some more state with each nexthop to allow implicit withdrawals of specific (NLRI,nexthop) tuples, but we felt this would be optimising for an uncommon case at the expense of the common case and complexity. In summary: - The fundamental difference is that Add-Path appears to leave the identifier as a local issue (an operational one even?), where the draft of this subject explicitely uses the next-hop. - We think next-hop is the only determinable additional path-identifier, and we see only problems in leaving the determination of this additional identifier as a local issue. The remaining differences are not fundamental, but consequential of mechanism (seperate path-id versus "list of nexthops" approach): - Add-path can implicitely withdraw+update a path, but can not bunch paths which differ only by next-hop into one UPDATE. - multiple-nexthop can implicitely withdraw all paths for an NLRI, it can implicitely withdraw a (NLRI,nexthop) as long as the nexthop remains the same. However, it can not implicitely withdraw a (NRLI,nexthop) if the nexthop changes. An explicit withdraw of the (NLRI,nexthop) and reannouncement of that particular path would be the common case. Note that as these are considered different paths (different (NLRI,nexthop) tuples), one can /first/ announce the updated (NLRI,nexthop) /before/ withdrawing the old (NLRI,nexthop). > It is not clear to me how the implicit replacement/withdraw can be achieved > with your proposal. Presence or absence of NEXT_HOP signals whether outstanding announcements of the path are withdrawn or not. Additionally, next-hops can be individually withdrawn by an UPDATE with only unfeasible NRLIs (traditional or MP_UNREACH) and the MULTIPLE_NEXT_HOP attribute. I.e.: - UPDATE with NEXT_HOP: -> implicit withdrawal of all paths for the NLRI -> one or more paths announced for: - (NRLI,NEXT_HOP) - expansion of (NLRI,) - feasible routes without NEXT_HOP: -> no general implicit withdrawal -> additional paths for (NLRI,) -> implicit withdrawal for specific (NLRI,nexthop) - unfeasible routes with only the MULTIPLE_NEXT_HOP attribute: -> withdrawal of paths in expansion of (NLRI,) 1. Hopefully if I misrepresent the other authors they will correct me. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Farnsworth: Oh my God!! Fry: What is it? Farnsworth: It's..It's...It's my new pager! _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 10:14:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtTt-000139-0j; Wed, 23 Aug 2006 10:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtTr-000133-QW for idr@ietf.org; Wed, 23 Aug 2006 10:13:19 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtTq-0003LR-6W for idr@ietf.org; Wed, 23 Aug 2006 10:13:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2006 07:13:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NEDFPP014362; Wed, 23 Aug 2006 07:13:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7NEDF1E026984; Wed, 23 Aug 2006 07:13:15 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 07:13:15 -0700 Received: from [10.21.81.227] ([10.21.81.227]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 07:13:14 -0700 Message-ID: <44EC6277.8090000@cisco.com> Date: Wed, 23 Aug 2006 07:13:11 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 14:13:14.0832 (UTC) FILETIME=[46122D00:01C6C6BE] DKIM-Signature: a=rsa-sha1; q=dns; l=5039; t=1156342395; x=1157206395; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DFMt196C98OMaGny/tdknCAVss/0=3D; b=di/DZ5JmteudxmK3SdUBqx85lRejEdOmAaaW6HHFXVw84BcSnP+2IqOT05qE4Tw70IZVloZ+ PPOxAp75i16eZ51XeHZ7RvkdMikWVxzKIRfjUAG3MIJfgSFKcVOo+mim; Authentication-Results: sj-dkim-1.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: idr@ietf.org, paul@clubi.ie X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joel, Paul I am looking at the version -01 and can't find any encoding how are you proposing to send multiple vpnv4/v6 paths each with different next hop and a different VPN labels. Can you clarify ? And operationally this is common request for SPs providing same RD across VPN type of configurations or in few scenarios of inter-as topologies. Cheers, R. > Enke, I have real trouble with your characterization of your draft. > You claim it is simple and elegant. > From where I sit, it introduces a new identifier that must be shared > between the routers. That identifier has to be assigned and managed by > the advertising router in such a way that it is unique for each path > that needs advertised (under all possible circumstances). But it has to > be used by the receiver no matter how the sender has chosen to allocate > / create it. As such, if the two happen to have the same implementation > view they may find it simple. But it is quite dependent upon that > implementation. > While our draft makes use of information that was already being > exchanged to provide the necessary disambiguation. I would argue that > such is in fact both simpler and more elegant. > > At the same time, your claim of greater flexibility is in fact not > backed up by need. We previously had support for advertising paths with > different attributes but the same NLRI and the same next-hop. In > discussion with folks we realized that there was no actual use case > where you need the differentiation. Either the advertiser is in the > path (next-hop self) in which case preserving the paths does not add > information, even for the route oscillation case, or the advertiser is > preserving the next-hop information in which case the next hops provide > the needed differentiation. Thus, using the next-hop as an added > differentiator provides exactly the flexibility needed by the problem, > and is much simpler, more amenable to variations in implementations > strategies, and more robust. > > Yours, > Joel M. Halpern > > At 03:45 AM 8/23/2006, Enke Chen wrote: >> Hi, Manav: >> >> Manav Bhatia wrote: >> >>> Hi Enke, >>> >>>> >>>> The add-path draft introduces a path identifier so that a path from >>>> a neighbor can be identified by (prefix, path identifier), and the >>>> implicit replacement/withdraw behavior (and thus the update >>>> efficiency) in BGP is maintained. The path identifier can be a >>>> neighbor-AS, or a router-id, or an opaque number suitable for a >>>> particular application. >>>> >>>> It is not clear to me how the implicit replacement/withdraw can be >>>> achieved with your proposal. >>> >>> >>> Simple. You look at the prefix and the nexthop to perform implicit >>> withdraw as this tuple would always be uniquely learnt from each BGP >>> speaker. >> >> >> Sorry I do not follow you, and I went back to your draft and got more >> confused. As you stated here, as well as in the draft, a path is >> identified by (prefix , nexthop-address) in your proposal. Then how >> can a path identified by (prefix, neighbor-As), or (prefix, >> router-id), or (prefix, opaque-number) be implicitly >> replaced/withdrawn by a mechanism that identifies a path by (prefix, >> nexthop-address)? >> >> Regarding the need for identifying a path by (prefix, neighbor_AS) or >> (prefix, route-id), I am not sure if you have read the companion >> draft of add-path (draft-walton-bgp-route-oscillation-stop-01.txt), >> which has expired unfortunately, but is still readily available on the >> Internet, for example: >> >> >> http://ietfreport.isoc.org/idref/draft-walton-bgp-route-oscillation-stop-01.txt >> >> >> Two approaches are presented in the draft to address the ibgp route >> oscillation: >> >> 1) advertise the available paths (equivalent to full ibgp mesh): >> in this case a path is identified by (prefix, router-id). >> 2) advertise the (neighboring-AS based) group bestpaths: in this >> case a path is identified by (prefix, neighboring-AS). >> >> They have different scaling properties, and a provider may choose to >> deploy one or another. In both cases, however, the nexthop addresses >> of the multiple paths being advertised would most likely be different. >> >> Since we are comparing the drafts, I think it is fair to ask this >> question: >> >> As the add-path draft has existed for a long time, and the spec is >> pretty simple, complete, fairly elegant (sure, relatively), I am >> wondering if you have spotted certain issues with it that can not be >> fixed, or if the solution proposed failed to address a particular >> problem that requires multiple paths? >> >> -- Enke >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 10:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFu53-0007kk-Es; Wed, 23 Aug 2006 10:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFu52-0007kZ-Vc for idr@ietf.org; Wed, 23 Aug 2006 10:51:44 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFu52-0004xY-Ap for idr@ietf.org; Wed, 23 Aug 2006 10:51:44 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/4iudf6S6ATTJwbK5r5L0+BYfZBlPg0/k@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7NEpRbq020095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 15:51:39 +0100 Date: Wed, 23 Aug 2006 15:51:26 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Robert Raszuk Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EC6277.8090000@cisco.com> Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1715/Wed Aug 23 09:25:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Joel M. Halpern" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Wed, 23 Aug 2006, Robert Raszuk wrote: > Joel, Paul > > I am looking at the version -01 and can't find any encoding how are you > proposing to send multiple vpnv4/v6 paths each with different next hop > and a different VPN labels. > > Can you clarify ? The label is encoded with the NLRI according to RFC3107. This draft extends the identity of a path to: (NLRI, next-hop) That the NLRI can be decomposed to (prefix,label) is of no interest, it is an opaque identity as far as this draft is concerned. So for say: ( (P, label1), N1) ( (P, label2), N2) . . ( (P, labeln), Nn) would be advertised as: UPDATE: feasible NLRI: (P,label1), NEXT_HOP: N1 UPDATE: feasible NLRI: (P,label2), MULTIPLE_NEXT_HOP: N2 . . UPDATE: feasible NLRI: (P,labeln), MULTIPLE_NEXT_HOP: Nn If are identical, this draft can not though bunch the UPDATEs together (it would be ambigious which nexthops were associated with which NLRI obviously). A seperate UPDATE is needed for each distinct NLRI. NB: Read "NEXT_HOP or next-hop from MP_REACH_NLRI, whichever is appropriate" for any use of NEXT_HOP. I.e. I refer to the logical next-hop, be it from the traditional NEXT_HOP or from MP extensions. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 11:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFusk-0007Zm-PT; Wed, 23 Aug 2006 11:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFusi-0007Zf-Py for idr@ietf.org; Wed, 23 Aug 2006 11:43:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFush-000646-Dc for idr@ietf.org; Wed, 23 Aug 2006 11:43:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2006 08:43:03 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NFh2Us020556; Wed, 23 Aug 2006 08:43:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7NFh21E025116; Wed, 23 Aug 2006 08:43:02 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 08:43:02 -0700 Received: from [171.70.208.36] ([171.70.208.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 08:43:02 -0700 Message-ID: <44EC7783.6060405@cisco.com> Date: Wed, 23 Aug 2006 08:42:59 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 15:43:02.0262 (UTC) FILETIME=[D13AC160:01C6C6CA] DKIM-Signature: a=rsa-sha1; q=dns; l=2434; t=1156347782; x=1157211782; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DFMt196C98OMaGny/tdknCAVss/0=3D; b=KnUr39/N5NE3Vs+IRPgEB/7yho12HARuAalo3g7Y8NKWkrcxLMuXGdZ4jozIzrt15OhNWkJJ LFKfPkHUKIMN19L/cKrtEU5skvDSSglUuOFAHxVNaICWhV4WBVDjWScI; Authentication-Results: sj-dkim-1.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Joel M. Halpern" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Paul, I am not talking about RFC3107 but RFC4364. Yes in both the label is encoded in the NLRI, but meaning of the VPN label can not be decoupled from the next hop information who advertised it. If you send as you propose in separate updates this is implicit withdraw in most implementations I am aware so I don't see the multipath in action. In general I think your draft may work well for IPv4/v6 unicast address family. I don't think that it works well for any other address families already proposed in this WG. Moreover I don't think it is flexible enough to offer requested functionality for new AFI/SAFIs coming soon. In many cases of new SAFIs next hop is irrelevant what matters is NLRI + neighbor for example. IMHO this is premature to accept this as WG document. Cheers, R. PS. The stated issue with add-path's drawback to require uniqe identifier to be generated by BGP speaker is not IMHO at all a problem. > On Wed, 23 Aug 2006, Robert Raszuk wrote: > >> Joel, Paul >> >> I am looking at the version -01 and can't find any encoding how are you >> proposing to send multiple vpnv4/v6 paths each with different next hop >> and a different VPN labels. >> >> Can you clarify ? > > The label is encoded with the NLRI according to RFC3107. This draft > extends the identity of a path to: > > (NLRI, next-hop) > > That the NLRI can be decomposed to (prefix,label) is of no interest, it > is an opaque identity as far as this draft is concerned. > > So for say: > > ( (P, label1), N1) > ( (P, label2), N2) > . > . > ( (P, labeln), Nn) > > would be advertised as: > > UPDATE: > feasible NLRI: (P,label1), > NEXT_HOP: N1 > > UPDATE: > feasible NLRI: (P,label2), > MULTIPLE_NEXT_HOP: N2 > > . > . > UPDATE: > feasible NLRI: (P,labeln), > MULTIPLE_NEXT_HOP: Nn > > > If are identical, this draft can not though bunch the > UPDATEs together (it would be ambigious which nexthops were associated > with which NLRI obviously). > > A seperate UPDATE is needed for each distinct NLRI. > > NB: Read "NEXT_HOP or next-hop from MP_REACH_NLRI, whichever is > appropriate" for any use of NEXT_HOP. I.e. I refer to the logical > next-hop, be it from the traditional NEXT_HOP or from MP > extensions. > > regards, _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 12:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvS8-0007sl-Gz; Wed, 23 Aug 2006 12:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvS7-0007sg-AN for idr@ietf.org; Wed, 23 Aug 2006 12:19:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvS5-0002u3-0J for idr@ietf.org; Wed, 23 Aug 2006 12:19:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2006 08:59:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,161,1154934000"; d="scan'208"; a="37672281:sNHT24551584" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NFxO4J004498; Wed, 23 Aug 2006 11:59:24 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7NFxOuI027561; Wed, 23 Aug 2006 11:59:24 -0400 (EDT) To: tony.li@tony.li Subject: Re: [Idr] address family of next hop In-Reply-To: Message from "Tony Li" of "Mon, 21 Aug 2006 14:45:55 PDT." <002801c6c56b$2e249600$9b01a8c0@tropos.com> Date: Wed, 23 Aug 2006 11:59:23 -0400 Message-ID: <16227.1156348763@cisco.com> From: Eric Rosen DKIM-Signature: a=rsa-sha1; q=dns; l=4283; t=1156348764; x=1157212764; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:Eric=20Rosen=20 |Subject:Re=3A=20[Idr]=20address=20family=20of=20next=20hop |To:tony.li@tony.li; X=v=3Dcisco.com=3B=20h=3DaTMk1ywckN/XQt+kKLGh6XkvYdY=3D; b=QSvDHhwZbmI+j5fVuOp/Woq0OKymjDiN/drdYNadLcTVA0KX0701JNJJFCT0GrYn1XgXlsBH DAdYENZ1yNftINvfmO68BP13H8k5MJEvwp4xMgiyEsXVMwohSVdTb4Zp; Authentication-Results: rtp-dkim-2.cisco.com; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: raszuk@cisco.com, 'Yakov Rekhter' , erosen@cisco.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org [changed the subject line to reflect the subject of discussion] Tony> In some implementations, the notion of a tunnel is presented to layer Tony> 3 protocols as an abstraction of an "interface". Eric> That's one possible implementation strategy, but certainly not the Eric> only one. Tony> True, but it's a common one, including brand C, J and the former brand Tony> P implementations. It is by no means true that all of those implementations always present tunnels as interfaces. Perhaps you're only thinking of GRE tunnels? Certainly I know of many cases where MPLS tunnels, IPsec tunnels, L2TP tunnels, and even layer 2 tunnels are not presented to their user layers via the interface abstraction. I also know of cases where tunnels were first imlemented one way and then had to be changed to the other way for various reasons. That is properly an implementation matter, and should not be dictated by the architecture. > If you want to have a fast Appletalk switching path that supports > tunneling, you end up caching an encaps string that is opaque to Appletalk Presumably the upper layer passes the next hop to the lower layer and gets back the opaque string. In other words, at least part of the "next hop resolution" requires you to get information from other layers. In any event, BGP is already capable of doing both v4 and v6 next hop resolution. > You don't need to modify Appletalk to carry IPv4 next hops. If Appletalk were expected to become a major protocol with worldwide scope, I am sure we would be talking about doing having Appletalk carrying IP next hops, and/or about having BGP carry Appletalk next hops. It's just that Appletalk is of so little consequence now that no one really wants to touch it. As such, it is not necessarily a good model for how we want to handle IPv4 and IPv6. Eric> Protocol-specific overlay models have numerous disadvantages. Tony> I agree completely! Why are you proposing one? Obviously there's some talking at cross-purposes going on, since I don't believe I have suggested any kind of overlay. The model I want to explore seems to me to be a rather straightforward one, and one which adheres closely to existing BGP practices. There are a number of different address families that BGP carries today, especially in the L3VPN/L2VPN world. But in most of these cases, the next hop still belongs to the IP address family, not to the address family of the NLRI. In many of these cases, the next hop can be either an IPv4 address or an IPv6 address, with only the length to distinguish v4 from v6. The expectation is that the next hop will be an IPv4 address when IPv4 is the infrastructure used to reach the next hop, but that it will be IPv6 if IPv6 is the infrastructure used to reach the next hop. (In some cases, the IP address may be encoded in a funny way so it looks like it belongs to another address family, but that is now generally regarded as a piece of silliness.) I think that when the NLRI is IPv4 or IPv6, the situation is really no different; when a BGP speaker's address appears in the next hop field, it should still be in the address family that it is using for its own communication, which is not necessarily the address family of the NLRI. If two BGP speakers are communicating over an IPv6 infrastructure, I think they should be able to have a single BGP session between them, and they should be able to use that session to exchange routes for IPv4, IPv6, and other address families. But the BGP session will be running over IPv6, and when a BGP speaker puts itself in as a next hop, it should use its v6 address. I believe this is a straightforward extrapolation of the current practice for the cases where NLRI is not IPv4 or IPv6. In fact, I would argue that it doesn't depart from traditional practice in pure IPv4 scenarios, because the next hop has always been in the address family of the IP infrastructure that is used for communication between the BGP speakers. It's merely a coincidence that the NLRI has been in that same family as well ;-) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 12:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvYq-0002Gp-2u; Wed, 23 Aug 2006 12:26:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvYn-0002Dd-Ty for idr@ietf.org; Wed, 23 Aug 2006 12:26:33 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvYm-0004fO-7s for idr@ietf.org; Wed, 23 Aug 2006 12:26:33 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19iNalFwrXF1CxVLfMfNKniEft39HChcLs@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7NGQGcb022656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 17:26:28 +0100 Date: Wed, 23 Aug 2006 17:26:16 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Jeffrey Haas Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <20060823155632.GB13706@scc.mi.org> Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1715/Wed Aug 23 09:25:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Robert Raszuk , "Joel M. Halpern" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Wed, 23 Aug 2006, Jeffrey Haas wrote: > If I might ask the authors, is this a fair summary of the mechanism? Almost: The implicit withdrawal is dependent on presence or absence of the existing next-hop attribute (NEXT_HOP or MP_REACH_NLRI as appropriate), not on the new attribute. Implicit withdrawal is unchanged from normal BGP if the normal NEXT_HOP/MP_REACH_NLRI next-hop is present. The Multiple-nexthop attribute is essentially additive to existing paths for the NLRI, for UPDATES with feasible routes. Multiple-nexthop acts as a selector for withdrawal for an UPDATE with only unfeasible routes and that attribute. > 1. When the multiple nexthop attribute is present, it suppresses > the normal implicit withdrawal behavior of BGP. 1. When the normal nexthop attribute (NEXT_HOP or MP_REACH_NLRI) is present, normal implicit withdrawal behavior of BGP remains - all prior announcements of paths for the NLRI are implicitely withdrawn. The UPDATE replaces all existing paths for the NLRI with the paths of identities (NLRI,next-hop) as given by the 'normal' next-hop attribute and those nexthops in the MULTIPLE_NEXT_HOP, if that attribute is present. (with path attributes of each path equivalent to the remaining path attributes given in the UPDATE obviously) > 2. When the multiple nexthop is absent, it implicitly withdraws all > previously advertised routes matching that prefix and replaces > it with the single route matching the advertised prefix. 2. When the normal nexthop (NEXT_HOP or MP equivalent) attribute is absent, presuming there are feasible routes, it suppresses the normal implicit withdrawal behavior of BGP. The paths with identity of (NLRI,next-hop), as given in the Multiple-Nexthop attribute are added to RIB. No implicit withdrawal of paths of the NLRI is needed, other than for any /specific/ (NLRI,nexthop) paths already received. > 3. Similarly, if you're missing the multiple nexthop attribute, a withdraw > removes all routes matching that prefix. Yep. > 4. A withdraw with the multiple nexthop attribute withdraws only routes > matching those nexthops. Yep. > (Note that I consider 4 problematic. That can be discussed later if > my summary is correct.) Please do. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Don't take life seriously, you'll never get out alive. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 12:32:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvdU-0006BX-CJ; Wed, 23 Aug 2006 12:31:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvdT-0006BR-4d for idr@ietf.org; Wed, 23 Aug 2006 12:31:23 -0400 Received: from nz-out-0102.google.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvdP-0005s5-U2 for idr@ietf.org; Wed, 23 Aug 2006 12:31:23 -0400 Received: by nz-out-0102.google.com with SMTP id q3so134015nzb for ; Wed, 23 Aug 2006 09:31:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WPRS2CyBsTFQqvaEZ75jFiaHrj2oCfc5b18y7fkNPM0Pocas3oprcj37b3e/KfgV/r2vRPhB+/ena1v/KsTMWfmoo8jFZt6idRwUfvCmY+lbFuJbVWGfCNMUbpChl6KoPdV7kZz+Usaacvw8JKqgcVYAs8jGDFi5Ppk+V5XpO4k= Received: by 10.65.119.14 with SMTP id w14mr699316qbm; Wed, 23 Aug 2006 09:31:09 -0700 (PDT) Received: by 10.65.163.7 with HTTP; Wed, 23 Aug 2006 09:31:06 -0700 (PDT) Message-ID: <92c950310608230931k7d727855u1dbadd684edd2e66@mail.gmail.com> Date: Wed, 23 Aug 2006 22:01:09 +0530 From: "Glen Kent" To: raszuk@cisco.com Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EC7783.6060405@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Joel M. Halpern" , idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Robert, How does your proposal solve the problem of carrying the new AFIs and new SAFIs? When you do that would you also mind elucidating on what new AFIs and SAFIs we're discussing here? Are those proposals indiviudal submissions or have those been accepted in the WG? Glen On 8/23/06, Robert Raszuk wrote: > Paul, > > I am not talking about RFC3107 but RFC4364. Yes in both the label is > encoded in the NLRI, but meaning of the VPN label can not be decoupled > from the next hop information who advertised it. > > If you send as you propose in separate updates this is implicit withdraw > in most implementations I am aware so I don't see the multipath in action. > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 12:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvyY-0008Gy-8E; Wed, 23 Aug 2006 12:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvyX-0008Gt-1u for idr@ietf.org; Wed, 23 Aug 2006 12:53:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvyV-0001PZ-N8 for idr@ietf.org; Wed, 23 Aug 2006 12:53:09 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2006 09:52:52 -0700 X-IronPort-AV: i="4.08,161,1154934000"; d="scan'208"; a="313105376:sNHT5125057422" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NGqpht031986; Wed, 23 Aug 2006 09:52:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7NGqpw9010711; Wed, 23 Aug 2006 09:52:51 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:52:51 -0700 Received: from [171.70.208.36] ([171.70.208.36]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 09:52:50 -0700 Message-ID: <44EC87DF.6070805@cisco.com> Date: Wed, 23 Aug 2006 09:52:47 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Glen Kent Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <92c950310608230931k7d727855u1dbadd684edd2e66@mail.gmail.com> In-Reply-To: <92c950310608230931k7d727855u1dbadd684edd2e66@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2006 16:52:50.0625 (UTC) FILETIME=[91B03B10:01C6C6D4] DKIM-Signature: a=rsa-sha1; q=dns; l=1170; t=1156351971; x=1157215971; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DFMt196C98OMaGny/tdknCAVss/0=3D; b=fFj/ieEfp7zGgNLK/O8Y0t7lAixXk+X72T0NZ6SzJFAqolaxKuhrkxP0xK18OsYe3GYd9ydU nGP/htOB72Tmka7Wgz88ZMzSVpuQKGhSvTx6dvFs+Ky7xadvlUXIHh6q; Authentication-Results: sj-dkim-6.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "Joel M. Halpern" , idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Glen, > Robert, > > How does your proposal solve the problem of carrying the new AFIs and > new SAFIs? It does by defining a new element Path Identifier (rather then using one of the existing attributes to create a tuple) which may or may not be needed in new SAFIs. > When you do that would you also mind elucidating on what > new AFIs and SAFIs we're discussing here? While I gave the example of VPNv4 SAFI 128 what we are discussing is the attempt to come with mechanism for sending multiple paths in MP-BGP protocol in a simple and universal way for any AFI/SAFI combination. Cheers, R. > > Are those proposals indiviudal submissions or have those been accepted > in the WG? > > Glen > > On 8/23/06, Robert Raszuk wrote: >> Paul, >> >> I am not talking about RFC3107 but RFC4364. Yes in both the label is >> encoded in the NLRI, but meaning of the VPN label can not be decoupled >> from the next hop information who advertised it. >> >> If you send as you propose in separate updates this is implicit withdraw >> in most implementations I am aware so I don't see the multipath in >> action. >> > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 13:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwSl-00073z-MK; Wed, 23 Aug 2006 13:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwSj-00072s-L4 for idr@ietf.org; Wed, 23 Aug 2006 13:24:21 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwSi-00027r-Cr for idr@ietf.org; Wed, 23 Aug 2006 13:24:21 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 066CC4F2E1; Wed, 23 Aug 2006 13:24:16 -0400 (EDT) Date: Wed, 23 Aug 2006 13:24:16 -0400 From: Jeffrey Haas To: Paul Jakma Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060823172415.GF13706@scc.mi.org> References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Wed, Aug 23, 2006 at 05:26:16PM +0100, Paul Jakma wrote: > >If I might ask the authors, is this a fair summary of the mechanism? > > Almost: The [...] Thanks for the summary. My understanding wasn't off too much. Here are my concerns with the mechanism at a meta level: - By keying on NLRI, nexthop (rather than just NLRI), you are precluding the sending of multiple distinct paths that share the same nexthop. We'll likely want to be able to do this for ECMP. Additionally, without the ability to do this, I believe we wont be able to suppress some of the MED oscillation scenarios. - The mechanism doesn't give us a way to distinguish routes that are being sent to preclude oscillation, but may not be relevant to forwarding. More generally, routes need to be marked as to whether they are being used for forwarding or not. - The protocol mechanism has withdraws utilizing path attributes as part of their keying mechanism. While this is intentional, it's very much out of character with BGP. Primarily, this is because it preclude the mixing of simultaneous advertisement of feasible and unfeasible routes. I would suggest that the application components of this draft be split into a separate draft. Mixing the applications with the protocol descriptions makes it a bit more complicated than is warranted. Interaction of speakers of this mechanism with non-speakers needs to be documented, both within an AS (or confederation) and outside. This means that the ecmp/aggregation case needs to be documented. General note to the IDR community: We're spending a lot of time discussing the protocol mechanisms of passing around additional routes. I think we'd benefit from more discussion of the implications of doing this at a generic level before we start debating how to sling bits on the wire. The complex AS_PATH aggregation for ecmp that was a previous topic is a good example of the discussion I think we need. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 13:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwtw-0004A7-M3; Wed, 23 Aug 2006 13:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwtv-0004A2-Mi for idr@ietf.org; Wed, 23 Aug 2006 13:52:27 -0400 Received: from nz-out-0102.google.com ([64.233.162.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwtt-0007DP-Dy for idr@ietf.org; Wed, 23 Aug 2006 13:52:27 -0400 Received: by nz-out-0102.google.com with SMTP id q3so155519nzb for ; Wed, 23 Aug 2006 10:52:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RjfOy8PF/h6s9n4WE68zcVM+/aqvnFUVtotpU/hTdH+zYsEPlNXIOOAp3fGqpQEIkvZPTsmNooDv96es+2ip3R2M8Tifp915zbI8SbS460qC2pVvYR/i4U5xNUbMZ+afLC/EWZxlOZ6JJ9zwp/xGlm1662CkEcT6sd2qVd3z/a0= Received: by 10.64.184.14 with SMTP id h14mr801091qbf; Wed, 23 Aug 2006 10:52:24 -0700 (PDT) Received: by 10.65.163.7 with HTTP; Wed, 23 Aug 2006 10:52:24 -0700 (PDT) Message-ID: <92c950310608231052j492c13dej7d8ee7ea7fa5428b@mail.gmail.com> Date: Wed, 23 Aug 2006 23:22:24 +0530 From: "Glen Kent" To: idr@ietf.org Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <20060823172415.GF13706@scc.mi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I think we need to disassociate the reason why a BGP speaker may want to advertise multiple paths with how it can do so. IMO this is a cause of some confusion. We should treat this as only a mechanism for advertising multiple paths (atleast this is how i was reading this all this time) and let the other applications (ecmp, med oscillation, add your favorite application here .. ) define how they want to use this extension. For example, ecmp does not care how I advertise multiple paths to a remote peer. What it should care for is the as_path that i construct when i cross the ecmp capable domain to the non ecmp capable domain covers all the AS numbers. Similarly med oscillation draft needs to do it in its own way. I dont think these applications should really care if the underlying mechanism to advertise multiple routes is through multiple_hop or add-paths. So, lets focus on just one thing here: Is the mechanism to advertise multiple paths okay here? some comments inline .. > > Here are my concerns with the mechanism at a meta level: > > - By keying on NLRI, nexthop (rather than just NLRI), you are precluding > the sending of multiple distinct paths that share the same nexthop. > We'll likely want to be able to do this for ECMP. Additionally, an RR cant set next-hop-self so it would never send paths with same next-hop. You could send this in EBGP, but then for EBGP would you really send separate individual path attributes? > without the ability to do this, I believe we wont be able to suppress > some of the MED oscillation scenarios. > - The mechanism doesn't give us a way to distinguish routes that are []. > > I would suggest that the application components of this draft be > split into a separate draft. Mixing the applications with the > protocol descriptions makes it a bit more complicated than is warranted. I agree to this. > > Interaction of speakers of this mechanism with non-speakers needs > to be documented, both within an AS (or confederation) and outside. Again, if this draft is only going to talk about how a speaker needs to announce multiple paths then the only interaction with an uncapable peer would be that of not advertising anything! > This means that the ecmp/aggregation case needs to be documented. This is application specific and should find place in some other document. > General note to the IDR community: We're spending a lot of time discussing > the protocol mechanisms of passing around additional routes. I think Which is what the draft is all about. > we'd benefit from more discussion of the implications of doing this > at a generic level before we start debating how to sling bits on the wire. > The complex AS_PATH aggregation for ecmp that was a previous topic > is a good example of the discussion I think we need. Depends on which side you're on. I think a healthy discussion of how we can advertise multiple paths is important and required before we proceed on complex applications like ecmp .. I vividly remember a draft on ecmp and its repurcussions by the same authors. That could be a good starting point, if thats what you meant. Glen. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 13:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwxV-0006JJ-Bo; Wed, 23 Aug 2006 13:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwxU-0006Ff-6W for idr@ietf.org; Wed, 23 Aug 2006 13:56:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFujH-0004PA-QH for idr@ietf.org; Wed, 23 Aug 2006 11:33:19 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFuSL-00040n-PQ for idr@ietf.org; Wed, 23 Aug 2006 11:15:51 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 2CB004E80B; Wed, 23 Aug 2006 11:15:43 -0400 (EDT) Date: Wed, 23 Aug 2006 11:15:43 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060823151543.GA3089@scc.mi.org> References: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> User-Agent: Mutt/1.3.28i X-Spam-Score: -2.2 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav, I will admit to not having read this draft in detail enough to comment on whether your procedures are complete. I've read enough to believe that it looks like the proposed mechanism is sufficient to add and delete multiple paths. However, one key mechanism that isn't obvious when skimming this draft is how the active route (the path or paths actually being used) of the advertising speaker is denoted from other paths. Have I missed something? -- Jeff On Tue, Aug 22, 2006 at 06:46:12PM +0530, Manav Bhatia wrote: > Hi, > > The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt addresses > all of the concerns and suggestions that were given in the past IETFs and > the mailing list and we believe its in a reasonable form to be progressed > further in the WG. > > The proposal is compatible with IPv6 support, MPLS label advertisement, and > BGP multi-protocol support. > > > We would like to ask for the working group status for this document, so > that the working group may determine what revisions it wishes to make. > > Thanks, > > Joel, Paul and Manav > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 14:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxCm-0005Dk-Ua; Wed, 23 Aug 2006 14:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxCk-00059V-GB for idr@ietf.org; Wed, 23 Aug 2006 14:11:54 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxCj-0001uv-28 for idr@ietf.org; Wed, 23 Aug 2006 14:11:54 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id B36214E7E3; Wed, 23 Aug 2006 14:11:50 -0400 (EDT) Date: Wed, 23 Aug 2006 14:11:50 -0400 From: Jeffrey Haas To: Glen Kent Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060823181150.GG13706@scc.mi.org> References: <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> <92c950310608231052j492c13dej7d8ee7ea7fa5428b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92c950310608231052j492c13dej7d8ee7ea7fa5428b@mail.gmail.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Glen, On Wed, Aug 23, 2006 at 11:22:24PM +0530, Glen Kent wrote: > I think we need to disassociate the reason why a BGP speaker may want > to advertise multiple paths with how it can do so. Agreed. > So, lets focus on just one thing here: Is the mechanism to advertise > multiple paths okay here? I don't think so. I've documented two reasons I think the mechanism needs to address. Catching up on this thread made me go read the add-paths document. I think that mechanism is cleaner from a protocol standpoint. > an RR cant set next-hop-self so it would never send paths with same > next-hop. You could send this in EBGP, but then for EBGP would you > really send separate individual path attributes? Consider the case of confederation's setting next-hop-self at a confederation border. It is used, although not commonly. I also think precluding the mechanism between external bgp speakers is excessive - from a protocol standpoint, not an application standpoint. > Again, if this draft is only going to talk about how a speaker needs > to announce multiple paths then the only interaction with an uncapable > peer would be that of not advertising anything! Well, no. If you have multiple paths and are using some subset of those for forwarding, and that subset is > 1, what do you advertise to a speaker that can't receive more than one path? The answer to this question may be documented in an ecmp document. The protocol mechanism must support noting which paths are used in forwarding. (This is a concern in the add-paths document as well, IMO.) > >we'd benefit from more discussion of the implications of doing this > >at a generic level before we start debating how to sling bits on the wire. > >The complex AS_PATH aggregation for ecmp that was a previous topic > >is a good example of the discussion I think we need. > > Depends on which side you're on. I think a healthy discussion of how > we can advertise multiple paths is important and required before we > proceed on complex applications like ecmp .. > > I vividly remember a draft on ecmp and its repurcussions by the same > authors. That could be a good starting point, if thats what you meant. Passing around more than one path, regardless of mechanism, fundamentally changes a core component of BGP: route selection. Documenting protocol before behavior seems very much like putting the cart before the horse. As a specific example, I've suggested we need to flag routes that are used for forwarding. If the consensus is that this is required, do we put together yet another per-route-instance draft that covers this or simply put it into the mechanism that distributes the multiple routes? -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 14:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxRD-00040v-Ce; Wed, 23 Aug 2006 14:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxRC-00040B-Cp for idr@ietf.org; Wed, 23 Aug 2006 14:26:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFv9v-00008Y-Iq for idr@ietf.org; Wed, 23 Aug 2006 12:00:51 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFv5n-0004xf-D5 for idr@ietf.org; Wed, 23 Aug 2006 11:56:36 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id D38634E7F6; Wed, 23 Aug 2006 11:56:32 -0400 (EDT) Date: Wed, 23 Aug 2006 11:56:32 -0400 From: Jeffrey Haas To: Robert Raszuk Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060823155632.GB13706@scc.mi.org> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44EC7783.6060405@cisco.com> User-Agent: Mutt/1.3.28i X-Spam-Score: -2.3 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Joel M. Halpern" , idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Robert, On Wed, Aug 23, 2006 at 08:42:59AM -0700, Robert Raszuk wrote: > If you send as you propose in separate updates this is implicit withdraw > in most implementations I am aware so I don't see the multipath in action. I wont pretend to speak for the authors, nor speak for my preference in the encodings in this draft. However, the relevant bit of their draft: When advertising multiple paths which do not have identical path attributes, separate BGP UPDATE messages MUST be sent, each with a MULTIPLE_HOP attribute even if there is only one next-hop in each MULTIPLE_HOP attribute. Presence of MULTIPLE_HOP suppresses route replacement at the receiving end. If I might ask the authors, is this a fair summary of the mechanism? 1. When the multiple nexthop attribute is present, it suppresses the normal implicit withdrawal behavior of BGP. 2. When the multiple nexthop is absent, it implicitly withdraws all previously advertised routes matching that prefix and replaces it with the single route matching the advertised prefix. 3. Similarly, if you're missing the multiple nexthop attribute, a withdraw removes all routes matching that prefix. 4. A withdraw with the multiple nexthop attribute withdraws only routes matching those nexthops. (Note that I consider 4 problematic. That can be discussed later if my summary is correct.) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 15:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFy3l-0006Qh-Rt; Wed, 23 Aug 2006 15:06:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFy3k-0006Qc-87 for idr@ietf.org; Wed, 23 Aug 2006 15:06:40 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFy3i-0007ck-UY for idr@ietf.org; Wed, 23 Aug 2006 15:06:40 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 795C624159; Wed, 23 Aug 2006 21:06:38 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 4876C24184; Wed, 23 Aug 2006 21:06:38 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 0C4EE2F592; Wed, 23 Aug 2006 21:06:38 +0200 (CEST) Message-Id: <7.0.1.0.2.20060823180856.03548898@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 23 Aug 2006 18:11:11 +0200 To: Jeffrey Haas From: Henk Uijterwaal Subject: Re: [Idr] 4byte ASN support in RFC4273 In-Reply-To: <20060822164321.GA3647@scc.mi.org> References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> <20060822164321.GA3647@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -4.4 X-RIPE-Signature: c2c12311ff90f4f22bed45080d6a9404 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: idr@ietf.org, asn32@ripe.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Jeff, >Answer: New MIB needed. BGP MIBv2, as previously published, didn't >get a lot of support from people due to excess complexity. At >the request of the WG chairs, I've factored a lot of that complexity out. > >Unfortunately, I'm stuck on getting functional conformance statements >for it. Once I have those compiling, I have several drafts to publish. Are you planning to write this draft/MIB? I have several products using the current MIB and it'd really help if I could point maintainers to a new MIB and ask them to upgrade? I can even provide a list of things that need to be changed (but I'm no MIB expert, so I don't think I could write the MIB myself). Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 16:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFzMn-0004rP-KY; Wed, 23 Aug 2006 16:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFzMm-0004rI-7C for idr@ietf.org; Wed, 23 Aug 2006 16:30:24 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFzMi-00088U-VX for idr@ietf.org; Wed, 23 Aug 2006 16:30:24 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 914AB4E7E6; Wed, 23 Aug 2006 16:30:13 -0400 (EDT) Date: Wed, 23 Aug 2006 16:30:13 -0400 From: Jeffrey Haas To: Henk Uijterwaal Subject: Re: [Idr] 4byte ASN support in RFC4273 Message-ID: <20060823203013.GK13706@scc.mi.org> References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> <20060822164321.GA3647@scc.mi.org> <7.0.1.0.2.20060823180856.03548898@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060823180856.03548898@ripe.net> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org, asn32@ripe.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Henk, On Wed, Aug 23, 2006 at 06:11:11PM +0200, Henk Uijterwaal wrote: > Are you planning to write this draft/MIB? A version of this mib was proposed: draft-ietf-idr-bgp4-mib-v2-05 was the last version published. It didn't receive much support due to its complexity. I've factored the complex functionality out, removed configuration objects and am planning no a republish of the components within the next two weeks, work permitting. Your review would be greatly appreciated. > I have several products using > the current MIB and it'd really help if I could point maintainers to > a new MIB and ask them to upgrade? I can even provide a list of things > that need to be changed (but I'm no MIB expert, so I don't think I > could write the MIB myself). Inputs on the MIB features would be appreciated. Core features of the base mib include: - Support for multiple bgp instances - Support for multiple route instances - 4 byte as path support - ipv6 support - prefix counters - hooks for extension mibs + communities + extended-communities + confederations + route reflect + etc. Long term, this may also support other uses of bgp to transport non-ipv4/v6 nlri, but that isn't the focus of this work. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 17:13:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG01t-0005ah-Rb; Wed, 23 Aug 2006 17:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG01s-0005ac-9i for idr@ietf.org; Wed, 23 Aug 2006 17:12:52 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG01q-0005A9-HY for idr@ietf.org; Wed, 23 Aug 2006 17:12:52 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/8hjaZHxvCPWOp7ZRRXQH6qApG/PvcrIA@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7NLCXnT028148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 22:12:45 +0100 Date: Wed, 23 Aug 2006 22:12:33 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Robert Raszuk Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EC7783.6060405@cisco.com> Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1717/Wed Aug 23 17:19:54 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "Joel M. Halpern" , Inter-Domain Routing List , Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Wed, 23 Aug 2006, Robert Raszuk wrote: > I am not talking about RFC3107 but RFC4364. Ah apologies. Though, to the best of our knowledge, the approach in this draft works perfectly well with VPNv4. Why would it not? > Yes in both the label is encoded in the NLRI, but meaning of the > VPN label can not be decoupled from the next hop information who > advertised it. And the draft does not require it to be decoupled. > If you send as you propose in separate updates this is implicit > withdraw in most implementations I am aware so I don't see the > multipath in action. This is covered, see the sub-thread of Jeff's reply. > address families already proposed in this WG. Moreover I don't > think it is flexible enough to offer requested functionality for > new AFI/SAFIs coming soon. In many cases of new SAFIs next hop is > irrelevant what matters is NLRI + neighbor for example. Which would those be? If there is no notional equivalent to a next-hop, are these things even routes? - If not, why try to bend non-routing information into UPDATE messages? Use a different BGP message more suited to the purpose.. (I'm thinking particularly of some of the "Use BGP to exchange VPN /configuration/ information" proposals floated, I can't remember whether or not they wanted to use UPDATE). - If yes, what kind of route does not have a notional 'target' (ie nexthop) for a destination? E.g. "NLRI + neighbour" sounds like the VPN-config stuff, which (IMHO) isn't routing related at all, but "Host + tunnel configuration information" I'd much rather not see that kind of thing not be shoe-horned into routing UPDATEs, regardless of the draft of this subject. However, if it must be, then it's a simple matter to require the next-hop be filled in with nexthop self. Also: I'd question why you'd need to advertise VPN configuration information for a given host multiple times. If it has no equivalent to next-hop, it likely has no use for multiple-advertisements. > PS. The stated issue with add-path's drawback to require uniqe > identifier to be generated by BGP speaker is not IMHO at all a problem. The draft should perhaps say how. We are reasonably certain there are issues with all but simple reflector cases - any case where one wishes multiple paths to be /readvertised/ can not use identifiers derived from the identity of from whom the route was learnt (e.g. router-ID). So the speaker is left to construct some identifier specific to the peer the speaker is sending the path to, for that path. Which seems redundant to us as such an identifier already exists in all the BGP AFI/SAFIs we have considered -> the nexthop. NB: As with all my replies in this thread, I am to a great extent paraphrasing things Joel and Manav pointed out to me in private discussions. Mistakes are my own though. ;) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Help a swallow land at Capistrano. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 17:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG041-0006qq-U8; Wed, 23 Aug 2006 17:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG041-0006ql-25 for idr@ietf.org; Wed, 23 Aug 2006 17:15:05 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG03z-0005Vi-OD for idr@ietf.org; Wed, 23 Aug 2006 17:15:05 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GG03w-0006Q0-UA; Wed, 23 Aug 2006 17:15:01 -0400 Message-Id: <7.0.1.0.0.20060823171044.040e7298@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 23 Aug 2006 17:14:59 -0400 To: Jeffrey Haas From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <20060823172415.GF13706@scc.mi.org> References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112022562ed0e0c6f31f2c900c81a27f0b6d2aee2c8841936d9a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org We probably do need to fold the path compression description (what you do when using multiple paths and talking to a peer who does not speak this extension.) We wanted to get the base description out, and we wanted to confirm that the working group actually wanted the description in the draft (since that was confusing to some people.) With regard to the case where paths differ on something other than NLRI or next-hop, I could not construct a case where there was a need to advertise them. All the cases I have seen for the oscillation also have differing next-hops. I had originally wanted to support broader variation, but realized that any time you are advertising multiple paths with the same next hop, you might as well compress them before advertising, rather than after. As to using the next-hop for advertisement identification, something has to identify the advertisement. After all, even if you do not have any implicit withdrawls, there has to be some way to explicitly withdraw the individual routes. Yours, Joel M. Halpern At 01:24 PM 8/23/2006, Jeffrey Haas wrote: >On Wed, Aug 23, 2006 at 05:26:16PM +0100, Paul Jakma wrote: > > >If I might ask the authors, is this a fair summary of the mechanism? > > > > Almost: The [...] > >Thanks for the summary. My understanding wasn't off too much. > >Here are my concerns with the mechanism at a meta level: > >- By keying on NLRI, nexthop (rather than just NLRI), you are precluding > the sending of multiple distinct paths that share the same nexthop. > We'll likely want to be able to do this for ECMP. Additionally, > without the ability to do this, I believe we wont be able to suppress > some of the MED oscillation scenarios. >- The mechanism doesn't give us a way to distinguish routes that are > being sent to preclude oscillation, but may not be relevant to > forwarding. More generally, routes need to be marked as to whether > they are being used for forwarding or not. >- The protocol mechanism has withdraws utilizing path attributes as > part of their keying mechanism. While this is intentional, it's very > much out of character with BGP. Primarily, this is because it preclude > the mixing of simultaneous advertisement of feasible and unfeasible > routes. > >I would suggest that the application components of this draft be >split into a separate draft. Mixing the applications with the >protocol descriptions makes it a bit more complicated than is warranted. > >Interaction of speakers of this mechanism with non-speakers needs >to be documented, both within an AS (or confederation) and outside. >This means that the ecmp/aggregation case needs to be documented. > >General note to the IDR community: We're spending a lot of time discussing >the protocol mechanisms of passing around additional routes. I think >we'd benefit from more discussion of the implications of doing this >at a generic level before we start debating how to sling bits on the wire. >The complex AS_PATH aggregation for ecmp that was a previous topic >is a good example of the discussion I think we need. > >-- Jeff > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 17:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG07d-00083C-Po; Wed, 23 Aug 2006 17:18:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG07c-00082T-F3 for idr@ietf.org; Wed, 23 Aug 2006 17:18:48 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG07Z-0006OC-6R for idr@ietf.org; Wed, 23 Aug 2006 17:18:48 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GG07Y-0002fN-IZ; Wed, 23 Aug 2006 17:18:44 -0400 Message-Id: <7.0.1.0.0.20060823164029.040d9f10@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 23 Aug 2006 17:18:42 -0400 To: raszuk@cisco.com From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EC7783.6060405@cisco.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112022562ed0e0c6f31f66f074f534198c03aa82875e1cd9e508350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org When the multiple next hops attribute is used, the advertisement is not an implicit withdrawl of anything other than an advertisement for the same NLRI / Next-Hop pair. RFC4364 makes use of RFC 3107. RFC 3107 defines that the label is part of the NLRI. Therefore, frankly, in most cases, neither our draft nor add-path is needed. The different next hops will typically use different labels. However, as defined, if two next hops happen to use the same label for the same prefix within a VPN, a reflector would have to choose one. By using our extension, the reflector can advertise both routes (next hops with NLRI and label) even when the NLRI and label match within the VPN. (Obviously, for different VPNs there is no problem as different RDs induce separation in BGP anyway. Our proposal works for any address family that advertises NLRI and meaningful next-hops. What hypothetical address family do you believe has problems? Yours, Joel M. Halpern At 11:42 AM 8/23/2006, Robert Raszuk wrote: >Paul, > >I am not talking about RFC3107 but RFC4364. Yes in both the label is >encoded in the NLRI, but meaning of the VPN label can not be decoupled >from the next hop information who advertised it. > >If you send as you propose in separate updates this is implicit withdraw >in most implementations I am aware so I don't see the multipath in action. > >In general I think your draft may work well for IPv4/v6 unicast address >family. I don't think that it works well for any other address families >already proposed in this WG. Moreover I don't think it is flexible >enough to offer requested functionality for new AFI/SAFIs coming soon. >In many cases of new SAFIs next hop is irrelevant what matters is NLRI + >neighbor for example. > >IMHO this is premature to accept this as WG document. > >Cheers, >R. > >PS. The stated issue with add-path's drawback to require uniqe >identifier to be generated by BGP speaker is not IMHO at all a problem. > > > > On Wed, 23 Aug 2006, Robert Raszuk wrote: > > > >> Joel, Paul > >> > >> I am looking at the version -01 and can't find any encoding how are you > >> proposing to send multiple vpnv4/v6 paths each with different next hop > >> and a different VPN labels. > >> > >> Can you clarify ? > > > > The label is encoded with the NLRI according to RFC3107. This draft > > extends the identity of a path to: > > > > (NLRI, next-hop) > > > > That the NLRI can be decomposed to (prefix,label) is of no interest, it > > is an opaque identity as far as this draft is concerned. > > > > So for say: > > > > ( (P, label1), N1) > > ( (P, label2), N2) > > . > > . > > ( (P, labeln), Nn) > > > > would be advertised as: > > > > UPDATE: > > feasible NLRI: (P,label1), > > NEXT_HOP: N1 > > > > UPDATE: > > feasible NLRI: (P,label2), > > MULTIPLE_NEXT_HOP: N2 > > > > . > > . > > UPDATE: > > feasible NLRI: (P,labeln), > > MULTIPLE_NEXT_HOP: Nn > > > > > > If are identical, this draft can not though bunch the > > UPDATEs together (it would be ambigious which nexthops were associated > > with which NLRI obviously). > > > > A seperate UPDATE is needed for each distinct NLRI. > > > > NB: Read "NEXT_HOP or next-hop from MP_REACH_NLRI, whichever is > > appropriate" for any use of NEXT_HOP. I.e. I refer to the logical > > next-hop, be it from the traditional NEXT_HOP or from MP > > extensions. > > > > regards, _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 17:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0TJ-0006gf-UK; Wed, 23 Aug 2006 17:41:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG0TJ-0006ga-2A for idr@ietf.org; Wed, 23 Aug 2006 17:41:13 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0TG-0002C9-Oz for idr@ietf.org; Wed, 23 Aug 2006 17:41:13 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GG0T6-0005oZ-7G; Wed, 23 Aug 2006 17:41:00 -0400 Message-Id: <7.0.1.0.0.20060823173808.040f6c60@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 23 Aug 2006 17:40:53 -0400 To: Jeffrey Haas From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <20060823151543.GA3089@scc.mi.org> References: <005201c6c5ed$2910dd90$0201a8c0@rs.riverstonenet.com> <20060823151543.GA3089@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112022562ed0e0c6f31f0d7cdfcdbe5a5a24ecedbbf8636b6fbe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org You are asking about whether the receiver can tell whether the advertised paths are usable. given that paths must differ either on NLRI or Next-Hop, receiving an advertisement means that the indicated next hop is providing that advertised next hop (and is pro forma presumed to be using it if you send packets to that next-hop.) In earlier versions, where theoretically paths could share next hop and NLRI, while differing on other attributes, there was indeed a problem of knowing whether a received advertisement was usable. Yours, Joel At 11:15 AM 8/23/2006, Jeffrey Haas wrote: >Manav, > >I will admit to not having read this draft in detail enough to >comment on whether your procedures are complete. I've read >enough to believe that it looks like the proposed mechanism >is sufficient to add and delete multiple paths. However, one >key mechanism that isn't obvious when skimming this draft is >how the active route (the path or paths actually being used) >of the advertising speaker is denoted from other paths. > >Have I missed something? > >-- Jeff > > >On Tue, Aug 22, 2006 at 06:46:12PM +0530, Manav Bhatia wrote: > > Hi, > > > > The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt > addresses > > all of the concerns and suggestions that were given in the past IETFs and > > the mailing list and we believe its in a reasonable form to be progressed > > further in the WG. > > > > The proposal is compatible with IPv6 support, MPLS label > advertisement, and > > BGP multi-protocol support. > > > > > > We would like to ask for the working group status for this document, so > > that the working group may determine what revisions it wishes to make. > > > > Thanks, > > > > Joel, Paul and Manav > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www1.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 18:49:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1Ut-0001Bb-Up; Wed, 23 Aug 2006 18:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1Ut-0001BW-8Q for idr@ietf.org; Wed, 23 Aug 2006 18:46:55 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1Ur-0007Yj-Dd for idr@ietf.org; Wed, 23 Aug 2006 18:46:55 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/1mBztpRe7kIV2+jktymQsJnX+iVBC2MM@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7NMkdRE013133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 23:46:51 +0100 Date: Wed, 23 Aug 2006 23:46:39 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Jeffrey Haas Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <20060823172415.GF13706@scc.mi.org> Message-ID: References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1717/Wed Aug 23 17:19:54 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Jeffrey, On Wed, 23 Aug 2006, Jeffrey Haas wrote: > Thanks for the summary. My understanding wasn't off too much. Indeed. Also note that the mechanism is fairly arbitrary. There are a number of variations possible, with different tradeoffs (e.g. we considered explicitely encoding whether a next-hop was to be withdrawn or not, but decided against). The fundamental question here, as per previous email to Enke, is of path identity and whether next-hop (or notionally equivalent "route target" in the abstract) is intrinsic to routes, because if so it makes an excellent identifier for this purpose. Obviously we believe it to be so. > Here are my concerns with the mechanism at a meta level: > > - By keying on NLRI, nexthop (rather than just NLRI), you are precluding > the sending of multiple distinct paths that share the same nexthop. Yes. We argued privately about this but could not come up with any plausible case where one would need to advertise multiple paths for an NLRI with the same next-hop, in practice or conceptually. > We'll likely want to be able to do this for ECMP. Well, bear in mind the draft started life as Manav's ECMP draft. :) The draft now no longer explores ECMP, that's something to be covered in an additional draft if desired, but we obviously feel ECMP can build on top of this. > Additionally, without the ability to do this, I believe we wont be > able to suppress some of the MED oscillation scenarios. Hmm, can you explain further? That's been considered - see the appendices in the draft. > - The mechanism doesn't give us a way to distinguish routes that are > being sent to preclude oscillation, but may not be relevant to > forwarding. More generally, routes need to be marked as to whether > they are being used for forwarding or not. This isn't an issue. Only useable paths can be advertised. See Joel's reply. > - The protocol mechanism has withdraws utilizing path attributes as > part of their keying mechanism. While this is intentional, it's very > much out of character with BGP. Primarily, this is because it preclude > the mixing of simultaneous advertisement of feasible and unfeasible > routes. Yes. That's a limitation of UPDATE really. It's in keeping with the MP extensions though. Though, several other RFCs and drafts already modify UPDATE, so.. But it just seems terribly bad form (to me anyway, I can't speak for other authors) to redefine established formats. UPDATEv2 one day will clean all this up, one wishes at least. > I would suggest that the application components of this draft be > split into a separate draft. Mixing the applications with the > protocol descriptions makes it a bit more complicated than is > warranted. Yes. > Interaction of speakers of this mechanism with non-speakers needs > to be documented, both within an AS (or confederation) and outside. > This means that the ecmp/aggregation case needs to be documented. That's for later. As you say: > The complex AS_PATH aggregation for ecmp that was a previous topic > is a good example of the discussion I think we need. Yes. But that's not needed right now for this draft. :) There are uses besides ECMP (IX route-servers, iBGP reflectors). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: USENET would be a better laboratory is there were more labor and less oratory. -- Elizabeth Haley _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 21:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG3Yl-00011x-52; Wed, 23 Aug 2006 20:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG3Yj-00011s-N6 for idr@ietf.org; Wed, 23 Aug 2006 20:59:01 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG3Yi-00071t-98 for idr@ietf.org; Wed, 23 Aug 2006 20:59:01 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA20607; Wed, 23 Aug 2006 17:58:53 -0700 (PDT) Received: from manavLpt ([10.128.16.142]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 17:58:52 -0700 Message-ID: <00a401c6c718$7804f090$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: , "Paul Jakma" References: <20060822200947.3141.qmail@web60725.mail.yahoo.com><44EB7461.9090101@cisco.com><002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com><44EBA7D4.1080002@cisco.com><00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com><44EC07A3.7000304@cisco.com><7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com><44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Thu, 24 Aug 2006 06:28:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 Aug 2006 00:58:53.0356 (UTC) FILETIME=[7807D6C0:01C6C718] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Joel M. Halpern" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Robert, > I am not talking about RFC3107 but RFC4364. Yes in both the label is > encoded in the NLRI, but meaning of the VPN label can not be decoupled > from the next hop information who advertised it. This has already been addressed here. http://www1.ietf.org/mail-archive/web/idr/current/msg01906.html I dont see any problem in advertsing multiple VPNv4 routes. The first route is advertised using normal MP_REACH_NLRI. The second is advertised in the following manner: MP_REACH_NLRI that encodes X: afi = x1 safi = VPVv4 length of next hop address = 0 reserved = 0 nlri = L2:RD:X MULTIPLE_HOP is encoded as: afi = x1 safi = VPVv4 number of nexthops = 1 length of nexthop = length of N2 network address = N2 > In general I think your draft may work well for IPv4/v6 unicast address > family. I don't think that it works well for any other address families > already proposed in this WG. Moreover I don't think it is flexible > enough to offer requested functionality for new AFI/SAFIs coming soon. Again, look at http://www1.ietf.org/mail-archive/web/idr/current/msg01906.html For any given that is advertised using MP_REACH_NLRI one can advertise supplementary paths using MULTIPLE_HOP. > In many cases of new SAFIs next hop is irrelevant what matters is NLRI + > neighbor for example. See Paul's reply. Cheers, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 21:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG424-0000gZ-2S; Wed, 23 Aug 2006 21:29:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG422-0000gO-Gm for idr@ietf.org; Wed, 23 Aug 2006 21:29:18 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG421-00056V-47 for idr@ietf.org; Wed, 23 Aug 2006 21:29:18 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id SAA22042; Wed, 23 Aug 2006 18:29:11 -0700 (PDT) Received: from manavLpt ([10.128.16.142]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 18:29:10 -0700 Message-ID: <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Jeffrey Haas" , "Glen Kent" References: <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com><44EC07A3.7000304@cisco.com><7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com><44EC6277.8090000@cisco.com><44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org><20060823172415.GF13706@scc.mi.org><92c950310608231052j492c13dej7d8ee7ea7fa5428b@mail.gmail.com> <20060823181150.GG13706@scc.mi.org> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Thu, 24 Aug 2006 06:59:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 Aug 2006 01:29:10.0602 (UTC) FILETIME=[B33192A0:01C6C71C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Jeff, Indicating which subset of the multiple routes being advertised are actually being used in FIB is fairly easy in our approach. We had discussed this offline and we had introduced a flags field in MULTIPLE_HOP field, where one of the bits set would indicate that the route is actually being used in forwarding. The idea was shot down and we put text in our ecmp draft wherein if a BGP speaker uses multiple paths then it *has* to forward all of those to a ecmp-capable peer. And if its peered up with a non ecmp capable peer, then it has to advertise a single path with a synthetic AS_PATH. The idea is that if you are using multiple paths then you are doing ecmp. I suggest you read draft-bhatia-ecmp-routes-in-bgp-02.txt for more details. A simple addition of the following text would perhaps fix the issue that you have: Between Multiple-Hop capable speakers, the MULTIPLE_HOP attribute MUST be used in addition to the existing NEXT_HOP/MP_REACH_NLRI in order to announce multiple next-hops for the destinations listed in the NLRI/MP_REACH_NLRI of the UPDATE message. If the speaker has installed one of the next-hops concerned in its FIB, then that particular next-hop MUST be listed in the NEXT_HOP/MP_REACH_NLRI attribute. This is possible in our approach, but can *never* be done in add-paths btw. However, we must also keep in mind that there are applications that require multiple BGP paths where none of them are actually installed in the FIB (eBGP IXes). Cheers, Manav ----- Original Message ----- From: "Jeffrey Haas" To: "Glen Kent" Cc: Sent: Wednesday, August 23, 2006 11:41 PM Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt > Glen, > > On Wed, Aug 23, 2006 at 11:22:24PM +0530, Glen Kent wrote: >> I think we need to disassociate the reason why a BGP speaker may want >> to advertise multiple paths with how it can do so. > > Agreed. > >> So, lets focus on just one thing here: Is the mechanism to advertise >> multiple paths okay here? > > I don't think so. I've documented two reasons I think the mechanism > needs to address. > > Catching up on this thread made me go read the add-paths document. > I think that mechanism is cleaner from a protocol standpoint. > >> an RR cant set next-hop-self so it would never send paths with same >> next-hop. You could send this in EBGP, but then for EBGP would you >> really send separate individual path attributes? > > Consider the case of confederation's setting next-hop-self at a > confederation border. It is used, although not commonly. > > I also think precluding the mechanism between external bgp speakers > is excessive - from a protocol standpoint, not an application standpoint. > >> Again, if this draft is only going to talk about how a speaker needs _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 23 21:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG48P-0003Kv-QM; Wed, 23 Aug 2006 21:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG48O-0003Kq-Ga for idr@ietf.org; Wed, 23 Aug 2006 21:35:52 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG48K-00062E-37 for idr@ietf.org; Wed, 23 Aug 2006 21:35:52 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id SAA22398; Wed, 23 Aug 2006 18:35:43 -0700 (PDT) Received: from manavLpt ([10.128.16.142]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 18:35:42 -0700 Message-ID: <00e801c6c71d$9cbc8f60$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: Subject: Fw: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Thu, 24 Aug 2006 07:05:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 Aug 2006 01:35:42.0579 (UTC) FILETIME=[9CD48430:01C6C71D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org This mail never made it to IDR because its probably waiting for ACK from the maintainer as it wasn't posted from the subscribed email. Manav ----- Original Message ----- From: "Arnold Nipper" To: "Manav Bhatia" Cc: ; ; "Yakov Rekhter" ; "Joel M. Halpern" ; "Paul Jakma" Sent: Tuesday, August 22, 2006 10:04 PM Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt > On 22.08.2006 15:16 Manav Bhatia wrote > >> Hi, >> >> The revised edition of draft-bhatia-bgp-multiple-next-hops-01.txt >> addresses all of the concerns and suggestions that were given in the >> past IETFs and the mailing list and we believe its in a reasonable >> form to be progressed further in the WG. >> >> The proposal is compatible with IPv6 support, MPLS label >> advertisement, and BGP multi-protocol support. >> >> >> We would like to ask for the working group status for this document, >> so that the working group may determine what revisions it wishes to >> make. >> >> Thanks, >> >> Joel, Paul and Manav >> > > I strongly support this as this helps Internet eXchange Points (IXP) to > build "real" routeservers. Having routeservers at IXPs reduces > complexity and brings new customers to speed very quickly. Currently > routeserver support still is suboptimal as the routeserver has to do best > path selection. > > > > Best regards, > Arnold > -- > Arnold Nipper / DE-CIX Management GmbH, the German Internet Exchange > e-mail: arnold.nipper@de-cix.net > phone/mob: +49 172 265 0958 fax: +49 6224 9259 333 > http://www.de-cix.net > pgp-fingerprint: 8A05 30DA 395F C1F0 1FAA 2EE1 B198 0312 F7EE 2295 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 00:56:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7Ew-0004mE-4Y; Thu, 24 Aug 2006 00:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7Eu-0004kM-Ni for idr@ietf.org; Thu, 24 Aug 2006 00:54:48 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG7Eu-0003vS-8p for idr@ietf.org; Thu, 24 Aug 2006 00:54:48 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k7O4sUQW006307; Thu, 24 Aug 2006 07:54:30 +0300 Date: Thu, 24 Aug 2006 07:54:30 +0300 (EEST) From: Pekka Savola To: Jeffrey Haas Subject: Re: [Idr] 4byte ASN support in RFC4273 In-Reply-To: <20060823203013.GK13706@scc.mi.org> Message-ID: References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> <20060822164321.GA3647@scc.mi.org> <7.0.1.0.2.20060823180856.03548898@ripe.net> <20060823203013.GK13706@scc.mi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.4/1721/Thu Aug 24 03:06:46 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: idr@ietf.org, asn32@ripe.net, Henk Uijterwaal X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Wed, 23 Aug 2006, Jeffrey Haas wrote: >> I have several products using >> the current MIB and it'd really help if I could point maintainers to >> a new MIB and ask them to upgrade? I can even provide a list of things >> that need to be changed (but I'm no MIB expert, so I don't think I >> could write the MIB myself). > > Inputs on the MIB features would be appreciated. Core features of > the base mib include: > > - Support for multiple bgp instances > - Support for multiple route instances > - 4 byte as path support > - ipv6 support > - prefix counters > - hooks for extension mibs > + communities > + extended-communities > + confederations > + route reflect > + etc. Aren't we getting pretty close to the original 'too complex' MIB? Was there any indication which specific bits of the MIB were felt to be particularly complex. As a particular item, as an operator I want to be able to see the prefix counts and, if at all possible, prefixes which are received over the BGP session but are filtered out in my configuration (e.g., prefix or AS path list). The BGP-MIB-V2 added support for that I think. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 01:52:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG87J-00062J-OT; Thu, 24 Aug 2006 01:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG87I-00062E-Hb for idr@ietf.org; Thu, 24 Aug 2006 01:51:00 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG87E-00065H-4g for idr@ietf.org; Thu, 24 Aug 2006 01:51:00 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA05645; Wed, 23 Aug 2006 22:50:53 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 11:20:52 +0530 From: "Manav Bhatia" To: "'Robert Raszuk'" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Thu, 24 Aug 2006 11:20:47 +0530 Message-ID: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHQT9ZyL0GgK8oRv6u7ycrcTlDyA== X-OriginalArrivalTime: 24 Aug 2006 05:50:52.0652 (UTC) FILETIME=[425842C0:01C6C741] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > PS. The stated issue with add-path's drawback to require uniqe > identifier to be generated by BGP speaker is not IMHO at all a problem. It is really. The suggested scheme becomes mucky and fragile when one has to readvertise the multiple paths that it has received, because it can then no longer use the Router ID to disambiguate the paths. The speaker is then left to construct some unique arbitrary identifier specific to the peer the speaker is sending the path to, for those paths. A | B C \ / D Assume A sends two routes x1:10/8, x2:10/8, where x1 and x2 are the router IDs of the peers A received these routes from, to B. How does B announce these routes forward to D? It has to generate and manage unique path IDs which now, are neither based on router IDs nor derived from AS numbers, etc. Something that the draft conveniently prefers to skim over. The use of arbitrary path IDs can influence the amount of memory required to hold the routes on both the routers. If different path IDs are used, the amount of memory needed to store all the routes increases. You cannot simply ignore the path IDs that you send/receive as you need to store them for performing implicit/complete withdrawals. The claim therefore that add-paths "requires only minor software changes for the vast majority of the BGP speakers in a network" is misleading and incorrect. [1] We believe that introducing a new arbitrary identifier is redundant, complex and prone to implementation quirks and can fail in interesting ways. We instead use the next_hop (which is already exchanged) as the "unique identifier". >In general I think your draft may work well for IPv4/v6 unicast address >family. I don't think that it works well for any other address families >already proposed in this WG. I have already replied as to how this proposal would work for VPNv4 routes, and other AFI, SAFI routes. Let me know if there is any ambiguity there. Cheers, Manav [1] The last paragraph in section 3 from draft-walton-bgp-route-oscillation-stop-01.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 02:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8oT-0008Cf-2p; Thu, 24 Aug 2006 02:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8oQ-0008Ca-W7 for idr@ietf.org; Thu, 24 Aug 2006 02:35:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG8oP-0004Kd-C7 for idr@ietf.org; Thu, 24 Aug 2006 02:35:34 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2006 23:35:32 -0700 X-IronPort-AV: i="4.08,163,1154934000"; d="scan'208"; a="313440521:sNHT33681114" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O6ZW2q000673; Wed, 23 Aug 2006 23:35:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7O6ZW6W001469; Wed, 23 Aug 2006 23:35:32 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 23:35:32 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 23:35:31 -0700 Message-ID: <44ED48AC.1020702@cisco.com> Date: Wed, 23 Aug 2006 23:35:24 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 06:35:31.0919 (UTC) FILETIME=[7F4FF5F0:01C6C747] DKIM-Signature: a=rsa-sha1; q=dns; l=5587; t=1156401332; x=1157265332; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=SFZn7aot3NZYGPd6RquQySbM+NbZrBb2VQYq3xgYqHs8itbeMft8wrhbzAUEY1h3IrzYewk4 +c6jewLq0Brot7iKelTigKQEVHJEsVjRFd//K44MhOszalyG4Xfm3/oK; Authentication-Results: sj-dkim-8.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Joel: Joel M. Halpern wrote: > Enke, I have real trouble with your characterization of your draft. > You claim it is simple and elegant. > From where I sit, it introduces a new identifier that must be shared > between the routers. That identifier has to be assigned and managed > by the advertising router in such a way that it is unique for each > path that needs advertised (under all possible circumstances). But it > has to be used by the receiver no matter how the sender has chosen to > allocate / create it. As such, if the two happen to have the same > implementation view they may find it simple. But it is quite > dependent upon that implementation. I am not sure what you meant by "same implementation view, and dependent upon a particular implementation". In the add-path proposal, the advertiser is responsible for allocating the identifier suitable for a particular application, and the receiver needs to use the (prefix, path-identifier) to identify a path to be replaced. I believe that part is clear in the proposal, but if it is not, we'll need to make it clear. > While our draft makes use of information that was already being > exchanged to provide the necessary disambiguation. I would argue that > such is in fact both simpler and more elegant. > > At the same time, your claim of greater flexibility is in fact not > backed up by need. We previously had support for advertising paths > with different attributes but the same NLRI and the same next-hop. In > discussion with folks we realized that there was no actual use case > where you need the differentiation. Either the advertiser is in the > path (next-hop self) in which case preserving the paths does not add > information, even for the route oscillation case, or the advertiser is > preserving the next-hop information in which case the next hops > provide the needed differentiation. Thus, using the next-hop as an > added differentiator provides exactly the flexibility needed by the > problem, and is much simpler, more amenable to variations in > implementations strategies, and more robust. I keep hearing that (prefix, nexthop) as the key to identify a path, and here you also mentioned "using the next-hop as an added differentiator". For several applications I cited, (prefix, nexthop) is actually not the right one. Considering the case in which the route reflector would advertising all the routes (simulating full-mesh). It is actually the (prefix, router-id) that would identify a path instead of the prefix itself. As the issue of how to identify a path is so fundamental to a solution, I hope that it can be clarified before we dive into other details. Regards, -- Enke > > Yours, > Joel M. Halpern > > At 03:45 AM 8/23/2006, Enke Chen wrote: > >> Hi, Manav: >> >> Manav Bhatia wrote: >> >>> Hi Enke, >>> >>>> >>>> The add-path draft introduces a path identifier so that a path from >>>> a neighbor can be identified by (prefix, path identifier), and the >>>> implicit replacement/withdraw behavior (and thus the update >>>> efficiency) in BGP is maintained. The path identifier can be a >>>> neighbor-AS, or a router-id, or an opaque number suitable for a >>>> particular application. >>>> >>>> It is not clear to me how the implicit replacement/withdraw can be >>>> achieved with your proposal. >>> >>> >>> >>> Simple. You look at the prefix and the nexthop to perform implicit >>> withdraw as this tuple would always be uniquely learnt from each BGP >>> speaker. >> >> >> >> Sorry I do not follow you, and I went back to your draft and got more >> confused. As you stated here, as well as in the draft, a path is >> identified by (prefix , nexthop-address) in your proposal. Then how >> can a path identified by (prefix, neighbor-As), or (prefix, >> router-id), or (prefix, opaque-number) be implicitly >> replaced/withdrawn by a mechanism that identifies a path by (prefix, >> nexthop-address)? >> >> Regarding the need for identifying a path by (prefix, neighbor_AS) or >> (prefix, route-id), I am not sure if you have read the companion >> draft of add-path (draft-walton-bgp-route-oscillation-stop-01.txt), >> which has expired unfortunately, but is still readily available on >> the Internet, for example: >> >> >> http://ietfreport.isoc.org/idref/draft-walton-bgp-route-oscillation-stop-01.txt >> >> >> Two approaches are presented in the draft to address the ibgp route >> oscillation: >> >> 1) advertise the available paths (equivalent to full ibgp mesh): >> in this case a path is identified by (prefix, router-id). >> 2) advertise the (neighboring-AS based) group bestpaths: in this >> case a path is identified by (prefix, neighboring-AS). >> >> They have different scaling properties, and a provider may choose to >> deploy one or another. In both cases, however, the nexthop addresses >> of the multiple paths being advertised would most likely be different. >> >> Since we are comparing the drafts, I think it is fair to ask this >> question: >> >> As the add-path draft has existed for a long time, and the spec is >> pretty simple, complete, fairly elegant (sure, relatively), I am >> wondering if you have spotted certain issues with it that can not be >> fixed, or if the solution proposed failed to address a particular >> problem that requires multiple paths? >> >> -- Enke >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 03:29:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9cq-0007gZ-L7; Thu, 24 Aug 2006 03:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG9cp-0007gU-0x for idr@ietf.org; Thu, 24 Aug 2006 03:27:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG9cn-0003XE-LS for idr@ietf.org; Thu, 24 Aug 2006 03:27:39 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2006 00:27:38 -0700 X-IronPort-AV: i="4.08,163,1154934000"; d="scan'208"; a="313456912:sNHT39710914" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O7Rbbs028236; Thu, 24 Aug 2006 00:27:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7O7Raw7005283; Thu, 24 Aug 2006 00:27:36 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Aug 2006 00:27:36 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 00:27:36 -0700 Message-ID: <44ED54E7.4030209@cisco.com> Date: Thu, 24 Aug 2006 00:27:35 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <00ef01c6c68b$60915990$260218ac@rs.riverstonenet.com> In-Reply-To: <00ef01c6c68b$60915990$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 07:27:36.0424 (UTC) FILETIME=[C5A99680:01C6C74E] DKIM-Signature: a=rsa-sha1; q=dns; l=3296; t=1156404457; x=1157268457; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=R1uSmAj6Z9ZfS55cIysB4Wo6VA31E27f96dFvnQepXJOvF88/Uh1dvbhGRj4ynSyEG18ym69 PY6UBGcqO9tsv7M7VBWCbOg45WqvsXKA+Z8STTpf1bKoU3U2w06uO1EO; Authentication-Results: sj-dkim-6.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav: In your example it seems that a path is replaced by another path with an identical nexthop. Would that be a bit too restrictive? In addition, it is desirable and typical in implementations to have the receiving processing de-coupled from the sending processing (in order to keep less state). It means that at the time of sending update the info (such as the nexthop) for the old path may no longer available. I am not sure if your proposal requires an implementation to keep track of the nexthops advertised to a peer for the purpose of figuring out when to use the NEXTHOP attribute or the MULTI-NEXTHOP attribute. Let us consider a specific example: RR1 ---------------- RR2 / \ / \ B1 B2 in which RR1 and RR2 are route reflectors, and B1 and B2 are clients of RR1, and they do not use "next-hop-self". The router-id for B1 and B2 are B1-ID, and B2-ID respectively. RR1 advertises all routes to RR2 (emulating full mesh). Initially B1 advertise X with N1 as the nexthop to RR1, and later advertise X with N11 to RR1. Initially B2 advertise X with N2 to RR1, and later advertise X with N22 to RR1. With the add-path proposal, RR1 would initially advertise (X, B1-ID) with N1, and (X, B2-ID) with N2, to RR2 using the router-id as the path identifier. Later, RR1 would advertise (X, B1-ID) with N11, and (X, B2-ID) with N22 to RR2. Four updates are involved. How does your proposal work with respect to the updates in this example? -- Enke Manav Bhatia wrote: >Hi Mach, > > > >>> An UPDATE message announced with a MULTIPLE_HOP attribute >>> >>> >>for a given >> >> >>> IP address prefix implicitly withdraws any previous route announced >>> with the same next-hop. >>> >>> >>OK,but I want to know how to perform implicitly withdraw when >>partial nexthop attribute changed. >> >> >> > >Assume A has 3 routes to X (with next-hops N1, N2 and N3) that it wants to >announce to B. > >A does this by sending the following UPDATE messages to B: > >UPDATE: feasible nlri X, next_hop N1, >UPDATE: feasible nlri X, multiple_hop N2, >UPDATE: feasible nlri X, multiple_hop N3, > >Case I: > >Some path attributes change for the route associated with next-hop N2 and it >wants to replace the new route with the earlier announcement. > >A sends the following UPDATE message: > >UPDATE: feasible nlri X, multiple_hop N2, > >B upon receiving this message searches its RIB for the route associated with >the tuple . If it doesn't find a route, then it appends this in its >RIB. In this case, it finds the route that it had received earlier from A >and considers this as an implicit withdrawal. > >Case II: > >A wants to selectively remove the route associated with the next_hop N2. > >A sends the following UPDATE message: > >UPDATE: unfeasible nlri X, multiple_next_hop N2 > >Hope this helps. > >Manav > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 03:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGA3b-0001mS-Aa; Thu, 24 Aug 2006 03:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGA3a-0001mN-2g for idr@ietf.org; Thu, 24 Aug 2006 03:55:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGA3Y-000757-Kb for idr@ietf.org; Thu, 24 Aug 2006 03:55:18 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 00:55:16 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O7tFdT026580; Thu, 24 Aug 2006 00:55:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7O7tFQV021628; Thu, 24 Aug 2006 00:55:15 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Aug 2006 00:55:15 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 00:55:15 -0700 Message-ID: <44ED5B62.4020104@cisco.com> Date: Thu, 24 Aug 2006 00:55:14 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> In-Reply-To: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 07:55:15.0387 (UTC) FILETIME=[A27B40B0:01C6C752] DKIM-Signature: a=rsa-sha1; q=dns; l=3199; t=1156406116; x=1157270116; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=bIDcuvjNo7b3MM6zcv0NCMhPHm7zohhFH9L6aa2IHTo3f3Mk257cMxtAO5fNpOErx4f9+EZj zX0sxOkWCiRB+G+Rh2SuWO98/MD5txV02zBFTRy4pkoRYI18zFZlZ6Xe; Authentication-Results: sj-dkim-1.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: 'Robert Raszuk' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav Bhatia wrote: >>PS. The stated issue with add-path's drawback to require uniqe >>identifier to be generated by BGP speaker is not IMHO at all a problem. >> >> > >It is really. > >The suggested scheme becomes mucky and fragile when one has to readvertise >the multiple paths that it has received, because it can then no longer use >the Router ID to disambiguate the paths. The speaker is then left to >construct some unique arbitrary identifier specific to the peer the speaker >is sending the path to, for those paths. > > Depends on the application, a speaker may or may not be able to use the same path identifier it has received. What exactly is the problem of constructing an identifier? >A >| >B C > \ / > D > > >Assume A sends two routes x1:10/8, x2:10/8, where x1 and x2 are the router >IDs of the peers A received these routes from, to B. > >How does B announce these routes forward to D? > > Router-ids are unique only with an AS. Since you did not specify the application, the fact that Router A uses the router-id as the identifier seems to suggest that this is a route reflection case (full-mesh), and it is ibgp between A and B. How does B announce these routes to D? It depends on the application again. If D is an ibgp peer, B can use the same router-id. If D is an ebgp peer and ebgp multipath is involved, B needs to assign an unique id. >It has to generate and manage unique path IDs which now, are neither based >on router IDs nor derived from AS numbers, etc. Something that the draft >conveniently prefers to skim over. The use of arbitrary path IDs can >influence the amount of memory required to hold the routes on both the >routers. If different path IDs are used, the amount of memory needed to >store all the routes increases. You cannot simply ignore the path IDs that >you send/receive as you need to store them for performing implicit/complete >withdrawals. > >The claim therefore that add-paths "requires only minor software changes for >the vast majority of the BGP speakers in a network" is misleading and >incorrect. [1] > >We believe that introducing a new arbitrary identifier is redundant, complex >and prone to implementation quirks and can fail in interesting ways. We >instead use the next_hop (which is already exchanged) as the "unique >identifier". > > It is all relative, and I am afraid that your description of "mucky, fragile, redundant, complex, prone to error" might be relevant in the current discussion. -- Enke > > >>In general I think your draft may work well for IPv4/v6 unicast address >>family. I don't think that it works well for any other address families >>already proposed in this WG. >> >> > >I have already replied as to how this proposal would work for VPNv4 routes, >and other AFI, SAFI routes. Let me know if there is any ambiguity there. > >Cheers, >Manav > >[1] The last paragraph in section 3 from >draft-walton-bgp-route-oscillation-stop-01.txt > > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 04:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAL8-0003eU-HW; Thu, 24 Aug 2006 04:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAL7-0003XJ-63 for idr@ietf.org; Thu, 24 Aug 2006 04:13:25 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAL5-0001ja-Pd for idr@ietf.org; Thu, 24 Aug 2006 04:13:25 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA14139; Thu, 24 Aug 2006 01:13:16 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 13:43:15 +0530 From: "Manav Bhatia" To: Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Thu, 24 Aug 2006 13:43:10 +0530 Message-ID: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHTshjwifNQVSzQaa2Dg10fDkmdwABJWUQ In-Reply-To: <44ED54E7.4030209@cisco.com> X-OriginalArrivalTime: 24 Aug 2006 08:13:15.0808 (UTC) FILETIME=[26766A00:01C6C755] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Enke, >Let us consider a specific example: > > RR1 ---------------- RR2 > / \ > / \ > B1 B2 > [ .. ] > Initially B1 advertise X with N1 as the nexthop to RR1, >and later >advertise X with N11 to RR1. > Initially B2 advertise X with N2 to RR1, and later advertise X >with N22 to RR1. > [ .. ] > >How does your proposal work with respect to the updates in >this example? RR1 would advertise the following UPDATEs to RR2. UPDATE: feasible nlri X, next_hop N1, UPDATE: feasible nlri X, multiple_hop N11, UPDATE: feasible nlri X, multiple_hop N2, UPDATE: feasible nlri X, multiple_hop N22, >With the add-path proposal, RR1 would initially advertise (X, B1-ID) >with N1, and (X, B2-ID) with N2, to RR2 using the router-id as the path >identifier. Later, RR1 would advertise (X, B1-ID) with N11, and (X, >B2-ID) with N22 to RR2. Four updates are involved. Same here. If OTOH the different UPDATEs share the same path attributes, then the announcements can be clubbed in a single UPDATE message. For eg., If B1 and B2 are redundantly connected to other BGP speakers then its possible that the announcements share common path attributes. In that case RR1 can announce the following UPDATE message to RR2. UPDATE: feasible nlri X, next_hop N1, UPDATE: feasible nlri X, multiple_hop N11, N2, N22 Or in the best case, can be done with only one UPDATE message. UPDATE: feasible nlri X, multiple_hop N1, N11, N2, N22 Cheers, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 04:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnl-00080R-FS; Thu, 24 Aug 2006 04:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnj-0007r7-Pi for idr@ietf.org; Thu, 24 Aug 2006 04:42:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAim-0007GK-5A for idr@ietf.org; Thu, 24 Aug 2006 04:37:54 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 01:37:51 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O8bpo5025711; Thu, 24 Aug 2006 01:37:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7O8bp1E027557; Thu, 24 Aug 2006 01:37:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Aug 2006 01:37:51 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 01:37:50 -0700 Message-ID: <44ED655E.8020702@cisco.com> Date: Thu, 24 Aug 2006 01:37:50 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> In-Reply-To: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 08:37:51.0029 (UTC) FILETIME=[95C34650:01C6C758] DKIM-Signature: a=rsa-sha1; q=dns; l=2233; t=1156408671; x=1157272671; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=kPwKcXDd8MUIk8lQ36HDHQPi3fgnV46R6PaZSvWDe0vE92DccZqGgCEA/6zuiZdYNCGPgUSX kRtLjYUNRTem7BpwdErTU2yUDBGX3vU6R3skOb9jY0PYmcYLFDnnrlxP; Authentication-Results: sj-dkim-4.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav: Manav Bhatia wrote: >Enke, > > > >>Let us consider a specific example: >> >> RR1 ---------------- RR2 >> / \ >> / \ >> B1 B2 >> >> >> > >[ .. ] > > > >> Initially B1 advertise X with N1 as the nexthop to RR1, >>and later >>advertise X with N11 to RR1. >> Initially B2 advertise X with N2 to RR1, and later advertise X >>with N22 to RR1. >> >> >> > >[ .. ] > > > >>How does your proposal work with respect to the updates in >>this example? >> >> > >RR1 would advertise the following UPDATEs to RR2. > >UPDATE: feasible nlri X, next_hop N1, >UPDATE: feasible nlri X, multiple_hop N11, >UPDATE: feasible nlri X, multiple_hop N2, >UPDATE: feasible nlri X, multiple_hop N22, > > Please note that B1 and B2 are clients and do not advertise multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they are no longer valid (replaced by B1 and B2), in other words how does RR2 figure out (X, N11) is a replacement of (X, N1), and (X, N22) a replacement of (X, N2)? -- Enke > > >>With the add-path proposal, RR1 would initially advertise (X, B1-ID) >>with N1, and (X, B2-ID) with N2, to RR2 using the router-id as the path >>identifier. Later, RR1 would advertise (X, B1-ID) with N11, and (X, >>B2-ID) with N22 to RR2. Four updates are involved. >> >> > >Same here. > >If OTOH the different UPDATEs share the same path attributes, then the >announcements can be clubbed in a single UPDATE message. > >For eg., If B1 and B2 are redundantly connected to other BGP speakers then >its possible that the announcements share common path attributes. In that >case RR1 can announce the following UPDATE message to RR2. > >UPDATE: feasible nlri X, next_hop N1, >UPDATE: feasible nlri X, multiple_hop N11, N2, N22 > >Or in the best case, can be done with only one UPDATE message. > >UPDATE: feasible nlri X, multiple_hop N1, N11, N2, N22 > >Cheers, >Manav > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 04:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAoe-0008Jb-TA; Thu, 24 Aug 2006 04:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAoc-0008I0-Uy for idr@ietf.org; Thu, 24 Aug 2006 04:43:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAZY-00040p-EU for idr@ietf.org; Thu, 24 Aug 2006 04:28:21 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 01:28:20 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O8SJnA017571; Thu, 24 Aug 2006 01:28:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7O8SJQV008459; Thu, 24 Aug 2006 01:28:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 01:28:19 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 01:28:19 -0700 Message-ID: <44ED631C.9080802@cisco.com> Date: Thu, 24 Aug 2006 01:28:12 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> In-Reply-To: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 08:28:19.0138 (UTC) FILETIME=[40E3A220:01C6C757] DKIM-Signature: a=rsa-sha1; q=dns; l=1289; t=1156408099; x=1157272099; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=hwI+KaUsoa3cmFbmFuA2MRPNc+2aSrGEqQkKKES7d+P2PtBuGncNGGvqgjyiAbRjGTaPPUqg os/qBK1bOZSxx7MJ5UUxzozV+nyC0KOrLQRMuQ10EiyyPZYpHYd0KX6l; Authentication-Results: sj-dkim-4.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Robert Raszuk' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Let me comment on the memory issue that I forgot to address in the previous message: So how much additional memory are we talking about: I think the max is 8 bytes per path (4bytes for receiving, and 4bytes for allocating). For some applications (such as RR) the memory overhead for the path identifier is zero. Regarding the memory overhead in allocating a path identifier, it should be no more than 4 bytes per prefix. I am actually not concerned about the memory overhead for allocating and storing the path identifier because they are small compared to the memory that would be needed to store the per-path advertisement state for supporting multi-path in general. -- Enke Manav Bhatia wrote: [snip] >It has to generate and manage unique path IDs which now, are neither based >on router IDs nor derived from AS numbers, etc. Something that the draft >conveniently prefers to skim over. The use of arbitrary path IDs can >influence the amount of memory required to hold the routes on both the >routers. If different path IDs are used, the amount of memory needed to >store all the routes increases. You cannot simply ignore the path IDs that >you send/receive as you need to store them for performing implicit/complete >withdrawals. > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 04:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnl-00080R-FS; Thu, 24 Aug 2006 04:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAnj-0007r7-Pi for idr@ietf.org; Thu, 24 Aug 2006 04:42:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAim-0007GK-5A for idr@ietf.org; Thu, 24 Aug 2006 04:37:54 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 01:37:51 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O8bpo5025711; Thu, 24 Aug 2006 01:37:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7O8bp1E027557; Thu, 24 Aug 2006 01:37:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Aug 2006 01:37:51 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 01:37:50 -0700 Message-ID: <44ED655E.8020702@cisco.com> Date: Thu, 24 Aug 2006 01:37:50 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> In-Reply-To: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 08:37:51.0029 (UTC) FILETIME=[95C34650:01C6C758] DKIM-Signature: a=rsa-sha1; q=dns; l=2233; t=1156408671; x=1157272671; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=kPwKcXDd8MUIk8lQ36HDHQPi3fgnV46R6PaZSvWDe0vE92DccZqGgCEA/6zuiZdYNCGPgUSX kRtLjYUNRTem7BpwdErTU2yUDBGX3vU6R3skOb9jY0PYmcYLFDnnrlxP; Authentication-Results: sj-dkim-4.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav: Manav Bhatia wrote: >Enke, > > > >>Let us consider a specific example: >> >> RR1 ---------------- RR2 >> / \ >> / \ >> B1 B2 >> >> >> > >[ .. ] > > > >> Initially B1 advertise X with N1 as the nexthop to RR1, >>and later >>advertise X with N11 to RR1. >> Initially B2 advertise X with N2 to RR1, and later advertise X >>with N22 to RR1. >> >> >> > >[ .. ] > > > >>How does your proposal work with respect to the updates in >>this example? >> >> > >RR1 would advertise the following UPDATEs to RR2. > >UPDATE: feasible nlri X, next_hop N1, >UPDATE: feasible nlri X, multiple_hop N11, >UPDATE: feasible nlri X, multiple_hop N2, >UPDATE: feasible nlri X, multiple_hop N22, > > Please note that B1 and B2 are clients and do not advertise multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they are no longer valid (replaced by B1 and B2), in other words how does RR2 figure out (X, N11) is a replacement of (X, N1), and (X, N22) a replacement of (X, N2)? -- Enke > > >>With the add-path proposal, RR1 would initially advertise (X, B1-ID) >>with N1, and (X, B2-ID) with N2, to RR2 using the router-id as the path >>identifier. Later, RR1 would advertise (X, B1-ID) with N11, and (X, >>B2-ID) with N22 to RR2. Four updates are involved. >> >> > >Same here. > >If OTOH the different UPDATEs share the same path attributes, then the >announcements can be clubbed in a single UPDATE message. > >For eg., If B1 and B2 are redundantly connected to other BGP speakers then >its possible that the announcements share common path attributes. In that >case RR1 can announce the following UPDATE message to RR2. > >UPDATE: feasible nlri X, next_hop N1, >UPDATE: feasible nlri X, multiple_hop N11, N2, N22 > >Or in the best case, can be done with only one UPDATE message. > >UPDATE: feasible nlri X, multiple_hop N1, N11, N2, N22 > >Cheers, >Manav > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 04:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAoe-0008Jb-TA; Thu, 24 Aug 2006 04:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAoc-0008I0-Uy for idr@ietf.org; Thu, 24 Aug 2006 04:43:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAZY-00040p-EU for idr@ietf.org; Thu, 24 Aug 2006 04:28:21 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2006 01:28:20 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7O8SJnA017571; Thu, 24 Aug 2006 01:28:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7O8SJQV008459; Thu, 24 Aug 2006 01:28:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 01:28:19 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 01:28:19 -0700 Message-ID: <44ED631C.9080802@cisco.com> Date: Thu, 24 Aug 2006 01:28:12 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> In-Reply-To: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 08:28:19.0138 (UTC) FILETIME=[40E3A220:01C6C757] DKIM-Signature: a=rsa-sha1; q=dns; l=1289; t=1156408099; x=1157272099; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=hwI+KaUsoa3cmFbmFuA2MRPNc+2aSrGEqQkKKES7d+P2PtBuGncNGGvqgjyiAbRjGTaPPUqg os/qBK1bOZSxx7MJ5UUxzozV+nyC0KOrLQRMuQ10EiyyPZYpHYd0KX6l; Authentication-Results: sj-dkim-4.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Robert Raszuk' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Let me comment on the memory issue that I forgot to address in the previous message: So how much additional memory are we talking about: I think the max is 8 bytes per path (4bytes for receiving, and 4bytes for allocating). For some applications (such as RR) the memory overhead for the path identifier is zero. Regarding the memory overhead in allocating a path identifier, it should be no more than 4 bytes per prefix. I am actually not concerned about the memory overhead for allocating and storing the path identifier because they are small compared to the memory that would be needed to store the per-path advertisement state for supporting multi-path in general. -- Enke Manav Bhatia wrote: [snip] >It has to generate and manage unique path IDs which now, are neither based >on router IDs nor derived from AS numbers, etc. Something that the draft >conveniently prefers to skim over. The use of arbitrary path IDs can >influence the amount of memory required to hold the routes on both the >routers. If different path IDs are used, the amount of memory needed to >store all the routes increases. You cannot simply ignore the path IDs that >you send/receive as you need to store them for performing implicit/complete >withdrawals. > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 04:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAx1-0004Ah-WC; Thu, 24 Aug 2006 04:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGAx0-0004Ac-7b for idr@ietf.org; Thu, 24 Aug 2006 04:52:34 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGAwy-00030T-TQ for idr@ietf.org; Thu, 24 Aug 2006 04:52:34 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA17711; Thu, 24 Aug 2006 01:52:30 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 14:22:29 +0530 From: "Manav Bhatia" To: Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Thu, 24 Aug 2006 14:22:24 +0530 Message-ID: <007801c6c75a$9e2d70c0$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHWJghEXS8SKikSUaaY+sO1Tw09gAACeVQ In-Reply-To: <44ED655E.8020702@cisco.com> X-OriginalArrivalTime: 24 Aug 2006 08:52:29.0106 (UTC) FILETIME=[A1233120:01C6C75A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Enke, >multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they >are no longer valid (replaced by B1 and B2), in other words >how does RR2 >figure out (X, N11) is a replacement of (X, N1), and (X, N22) a >replacement of (X, N2)? > UPDATE: unfeasible nlri X, multiple_hop N1 UPDATE: unfeasible nlri X, multiple_hop N2 UPDATE: feasible nlri X, multiple_hop N11, UPDATE: feasible nlri X, multiple_hop N12, I think we can each come up with a scenario where one scheme would be more optimal and would involve lesser number of UPDATEs than the other. Cheers, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 08:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDvD-0006PW-Hh; Thu, 24 Aug 2006 08:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDvB-0006PP-S1 for idr@ietf.org; Thu, 24 Aug 2006 08:02:53 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGDvA-0002Tc-Ky for idr@ietf.org; Thu, 24 Aug 2006 08:02:53 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GGDv8-0000b8-7N; Thu, 24 Aug 2006 08:02:50 -0400 Message-Id: <7.0.1.0.0.20060824080059.03349d20@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 24 Aug 2006 08:02:47 -0400 To: Enke Chen From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44ED48AC.1020702@cisco.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44ED48AC.1020702@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112055150872e371e2cce022b6c2db3ed120510ab3ad090af031350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org A route reflector does not insert itself into the data path. Rather, it preserves the next-hop on all routes it receives. Therefore, when a route reflector reflects all routes it receives, all the routes for a given NLRI have distinct next-hops. So, in fact, the (NLRI, next-hop) pair does uniquely identify each advertisement generated by the route reflector. Yours, Joel M. Halpern At 02:35 AM 8/24/2006, Enke Chen wrote: >I keep hearing that (prefix, nexthop) as the key to identify a path, >and here you also mentioned "using the next-hop as an added >differentiator". For several applications I cited, (prefix, nexthop) >is actually not the right one. Considering the case in which the >route reflector would advertising all the routes (simulating >full-mesh). It is actually the (prefix, router-id) that would >identify a path instead of the prefix itself. > >As the issue of how to identify a path is so fundamental to a solution, >I hope that it can be clarified before we dive into other details. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 08:06:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDyu-0007OF-KO; Thu, 24 Aug 2006 08:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDyt-0007Nt-Fl; Thu, 24 Aug 2006 08:06:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGDyt-0002gf-Cz; Thu, 24 Aug 2006 08:06:43 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGDXp-0000BZ-GS; Thu, 24 Aug 2006 07:38:47 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 414F8147AB6; Thu, 24 Aug 2006 07:38:45 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k7OBcjgA018217; Thu, 24 Aug 2006 04:38:45 -0700 From: Bill Fenner Message-Id: <200608241138.k7OBcjgA018217@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Sam Hartman References: <44DCA14C.5030304@zurich.ibm.com> Date: Thu, 24 Aug 2006 04:38:44 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: -2.5 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr@ietf.org, IESG Subject: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >How does this interact with softwires? Sam, This protocol fits into more or less the Mesh problem of softwires (section 3.1 of draft-ietf-softwire-problem-statement). The problem statement says: > It should also be noted that the mesh problem can be considered as a > derivative of L3VPN, where the core provides transit in one address > family and the islands are connected via L3VPN of another address > family. And indeed, the draft-ooms document is more or less an application of the L3VPN technology to the IPv6 address family. I don't know what the softwires participants' position is with respect to this draft, but it predates the softwires work [at least, by that name] by about 5 years. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 09:24:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGF9E-0000Wm-Nz; Thu, 24 Aug 2006 09:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGF9D-0000Vm-Hr for idr@ietf.org; Thu, 24 Aug 2006 09:21:27 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGF99-0000PW-8E for idr@ietf.org; Thu, 24 Aug 2006 09:21:27 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id BDB4D24102; Thu, 24 Aug 2006 15:21:14 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 99F8523F75; Thu, 24 Aug 2006 15:21:12 +0200 (CEST) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 8513A2F592; Thu, 24 Aug 2006 15:21:12 +0200 (CEST) Message-Id: <7.0.1.0.2.20060824151827.03590598@ripe.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 24 Aug 2006 15:20:59 +0200 To: Jeffrey Haas From: Henk Uijterwaal Subject: Re: [Idr] 4byte ASN support in RFC4273 In-Reply-To: <20060823203013.GK13706@scc.mi.org> References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> <20060822164321.GA3647@scc.mi.org> <7.0.1.0.2.20060823180856.03548898@ripe.net> <20060823203013.GK13706@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -4.4 X-RIPE-Signature: 2023d553e61d64892a062528e81bb0a3 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: idr@ietf.org, asn32@ripe.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Jeff, >I've factored the complex functionality out, removed configuration >objects and am planning no a republish of the components within >the next two weeks, work permitting. Your review would be greatly >appreciated. I read the draft this morning, mainly focussing on 4 byte ASN. This draft seems to do what we want (provide data about routing for our monitoring stuff). I cannot really comment on the complexity (or lack thereof) of the entire MIB. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 10:14:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFxk-0007gN-1v; Thu, 24 Aug 2006 10:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFxi-0007gE-Ro for idr@ietf.org; Thu, 24 Aug 2006 10:13:38 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGFxh-0005n2-LR for idr@ietf.org; Thu, 24 Aug 2006 10:13:38 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 283414E80F; Thu, 24 Aug 2006 10:13:29 -0400 (EDT) Date: Thu, 24 Aug 2006 10:13:29 -0400 From: Jeffrey Haas To: Pekka Savola Subject: Re: [Idr] 4byte ASN support in RFC4273 Message-ID: <20060824141329.GL13706@scc.mi.org> References: <7.0.1.0.2.20060822105158.03521e78@ripe.net> <20060822164321.GA3647@scc.mi.org> <7.0.1.0.2.20060823180856.03548898@ripe.net> <20060823203013.GK13706@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: idr@ietf.org, asn32@ripe.net, Henk Uijterwaal X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Pekka, On Thu, Aug 24, 2006 at 07:54:30AM +0300, Pekka Savola wrote: > Aren't we getting pretty close to the original 'too complex' MIB? For the most part, all BGP extentions are factored into separate MIBs. If you don't want to see them, you don't have to. > Was there any indication which specific bits of the MIB were felt to > be particularly complex. Configuration objects were specifically noted. > As a particular item, as an operator I want to be able to see the > prefix counts and, if at all possible, prefixes which are received > over the BGP session but are filtered out in my configuration (e.g., > prefix or AS path list). The BGP-MIB-V2 added support for that I > think. The MIB has kept the prefix counters for total in, total out and accepted, rejected. An implementation, depending on what it does with a rejected prefix, may not be able to track rejected prefixes. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 12:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIAk-0003O5-Bt; Thu, 24 Aug 2006 12:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIAj-0003O0-02 for idr@ietf.org; Thu, 24 Aug 2006 12:35:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIAh-0005M8-LM for idr@ietf.org; Thu, 24 Aug 2006 12:35:12 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2006 09:35:11 -0700 X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="313637576:sNHT31489900" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OGZAlC030722; Thu, 24 Aug 2006 09:35:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7OGZA6a025361; Thu, 24 Aug 2006 09:35:10 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 09:35:10 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 09:35:10 -0700 Message-ID: <44EDD53D.4050404@cisco.com> Date: Thu, 24 Aug 2006 09:35:09 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <007801c6c75a$9e2d70c0$260218ac@rs.riverstonenet.com> In-Reply-To: <007801c6c75a$9e2d70c0$260218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 16:35:10.0351 (UTC) FILETIME=[442101F0:01C6C79B] DKIM-Signature: a=rsa-sha1; q=dns; l=2702; t=1156437310; x=1157301310; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=dyPj9GdITEudTzfJ+1FwKedUJ6tCLoUVQ0ZYX2b9irGBlB8VaVIPOUwUdU2Ovzwe+4SYi6cM rr/AlPI1xtKRlvJDaKQZ/cUSoArrLP6v2MZ0rDYtEaBI8NDqeBePQhsA; Authentication-Results: sj-dkim-7.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav: Manav Bhatia wrote: >Enke, > > > >>multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they >>are no longer valid (replaced by B1 and B2), in other words >>how does RR2 >>figure out (X, N11) is a replacement of (X, N1), and (X, N22) a >>replacement of (X, N2)? >> >> >> > >UPDATE: unfeasible nlri X, multiple_hop N1 >UPDATE: unfeasible nlri X, multiple_hop N2 >UPDATE: feasible nlri X, multiple_hop N11, >UPDATE: feasible nlri X, multiple_hop N12, > > Ok, so (X, N1) and (X, N2) have to be explicitly withdrawn in your scheme. That means more updates. Perhaps what is more challenging here is that RR1 must withdraw (X, N1) before advertising (X, N11). How do you guarantee the ordering in an imploementation? - maintain extra state to keep track of which nexthop address was advertised to which peer. This would mean more states and more memory, or - hanging on the path (X, N1) replaced by (X, N11) until (X, N1) is explicitly withdraw from RR2? The means keeping both (X, N1) and (X, N11) which incurs more memory, and couples the Tx and Rx. What happens if (X, N111) is received before (X, N1) is withdrawn? Do you keep (X, N111) and in order as well? This can easily get out of hand. Please see my previous comment on de-coupling Tx from Rx: --------------------------------------------------------------------------- In addition, it is desirable and typical in implementations to have the receiving processing de-coupled from the sending processing (in order to keep less state). It means that at the time of sending update the info (such as the nexthop) for the old path may no longer available. I am not sure if your proposal requires an implementation to keep track of the nexthops advertised to a peer for the purpose of figuring out when to use the NEXTHOP attribute or the MULTI-NEXTHOP attribute. --------------------------------------------------------------------------- >I think we can each come up with a scenario where one scheme would be more >optimal and would involve lesser number of UPDATEs than the other. > > I strongly disagree because of these reasons: 1) More updates are generated by your proposal due to the need for explicit withdraws as shown in the example. 2) As a new attribute is introduced in your proposal, the efficiency of prefix packing will be lower, resulting in more updates. It's shown that the prefix packing efficiency has a huge impact on the performance of update processing (both Tx and Rx). I would welcome an example that shows otherwise. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 12:42:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIHK-0006rK-BH; Thu, 24 Aug 2006 12:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIHJ-0006rF-It for idr@ietf.org; Thu, 24 Aug 2006 12:42:01 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIHI-0006CP-CP for idr@ietf.org; Thu, 24 Aug 2006 12:42:01 -0400 X-TACSUNS: Virus Scanned Received: from rtp-cse-489.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k7OGfxQ24196; Thu, 24 Aug 2006 12:41:59 -0400 (EDT) Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7p1+Sun/8.11.6) with ESMTP id k7OGfxL01034; Thu, 24 Aug 2006 12:41:59 -0400 (EDT) Date: Thu, 24 Aug 2006 12:41:59 -0400 (EDT) From: Daniel Walton To: yakov@juniper.net, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.6 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Alvaro Retana , idr@ietf.org Subject: [Idr] (no subject) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello Yakov, Sue, We would like to ask for draft-walton-bgp-add-paths-05.txt to be accepted as an IDR WG document. Thanks Daniel _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIxV-000398-Ut; Thu, 24 Aug 2006 13:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIxU-00037E-AF for idr@ietf.org; Thu, 24 Aug 2006 13:25:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIp1-0004A2-L7 for idr@ietf.org; Thu, 24 Aug 2006 13:16:51 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGIoz-0001DJ-Pm for idr@ietf.org; Thu, 24 Aug 2006 13:16:51 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/uzvX6RYlW2wyIHLDMcWpBomsCWOm3+w4@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OHGTI5004438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 18:16:42 +0100 Date: Thu, 24 Aug 2006 18:16:29 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44ED48AC.1020702@cisco.com> Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44ED48AC.1020702@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -1.9 (-) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: "Joel M. Halpern" , Inter-Domain Routing List , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Enke, On Wed, 23 Aug 2006, Enke Chen wrote: > I am not sure what you meant by "same implementation view, and > dependent upon a particular implementation". In the add-path > proposal, the advertiser is responsible for allocating the > identifier suitable for a particular application, and the receiver > needs to use the (prefix, path-identifier) to identify a path to be > replaced. I believe that part is clear in the proposal, but if it > is not, we'll need to make it clear. That the sender must pick the identifier is quite clear. It's also clear the draft leaves that as an implementation matter. The problem, and Joel's point (I think), is that in not giving any guidance on how this identifier is to be picked, implementations will settle on picking this identifier in a deficient way. E.g. particularly as the draft suggests that router-ID is one possible choice of such identifier (and indeed you suggest same the below). Such a choice would not work for re-advertising multiple paths, e.g. a cluster of route-reflectors: RR1-RR2 / | | A B C Say A, B and C all advertise a certain NLRI, P. RR1 and RR2 use add-path with their clients and between themselves so as to allow all paths to be distributed to all RR-clients. Both the RR implementations go for the simple approach (as suggested in the draft and your email) of using the router-ID of the speaker a path was received from as the Add-Path-ID. So RR1 sends to RR2: UPDATE: feasible P:A, UPDATE: feasible P:B, Where X:Y is: add-path NLRI for Prefix X and add-path-id of Y. Now, how should RR2 advertise these to its clients? It clearly can not blindly just use the Router-ID of the speaker it received the paths from (RR1 in both cases). It could however just reuse the path-ids. So the RR's add-path implementation now becomes (wrt choosing Add-Path-ID): "If the received path already has a path-ID, and no other received paths have the same, just re-use that path-id. Otherwise, use the Router-ID of speaker the path was received from" So now RR2 /can/ easily advertise the two paths received from RR1 to C and D. However, our friendly BGP network administrator now figures out he really ought to have clients peer with both RRs, he does so for B (e.g. A and C's sessions to other RR may be broken for some reason): RR1-RR2 / |/ | A B C RR2 now has recieved: >From RR1: P:A P:B >From B: P What should it advertise to C? The choices seem to be: - Figure out that P and P:B are the exact same path (e.g. they'll have the exact same next-hop..), and advertise just P:B to C. - remember, that RR1 used 'B' as the path-ID is wholly at the discretion of RR1 - the nexthop however... or - Advertise both P:B and P:B' to C - where B' is some constructed identifier for the path for P received from B It seems to us that behaviour of the add-path draft with RR clusters may be quite indeterminable, given that the issue of the additional path-identifier is left completely at the discretion of speakers. One could say "Ah, but ORIGINATOR_ID can be used!", but that's a route-reflection specific attribute. It won't work for other cases that could make use of add-path, e.g. ECMP.. Also, for ECMP, a lot of the details of whether not multiple-paths should be advertised or else whether or not the AS_PATH must be 'ECMP aggregated' revolve around next-hop. > the routes (simulating full-mesh). It is actually the (prefix, > router-id) that would identify a path instead of the prefix itself. And see above :) > As the issue of how to identify a path is so fundamental to a solution, I > hope that it can be clarified before we dive into other details. Yep, fully agreed. And for any two paths to the same destination a speaker may have, the next-hop(s) serve(s) as an identity, regardless of other attributes of the paths. - if they are not to the same remote speaker, the paths obviously are different (at least in that "plane" of routing) - if they are the same, the two paths are effectively the same, regardless of the other attributes. We maintain so anyway and think it to be fundamental to routing. In which case, we might as well make use of this property, rather than having speakers left to reinvent identifiers, which we think is not quite as easy and problem-free in the general case as it is for simple RR cases. So the question is how to settle the matter of the additional identifier.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Populus vult decipi. [The people like to be deceived.] _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:58:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJR7-000206-Tc; Thu, 24 Aug 2006 13:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJR6-0001zw-75 for idr@ietf.org; Thu, 24 Aug 2006 13:56:12 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJR3-0005Tb-Dz for idr@ietf.org; Thu, 24 Aug 2006 13:56:12 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18Ob5eyfjl5lBJUQcYB+eW51vXmt5u1x8A@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OHtlUP005323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 18:55:59 +0100 Date: Thu, 24 Aug 2006 18:55:46 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44ED655E.8020702@cisco.com> Message-ID: References: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> <44ED655E.8020702@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, Enke Chen wrote: >> RR1 would advertise the following UPDATEs to RR2. >> >> UPDATE: feasible nlri X, next_hop N1, >> UPDATE: feasible nlri X, multiple_hop N11, >> UPDATE: feasible nlri X, multiple_hop N2, >> UPDATE: feasible nlri X, multiple_hop N22, >> > > Please note that B1 and B2 are clients and do not advertise > multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as > they are no longer valid (replaced by B1 and B2), in other words > how does RR2 figure out (X, N11) is a replacement of (X, N1), and > (X, N22) a replacement of (X, N2)? They don't need to. The first above, with NEXT_HOP (or MP_REACH for MP) continues to imply a full implicit withdrawal of the NLRI. So with that first UPDATE all the previous (NLRI,nexthops) are withdrawn. Further, if are the same for the above paths, it can be done in just one UPDATE. UPDATE: feasible nlri X, NEXT_HOP N1, MULTIPLE_HOP N11, N2, N22 If, say, all but (X,N22) had the same attributes, then the following would be sent: UPDATE: feasible nlri X, NEXT_HOP N1, MULTIPLE_HOP N11, N2 UPDATE: feasible nlri X, MULTIPLE_HOP N22 <(X,N22) attributes> regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Snow Day -- stay home. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUW-0002RD-EB; Thu, 24 Aug 2006 13:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUS-0002Pv-Mm for idr@ietf.org; Thu, 24 Aug 2006 13:59:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUR-0006f9-GG for idr@ietf.org; Thu, 24 Aug 2006 13:59:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 13:59:40 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208"; a="98484089:sNHT29649900" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxd2T029154; Thu, 24 Aug 2006 13:59:39 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdR018668; Thu, 24 Aug 2006 13:59:38 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <92c950310608231052j492c13dej7d8ee7ea7fa5428b@mail.gmail.com> References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> <92c950310608231052j492c13dej7d8ee7ea7fa5428b@mail.gmail.com> Date: Thu, 24 Aug 2006 12:30:35 -0400 To: "Glen Kent" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=779; t=1156442379; x=1157306379; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt |To:=22Glen=20Kent=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=QgQ6EinHUDtN07yrXBJztkwHUoC+eY2NxkB96mVOz7Cy2tm+aFRFGhOzwpDmQtO/AUvakfpK CBPxmAcnDgbHbEGIbLiiflQuwCHnQlgW5p7H0qhwzHEVPLKIA+y4pRF2; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 11:22 PM +0530 8/23/06, Glen Kent wrote: >>- By keying on NLRI, nexthop (rather than just NLRI), you are precluding >> the sending of multiple distinct paths that share the same nexthop. >> We'll likely want to be able to do this for ECMP. Additionally, > >an RR cant set next-hop-self so it would never send paths with same >next-hop. You could send this in EBGP, but then for EBGP would you >really send separate individual path attributes? Perhaps not (though you never know). However, to a confederation peer (i.e. in a different AS within your own confederation)? Yes. I agree with Jeff that the lack of ability to send multiple paths for a given next hop is a deficiency -- if for no other reason that it's an unnecessary restriction. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUg-0002g2-MT; Thu, 24 Aug 2006 13:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUd-0002dq-BN for idr@ietf.org; Thu, 24 Aug 2006 13:59:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUc-0006ei-3z for idr@ietf.org; Thu, 24 Aug 2006 13:59:51 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:50 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902677:sNHT24855628" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxnwg030719; Thu, 24 Aug 2006 13:59:49 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdb018668; Thu, 24 Aug 2006 13:59:48 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <007801c6c75a$9e2d70c0$260218ac@rs.riverstonenet.com> References: <007801c6c75a$9e2d70c0$260218ac@rs.riverstonenet.com> Date: Thu, 24 Aug 2006 13:55:29 -0400 To: "Manav Bhatia" From: "John G. Scudder" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1634; t=1156442389; x=1157306389; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:RE=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt |To:=22Manav=20Bhatia=22=20; X=v=3Dcisco.com=3B=20h=3DDfj/sbQHz0fG9465oH4ef1CAC70=3D; b=BHX7+jUPq7JcGuI8Go/vN6AtkzRZR+mrXlTDCl0crw5/milevtPLPXdljyV/NwINFQjnlDJH yo92i3y4g3OlbpIoNwTPIl6xvrEcQ0nEwgbB9Ow/kNghaPnksfJbx1TQ; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 2:22 PM +0530 8/24/06, Manav Bhatia wrote: >Enke, > >>multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they >>are no longer valid (replaced by B1 and B2), in other words >>how does RR2 >>figure out (X, N11) is a replacement of (X, N1), and (X, N22) a >>replacement of (X, N2)? >> > >UPDATE: unfeasible nlri X, multiple_hop N1 >UPDATE: unfeasible nlri X, multiple_hop N2 >UPDATE: feasible nlri X, multiple_hop N11, >UPDATE: feasible nlri X, multiple_hop N12, > >I think we can each come up with a scenario where one scheme would be more >optimal and would involve lesser number of UPDATEs than the other. Sure. In terms of implementation overhead, I don't think you've addressed Enke's original point though, which was that the full sequence on the RR is: - Receive X, N1 from client - Advertise X, N1 to peer RR - Receive X, N11 from client ==> at this point a conventional implementation might simply free the memory used to store N1 and somehow queue the replacement, X, N11 for advertisement. However, a multiple-hop implementation would have to retain N1 (marked as deleted or the like) until all peers had been updated -- since N1 is used as part of the key in the withdrawal. - Followed by updates as you've noted above The point here isn't that this is necessarily a show-stopper. However, I think it does demonstrate that until one carefully considers the implications in a real implementation, it's dangerous to make sweeping statements about how one proposal is simpler than other. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUW-0002S0-Uc; Thu, 24 Aug 2006 13:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUU-0002Qv-PL for idr@ietf.org; Thu, 24 Aug 2006 13:59:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUT-0006f9-HR for idr@ietf.org; Thu, 24 Aug 2006 13:59:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 13:59:42 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208"; a="98484097:sNHT33950576" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxfcD029172; Thu, 24 Aug 2006 13:59:41 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdT018668; Thu, 24 Aug 2006 13:59:40 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> Date: Thu, 24 Aug 2006 13:48:58 -0400 To: Paul Jakma From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1917; t=1156442381; x=1157306381; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt |To:Paul=20Jakma=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=oFnppHsoOH2mhVceVQMOKXAIqWJjXkpmkBalQ+1EDIB2x5diV54mJ5OGIk471atohCMV+9mj WgNLO3ufEU4aWTDmR85vARKk8JwH4jfnE/f8bbfAE+1A5YThpj/bRQrR; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Robert Raszuk , "Joel M. Halpern" , Paul Jakma , Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Paul, At 10:12 PM +0100 8/23/06, Paul Jakma wrote: >>PS. The stated issue with add-path's drawback to require uniqe >>identifier to be generated by BGP speaker is not IMHO at all a problem. > >The draft should perhaps say how. > >We are reasonably certain there are issues with all but simple >reflector cases - any case where one wishes multiple paths to be >/readvertised/ can not use identifiers derived from the identity of >from whom the route was learnt (e.g. router-ID). So the speaker is >left to construct some identifier specific to the peer the speaker >is sending the path to, for that path. > >Which seems redundant to us as such an identifier already exists in >all the BGP AFI/SAFIs we have considered -> the nexthop. It's been quite a while since we wrote that draft so I'm having to refresh my memory, but we did consider the concerns you describe while writing it. Some responses: As to "say how" -- we specifically wanted to avoid prescribing how to derive the path identifier, since what's the point of a semantics-free identifier if the specification goes and forces a particular algorithm on you? As I said in my note to Joel, I just don't see this as a very difficult problem. Do you? As to the re-advertisement case -- yes, the path identifier has to be reconstructed. Again, this seems to me a simple problem. As to redundancy -- if you can make the case convincingly that there is never, under any circumstance, a case where one might want to advertise more than a single route with a given next hop, then I think you have a strong argument. I'm not convinced of this premise yet, however. (See previous message with example involving confederations, for one.) If indeed there is ever a case where you want to advertise two routes with the same next hop, then the path identifier is not redundant. Regards, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUb-0002Zj-4M; Thu, 24 Aug 2006 13:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUZ-0002To-U3 for idr@ietf.org; Thu, 24 Aug 2006 13:59:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUY-0006ei-Md for idr@ietf.org; Thu, 24 Aug 2006 13:59:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902668:sNHT26219636" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxkPB029224; Thu, 24 Aug 2006 13:59:46 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdX018668; Thu, 24 Aug 2006 13:59:44 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> References: <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com><44EC07A3.7000304@cis co.com><7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com><44EC6277.80900 00@cisco.com><44EC7783.6 060405@cisco.com> <20060823155632.GB13706@scc.mi.org><20060823172415.GF13706@scc.mi.org><92c950310608231052j492c13de j7d8ee7ea7fa5428b@mail.gmail.com> <20060823181150.GG13706@scc.mi.org> <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> Date: Thu, 24 Aug 2006 13:50:56 -0400 To: "Manav Bhatia" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=849; t=1156442386; x=1157306386; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt |To:=22Manav=20Bhatia=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=ptuRDK06/uMepBfuCBFh1qfk1nXTvk+ntSuXbhDrglVIDexB415rNb2r49n4vLGKD7a32XFO iO/OH0rW/J0vi4kuHP7TtUkEBTGdrOoWLhY2Sk/Eg8EpRJ5HARP/FSwp; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 6:59 AM +0530 8/24/06, Manav Bhatia wrote: >Between Multiple-Hop capable speakers, the MULTIPLE_HOP attribute >MUST be used in addition to the existing NEXT_HOP/MP_REACH_NLRI in >order to announce multiple next-hops for the destinations listed in >the NLRI/MP_REACH_NLRI of the UPDATE message. If the speaker has >installed one of the next-hops concerned in its FIB, then that >particular next-hop MUST be listed in the NEXT_HOP/MP_REACH_NLRI >attribute. > >This is possible in our approach, but can *never* be done in add-paths btw. If indeed it's important to flag installed vs. non-installed routes, it's clearly easy enough to extend either proposal to do so. I don't think this is an interesting point of comparison. Also, see my other message for why I think using NEXT_HOP in this way is a bad idea. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUT-0002QC-2g; Thu, 24 Aug 2006 13:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUR-0002Pp-Pg for idr@ietf.org; Thu, 24 Aug 2006 13:59:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUQ-0006ei-I4 for idr@ietf.org; Thu, 24 Aug 2006 13:59:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902639:sNHT22756180" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxbmq029146; Thu, 24 Aug 2006 13:59:37 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdP018668; Thu, 24 Aug 2006 13:59:37 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> Date: Thu, 24 Aug 2006 12:30:04 -0400 To: "Joel M. Halpern" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2347; t=1156442377; x=1157306377; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20=20draft-bhatia-bgp-multiple-next-hops- 01.txt |To:=22Joel=20M.=20Halpern=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=iFFB2NUclr5b/pCRw4vvjcIetY9Q7J+vCTu+Rxfdnu5X0ILr7wpiTzR6jDUxFkfZqaeAdEgr GyyAkGIBDLptILlLo7NecG/n02e605e1Bfv3u4EQR1PWltwQJjZGSXm6; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joel, Elegance is very much in the eye of the beholder, which is why I'd rather not appeal to it in discussing these things, but rather stick to facts. What I like about the add-path approach is exactly that it doesn't impute any particular semantics to the path identifier. I think it's instructive that OSPF used to use the prefix as its database key and has finally moved away from that in OSPFv3. I don't understand your apparent concern about how to choose the path identifier. Surely this is a problem that can be solved by any moderately skilled undergraduate. --John At 7:58 AM -0400 8/23/06, Joel M. Halpern wrote: >Enke, I have real trouble with your characterization of your draft. >You claim it is simple and elegant. >From where I sit, it introduces a new identifier that must be shared >between the routers. That identifier has to be assigned and managed >by the advertising router in such a way that it is unique for each >path that needs advertised (under all possible circumstances). But >it has to be used by the receiver no matter how the sender has >chosen to allocate / create it. As such, if the two happen to have >the same implementation view they may find it simple. But it is >quite dependent upon that implementation. >While our draft makes use of information that was already being >exchanged to provide the necessary disambiguation. I would argue >that such is in fact both simpler and more elegant. > >At the same time, your claim of greater flexibility is in fact not >backed up by need. We previously had support for advertising paths >with different attributes but the same NLRI and the same next-hop. >In discussion with folks we realized that there was no actual use >case where you need the differentiation. Either the advertiser is >in the path (next-hop self) in which case preserving the paths does >not add information, even for the route oscillation case, or the >advertiser is preserving the next-hop information in which case the >next hops provide the needed differentiation. Thus, using the >next-hop as an added differentiator provides exactly the flexibility >needed by the problem, and is much simpler, more amenable to >variations in implementations strategies, and more robust. > >Yours, >Joel M. Halpern ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUb-0002Zj-4M; Thu, 24 Aug 2006 13:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUZ-0002To-U3 for idr@ietf.org; Thu, 24 Aug 2006 13:59:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUY-0006ei-Md for idr@ietf.org; Thu, 24 Aug 2006 13:59:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902668:sNHT26219636" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxkPB029224; Thu, 24 Aug 2006 13:59:46 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdX018668; Thu, 24 Aug 2006 13:59:44 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> References: <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com><44EC07A3.7000304@cis co.com><7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com><44EC6277.80900 00@cisco.com><44EC7783.6 060405@cisco.com> <20060823155632.GB13706@scc.mi.org><20060823172415.GF13706@scc.mi.org><92c950310608231052j492c13de j7d8ee7ea7fa5428b@mail.gmail.com> <20060823181150.GG13706@scc.mi.org> <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> Date: Thu, 24 Aug 2006 13:50:56 -0400 To: "Manav Bhatia" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=849; t=1156442386; x=1157306386; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt |To:=22Manav=20Bhatia=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=ptuRDK06/uMepBfuCBFh1qfk1nXTvk+ntSuXbhDrglVIDexB415rNb2r49n4vLGKD7a32XFO iO/OH0rW/J0vi4kuHP7TtUkEBTGdrOoWLhY2Sk/Eg8EpRJ5HARP/FSwp; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 6:59 AM +0530 8/24/06, Manav Bhatia wrote: >Between Multiple-Hop capable speakers, the MULTIPLE_HOP attribute >MUST be used in addition to the existing NEXT_HOP/MP_REACH_NLRI in >order to announce multiple next-hops for the destinations listed in >the NLRI/MP_REACH_NLRI of the UPDATE message. If the speaker has >installed one of the next-hops concerned in its FIB, then that >particular next-hop MUST be listed in the NEXT_HOP/MP_REACH_NLRI >attribute. > >This is possible in our approach, but can *never* be done in add-paths btw. If indeed it's important to flag installed vs. non-installed routes, it's clearly easy enough to extend either proposal to do so. I don't think this is an interesting point of comparison. Also, see my other message for why I think using NEXT_HOP in this way is a bad idea. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUT-0002QC-2g; Thu, 24 Aug 2006 13:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUR-0002Pp-Pg for idr@ietf.org; Thu, 24 Aug 2006 13:59:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUQ-0006ei-I4 for idr@ietf.org; Thu, 24 Aug 2006 13:59:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902639:sNHT22756180" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxbmq029146; Thu, 24 Aug 2006 13:59:37 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdP018668; Thu, 24 Aug 2006 13:59:37 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> Date: Thu, 24 Aug 2006 12:30:04 -0400 To: "Joel M. Halpern" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2347; t=1156442377; x=1157306377; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20=20draft-bhatia-bgp-multiple-next-hops- 01.txt |To:=22Joel=20M.=20Halpern=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=iFFB2NUclr5b/pCRw4vvjcIetY9Q7J+vCTu+Rxfdnu5X0ILr7wpiTzR6jDUxFkfZqaeAdEgr GyyAkGIBDLptILlLo7NecG/n02e605e1Bfv3u4EQR1PWltwQJjZGSXm6; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joel, Elegance is very much in the eye of the beholder, which is why I'd rather not appeal to it in discussing these things, but rather stick to facts. What I like about the add-path approach is exactly that it doesn't impute any particular semantics to the path identifier. I think it's instructive that OSPF used to use the prefix as its database key and has finally moved away from that in OSPFv3. I don't understand your apparent concern about how to choose the path identifier. Surely this is a problem that can be solved by any moderately skilled undergraduate. --John At 7:58 AM -0400 8/23/06, Joel M. Halpern wrote: >Enke, I have real trouble with your characterization of your draft. >You claim it is simple and elegant. >From where I sit, it introduces a new identifier that must be shared >between the routers. That identifier has to be assigned and managed >by the advertising router in such a way that it is unique for each >path that needs advertised (under all possible circumstances). But >it has to be used by the receiver no matter how the sender has >chosen to allocate / create it. As such, if the two happen to have >the same implementation view they may find it simple. But it is >quite dependent upon that implementation. >While our draft makes use of information that was already being >exchanged to provide the necessary disambiguation. I would argue >that such is in fact both simpler and more elegant. > >At the same time, your claim of greater flexibility is in fact not >backed up by need. We previously had support for advertising paths >with different attributes but the same NLRI and the same next-hop. >In discussion with folks we realized that there was no actual use >case where you need the differentiation. Either the advertiser is >in the path (next-hop self) in which case preserving the paths does >not add information, even for the route oscillation case, or the >advertiser is preserving the next-hop information in which case the >next hops provide the needed differentiation. Thus, using the >next-hop as an added differentiator provides exactly the flexibility >needed by the problem, and is much simpler, more amenable to >variations in implementations strategies, and more robust. > >Yours, >Joel M. Halpern ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUY-0002T0-Hz; Thu, 24 Aug 2006 13:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUW-0002Rl-G7 for idr@ietf.org; Thu, 24 Aug 2006 13:59:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUV-0006ei-A5 for idr@ietf.org; Thu, 24 Aug 2006 13:59:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902657:sNHT21443348" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxgXP030652; Thu, 24 Aug 2006 13:59:42 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdV018668; Thu, 24 Aug 2006 13:59:41 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> Date: Thu, 24 Aug 2006 13:50:12 -0400 To: Paul Jakma From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=456; t=1156442382; x=1157306382; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt |To:Paul=20Jakma=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=StZOSFsfReOT2EJUSA1Zzy0Yexk3NSblo2znudnd/uUcjUJKiaEW+vXM9x2eHYNGIOLr/A2O 3LAXXmoPOseaRJ91TynWNoKbMAaKJMZ90VLU0nRDARG06GT7tKIbZUNN; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 11:46 PM +0100 8/23/06, Paul Jakma wrote: >This isn't an issue. Only useable paths can be advertised. If true that seems like a deficiency, since it may be desirable in some cases to advertise non-used but feasible routes (e.g., "best external") for reasons of fast convergence. I'm not sure whether such routes need to be explicitly labeled as not used for forwarding, but I am moderately sure we don't want to preclude them. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUd-0002dA-7U; Thu, 24 Aug 2006 13:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUc-0002bS-5j for idr@ietf.org; Thu, 24 Aug 2006 13:59:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUZ-0006qB-QP for idr@ietf.org; Thu, 24 Aug 2006 13:59:50 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 10:59:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="37902670:sNHT23642166" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxl9Y030703; Thu, 24 Aug 2006 13:59:47 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdZ018668; Thu, 24 Aug 2006 13:59:46 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> Date: Thu, 24 Aug 2006 13:54:29 -0400 To: "Manav Bhatia" From: "John G. Scudder" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=3137; t=1156442387; x=1157306387; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:RE=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt |To:=22Manav=20Bhatia=22=20; X=v=3Dcisco.com=3B=20h=3DDfj/sbQHz0fG9465oH4ef1CAC70=3D; b=SJQoogkTNavMdRyfGOWNXewipk2c3mId8Qa7jrIac8hyObCpKolEr1B0n7anTPYbloIxvIIj yzNAj2qKeNEnBKk51I4sGHBba5Ot2vRsJ03PkjBX6Nobvxeq1bR7Wr8/; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'Robert Raszuk' , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 11:20 AM +0530 8/24/06, Manav Bhatia wrote: > > PS. The stated issue with add-path's drawback to require uniqe >> identifier to be generated by BGP speaker is not IMHO at all a problem. > >It is really. > >The suggested scheme becomes mucky I won't take that personally, but I do suggest that you may want to consider your choice of adjectives in the future. Glass houses, stones, etc. >and fragile when one has to readvertise >the multiple paths that it has received, because it can then no longer use >the Router ID to disambiguate the paths. The speaker is then left to >construct some unique arbitrary identifier specific to the peer the speaker >is sending the path to, for those paths. > >A >| >B C > \ / > D > > >Assume A sends two routes x1:10/8, x2:10/8, where x1 and x2 are the router >IDs of the peers A received these routes from, to B. > >How does B announce these routes forward to D? > >It has to generate and manage unique path IDs which now, are neither based >on router IDs nor derived from AS numbers, etc. Something that the draft >conveniently prefers to skim over. Actually, something that the draft deliberately chooses to remain silent on because we didn't care to over-specify. I'm dumbfounded that so many people seem to believe that associating a unique identifier with a datum is a hard problem. I guess if we resurrect add-path, we could add an appendix with a sample algorithm, or we can just provide a reference to a standard algorithms textbook. >The use of arbitrary path IDs can >influence the amount of memory required to hold the routes on both the >routers. Omelette, eggs, etc. The additional overhead isn't very much (neighborhood of 8 bytes/route -- 4 for rx'd identifier, 4 for tx'd), but yes it does exist. >If different path IDs are used, the amount of memory needed to >store all the routes increases. You cannot simply ignore the path IDs that >you send/receive as you need to store them for performing implicit/complete >withdrawals. Well, sure. I'm not sure this is an interesting point of comparison though -- see follow up to Enke's message. >The claim therefore that add-paths "requires only minor software changes for >the vast majority of the BGP speakers in a network" is misleading and >incorrect. [1] Only speakers which wish to advertise multiple paths have to know how to generate unique path identifiers. The rest just need to know how to consume them. I guess it's in the eye of the beholder what constitutes "minor". Or maybe it's "vast". In any case, I'd rather debate specific merits rather than argue about whether it's misleading if vast is more elegant than minor. >We believe that introducing a new arbitrary identifier is redundant, complex >and prone to implementation quirks and can fail in interesting ways. We >instead use the next_hop (which is already exchanged) as the "unique >identifier". Regarding redundancy (which is the only claim above which is substantive enough to debate at this point) see my previous message to Paul. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 13:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUh-0002gl-6l; Thu, 24 Aug 2006 13:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJUf-0002fn-Ff for idr@ietf.org; Thu, 24 Aug 2006 13:59:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJUe-0006qY-83 for idr@ietf.org; Thu, 24 Aug 2006 13:59:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 13:59:53 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208"; a="98484126:sNHT29826372" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxqpr029252 for ; Thu, 24 Aug 2006 13:59:52 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdd018668 for ; Thu, 24 Aug 2006 13:59:50 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44ED48AC.1020702@cisco.com> Date: Thu, 24 Aug 2006 13:59:25 -0400 To: idr@ietf.org From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2004; t=1156442392; x=1157306392; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt |To:idr@ietf.org; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=WR4VqhU9na7zABxCDbjnycqgodkmZ8lop/S/erjqzCU4wXGP8imoL6Kwz1Mhu5SmmIWenX4j /Zt+Ce+Ni2lB+27aL+587XHDLNi+c3NNyoFIEzGICYTuRGJI+75/aQP8; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org A few other points regarding the draft -- First, the draft isn't terribly clear on the usage of "legacy" next_hop on a connection over which the multiple-hop capability has been exchanged. To take one example, if I announce: R1: (P, next_hop N1, other attributes) R2: (P, multiple_next_hop N2, other attributes) can I subsequently withdraw R1 by means of an update which lists N1 in the multiple_next_hop attribute? I'd assume so, but the mixing of next_hop and multiple_next_hop leaves room for confusion. (Other comments to the list have exhibited the same confusion so I think it's not just me.) I'd suggest dropping use of next_hop at all on multiple-hop connections, for clarity. Instead, mandate that all next hop information is carried in multiple_next_hop. As far as I can tell, the only well-defined use of next_hop in the document right now is if you want to implicitly withdraw N routes and replace them with M routes (but where all M share one set of path attributes). That seems like an unnecessary corner case optimization, especially since you've already disclaimed interest in other implicit withdraw cases (where the next hop changes). If you don't want to make this change then I think you at least need to clarify the implicit withdraw semantics in the presence of next_hop, as Paul did -- At 5:26 PM +0100 8/23/06, Paul Jakma wrote: > The UPDATE replaces all existing paths for the NLRI with the > paths of identities (NLRI,next-hop) as given by the > 'normal' next-hop attribute and those nexthops in the > MULTIPLE_NEXT_HOP, if that attribute is present. This is NOT clear in the doc. Second, the draft specifies a set of flags in the multiple-hop capability. The only defined flag is the "receive multiple" flag. Under what circumstances would a router ever advertise the capability without setting the RM flag? Third, you misspelled "Traina" in your references section. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 14:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJZS-0004g8-Aq; Thu, 24 Aug 2006 14:04:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJZQ-0004bM-A9 for idr@ietf.org; Thu, 24 Aug 2006 14:04:48 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJZP-0007sC-GT for idr@ietf.org; Thu, 24 Aug 2006 14:04:48 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+dTq/283miABexGg9VBCWX2gTR/niPDGA@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OI4UVH005599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 19:04:43 +0100 Date: Thu, 24 Aug 2006 19:04:30 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EDD53D.4050404@cisco.com> Message-ID: References: <007801c6c75a$9e2d70c0$260218ac@rs.riverstonenet.com> <44EDD53D.4050404@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Manav Bhatia , paul.jakma@sun.com, Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, Enke Chen wrote: > Ok, so (X, N1) and (X, N2) have to be explicitly withdrawn in your > scheme. Either that or resend all remaining paths for the NLRI in their entirety (implicitely withdrawing all previous paths for same NLRI). See other reply too. > That means more updates. Perhaps what is more challenging here is > that RR1 must withdraw (X, N1) before advertising (X, N11). It doesn't, the UPDATE for (X,N11) can be sent before explicitely withdrawing (X, N1), if an implementation wishes. > How do you guarantee the ordering in an imploementation? Not needed. They are different paths in this scheme. I don't actually see a difference in the implementation requirements here between the two drafts. Either implementation must either be able to reliably construct the identifier from (path, speaker path is to be sent to), or else keep state specific to each (path,speaker sent to). > Please see my previous comment on de-coupling Tx from Rx: Yes, agree this is highly desirable. The multiple-hops case occasionally will have to generate multiple messages in the Tx path for one path change, which shouldn't be a problem. But there's no need for it to be coupled to Rx. > --------------------------------------------------------------------------- > In addition, it is desirable and typical in implementations to have the > receiving processing de-coupled from the sending processing (in order to > keep less state). It means that at the time of sending update the info > (such as the nexthop) for the old path may no longer available. I am not > sure if your proposal requires an implementation to keep track of the > nexthops advertised to a peer for the purpose of figuring out when to use the > NEXTHOP attribute or the MULTI-NEXTHOP attribute. > --------------------------------------------------------------------------- If the implementation has the ability to advertise the same path with different nexthops to different speakers, yes it almost certainly would have to keep state on that. I don't think this is much different from add-path, which also would need to keep state on identifiers it has used for each peer and path. >> I think we can each come up with a scenario where one scheme would be more >> optimal and would involve lesser number of UPDATEs than the other. >> > > I strongly disagree because of these reasons: > > 1) More updates are generated by your proposal due to the need for > explicit withdraws as shown in the example. Though, this would be true only when the nexthop changes for a path. - If the nexthop is the same, multiple-hops can update it with with an implicit withdraw. - On the flip side, multiple-hops can bunch together paths whose attributes are all (bar nexthop(s)) equal. - Add-path must always send distinct UPDATEs (with all attributes) for all paths which differ only by (NLRI,nexthop). I don't know which would use more or less bandwidth in the real world. But we suspect next-hops are comparitively stable compared to full path changes. > 2) As a new attribute is introduced in your proposal, the efficiency of > prefix packing will be lower, resulting in more updates. > It's shown that the prefix packing efficiency has a huge impact on the > performance of update processing (both Tx and Rx). > I would welcome an example that shows otherwise. We could encode the nexthop identifiers in the NRLI quite easily. I, personally, hate to see message formats redefined. If the 'traditional' NLRI in BGP-4 no longer meets todays needs, we ought to deprecate it and properly define a new UPDATE message, but hey. But if mushing UPDATE is fine, multiple-hop could do so too. The identity question is still the tricky one here :). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Question: Is it better to abide by the rules until they're changed or help speed the change by breaking them? _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 14:20:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJnn-0006y9-Ie; Thu, 24 Aug 2006 14:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGJnm-0006x7-VX for idr@ietf.org; Thu, 24 Aug 2006 14:19:38 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGJnl-0003UD-KJ for idr@ietf.org; Thu, 24 Aug 2006 14:19:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Aug 2006 11:19:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OIJbjY007832; Thu, 24 Aug 2006 11:19:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7OIJa1E001836; Thu, 24 Aug 2006 11:19:36 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 11:19:36 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 11:19:36 -0700 Message-ID: <44EDEDB8.303@cisco.com> Date: Thu, 24 Aug 2006 11:19:36 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 18:19:36.0704 (UTC) FILETIME=[DB2A9800:01C6C7A9] DKIM-Signature: a=rsa-sha1; q=dns; l=984; t=1156443577; x=1157307577; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3D1TvTQ4hEIHLcURaCM+jLeUnTslg=3D; b=l/28kO+uiwmW7S03JXeBS4tRn5wuKLfDhM8Po0VdRYNorjBQWCwAS9MAfvZUnHKBfvqw4BL1 RlnGsLvVSiP6nE8r0f3w2lgKPBWt0t2vYarQTqQZ91U7O60qmgSPkc3y; Authentication-Results: sj-dkim-2.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Robert Raszuk' , Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John G. Scudder wrote: > [snip] > >> >> How does B announce these routes forward to D? >> >> It has to generate and manage unique path IDs which now, are neither >> based >> on router IDs nor derived from AS numbers, etc. Something that the draft >> conveniently prefers to skim over. > > > Actually, something that the draft deliberately chooses to remain > silent on because we didn't care to over-specify. Exactly, as it is trivial and implementation specific. > > I'm dumbfounded that so many people seem to believe that associating a > unique identifier with a datum is a hard problem. I guess if we > resurrect add-path, we could add an appendix with a sample algorithm, > or we can just provide a reference to a standard algorithms textbook. Let us give a trivial algorithm: For a prefix, allocate the path identifiers for paths sequentially starting from 0, do not reuse until it wraps (that will take many many years). -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 15:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGKxb-0005p8-4o; Thu, 24 Aug 2006 15:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGKxY-0005p3-VL for idr@ietf.org; Thu, 24 Aug 2006 15:33:48 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGKxX-0002Lb-TS for idr@ietf.org; Thu, 24 Aug 2006 15:33:48 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19u/pPXkHXDrnjwPOQ8Whvalsbyux4Xugo@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OJXUZ4006877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 20:33:42 +0100 Date: Thu, 24 Aug 2006 20:33:29 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Joel M. Halpern" , Inter-Domain Routing List , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, John G. Scudder wrote: > I don't understand your apparent concern about how to choose the > path identifier. Surely this is a problem that can be solved by > any moderately skilled undergraduate. :) Yes, it undoubtedly is. And they should reach the following conclusion: for readvertisement of multiple-paths to the same destination to be feasible you need to be able to determine the identity of the path from the path itself As you can not construct the additional path identifier solely from the identity of the speaker from whom you received the path, obviously, if they are to advertise multiple-paths. Hence it follows that some additional aspect of each path itself must be used to discriminate between paths to the same destination (e.g. the hash value of certain key values, or even one key value directly, such as nexthop)[1]. Our point therefore is that we should simply use next-hop as this additional path-identity, as it is emminently suited to the task. There is no value in leaving the additional identifier to local implementations, as they're going to have to come to the same conclusion, with the risk that if they do not[2] they will unable to cope with RR clusters and various other multiple-readvertisement scenarios. 1. Note that this means the stability of the Add-Path-ID depends on the stability of whatever aspect of the path is chosen to mix into the Add-Path-ID. Consider this with the point raised against Multiple-Hop by Enke that if next-hop changes, Multiple-Hop must withdraw and reannounce. The same likely will be true for add-path implementations. 2. E.g. by choosing to use identity of the speaker (Router-ID, etc..) from whom a path was received solely as the Add-Path-ID, as the add-path draft hints at, and as Enke gave as an example in this thread. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Oh, `no attitude,' eh? Not `in your face,' huh? Well, you can cram it with walnuts, ugly! -- Homer Simpson The Itchy & Scratchy & Poochie Show _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 16:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLS1-0005Tg-0b; Thu, 24 Aug 2006 16:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLRz-0005SU-KR for idr@ietf.org; Thu, 24 Aug 2006 16:05:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLRz-0006RP-Iy for idr@ietf.org; Thu, 24 Aug 2006 16:05:15 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGLRw-0005Wx-UA for idr@ietf.org; Thu, 24 Aug 2006 16:05:15 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19+ON3/J4rrMoYLeUeaY5wni6KF8mifQ3g@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OK4rs2007381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 21:05:06 +0100 Date: Thu, 24 Aug 2006 21:04:53 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: Message-ID: References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.3 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi John, On Thu, 24 Aug 2006, John G. Scudder wrote: > If true that seems like a deficiency, since it may be desirable in > some cases to advertise non-used but feasible routes (e.g., "best > external") for reasons of fast convergence. > I'm not sure whether such routes need to be explicitly labeled as > not used for forwarding, but I am moderately sure we don't want to > preclude them. We potentially could add a flag field to MULTIPLE_HOP for this, to signal this on a per-nexthop basis (and then could be used for a per-nexthop implicit withdrawal flag too), if thought to be desireable. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: I think we're all Bozos on this bus. -- Firesign Theatre _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 16:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLXU-0008R5-BW; Thu, 24 Aug 2006 16:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGLXT-0008R0-JY for idr@ietf.org; Thu, 24 Aug 2006 16:10:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLXR-000779-3r for idr@ietf.org; Thu, 24 Aug 2006 16:10:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 16:08:51 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208"; a="98511158:sNHT2225919420" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OK8p1G014269; Thu, 24 Aug 2006 16:08:51 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OK8ldN007817; Thu, 24 Aug 2006 16:08:50 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> <44EDEDB8.303@cisco.com> Date: Thu, 24 Aug 2006 16:08:45 -0400 To: Paul Jakma From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1839; t=1156450131; x=1157314131; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt |To:Paul=20Jakma=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=bzFfnEgLoZmX2dN//5cfWlDVr+N6ooIIoceBeC+lK3FTtDFN06YGq3OGS8AJCCEDQ6ZmyFou ZekeQnRHkUZbs9AqDICZi7A9WJzeCZ267d3o1/uvhuGSmgmOv+ert4nk; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Robert Raszuk' , Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 8:44 PM +0100 8/24/06, Paul Jakma wrote: >On Thu, 24 Aug 2006, Enke Chen wrote: > >>Let us give a trivial algorithm: >> >>For a prefix, allocate the path identifiers for paths sequentially >>starting from 0, do not reuse until it wraps (that will take many >>many years). > >Now you receive a path update and must pass it on to this peer, how >do you find out whether a previous path was advertised? The referent of "this" isn't clear but I'll take a shot at answering anyway. >Bear in mind, you can't just compare against peer path was received >from, because there can be multiple such paths. - Peer A sends us route R for prefix P with path ID N. - If peer A has not previously sent us a route for P with ID N, this is a new route. We store it, allocating it local ID M calculated as P->local_id++ (you get the idea I hope). Now that we have a local ID for it, we can advertise it using that ID, following whatever normal procedures we have for advertising a route to a peer. - If peer A has previously sent us a route for prefix P with path ID N, this is a replacement. We replace our local copy -- there is no need to recompute our local ID as we already have one -- and re-advertise the route using our local ID, following whatever normal procedures we have for advertising a route to a peer. I'm not sure if that answers your question or not. If the question was "how do you know if the peer previously advertised a route to us?" the answer is "you look it up, just like you do now, only considering the path ID as well". If the question was "how do you know if you previously advertised the route to your (other) peer?" the answer is "just like you do now". If I've missed the sense of your question altogether, please ask again. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 17:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGMWp-000249-GB; Thu, 24 Aug 2006 17:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGMWo-00023q-HQ for idr@ietf.org; Thu, 24 Aug 2006 17:14:18 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGMKi-0006o7-WD for idr@ietf.org; Thu, 24 Aug 2006 17:01:50 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GGMKi-0005wB-Fe; Thu, 24 Aug 2006 17:01:48 -0400 Message-Id: <7.0.1.0.0.20060824165926.0376d508@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 24 Aug 2006 17:01:45 -0400 To: "John G. Scudder" From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112055150872e371e2cc47afc4429467d3b97a6eb7231074f135350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I would not have raised elegance and simplicity as issues, except that Mr. Chen chose to assert thoser properties for his solution. As for choosing the identifiers, part of the problem is that in fact several of the proposed techniques (such as using the router-ID of the router you receive the advertisement from) will not work. The other aspect is that introducing a new identifier shared between communicating devices is natural for certain architectures, but not particularly natural for others. Yours, Joel M. Halpern At 12:30 PM 8/24/2006, John G. Scudder wrote: >Joel, > >Elegance is very much in the eye of the beholder, which is why I'd >rather not appeal to it in discussing these things, but rather stick >to facts. What I like about the add-path approach is exactly that >it doesn't impute any particular semantics to the path >identifier. I think it's instructive that OSPF used to use the >prefix as its database key and has finally moved away from that in OSPFv3. > >I don't understand your apparent concern about how to choose the >path identifier. Surely this is a problem that can be solved by any >moderately skilled undergraduate. > >--John > >At 7:58 AM -0400 8/23/06, Joel M. Halpern wrote: >>Enke, I have real trouble with your characterization of your draft. >>You claim it is simple and elegant. > From where I sit, it introduces a new identifier that must be shared >>between the routers. That identifier has to be assigned and >>managed by the advertising router in such a way that it is unique >>for each path that needs advertised (under all possible >>circumstances). But it has to be used by the receiver no matter >>how the sender has chosen to allocate / create it. As such, if the >>two happen to have the same implementation view they may find it >>simple. But it is quite dependent upon that implementation. >>While our draft makes use of information that was already being >>exchanged to provide the necessary disambiguation. I would argue >>that such is in fact both simpler and more elegant. >> >>At the same time, your claim of greater flexibility is in fact not >>backed up by need. We previously had support for advertising paths >>with different attributes but the same NLRI and the same next-hop. >>In discussion with folks we realized that there was no actual use >>case where you need the differentiation. Either the advertiser is >>in the path (next-hop self) in which case preserving the paths does >>not add information, even for the route oscillation case, or the >>advertiser is preserving the next-hop information in which case the >>next hops provide the needed differentiation. Thus, using the >>next-hop as an added differentiator provides exactly the >>flexibility needed by the problem, and is much simpler, more >>amenable to variations in implementations strategies, and more robust. >> >>Yours, >>Joel M. Halpern >... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNFv-000734-1I; Thu, 24 Aug 2006 18:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNFt-00072y-UL for idr@ietf.org; Thu, 24 Aug 2006 18:00:53 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNFr-0000Y9-Ma for idr@ietf.org; Thu, 24 Aug 2006 18:00:53 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GGNFq-0004tD-NV; Thu, 24 Aug 2006 18:00:50 -0400 Message-Id: <7.0.1.0.0.20060824175929.03547378@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 24 Aug 2006 18:00:47 -0400 To: "John G. Scudder" ,Paul Jakma From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: References: <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> <20060823155632.GB13706@scc.mi.org> <20060823172415.GF13706@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112055150872e371e2cc16856a03f0097f875a1344a043bbea60350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In once sense one can argue that it is deficiency. However, I want to avoid designing for hypothetical goals which will not be needed. Note that in the confederation border case you suggested, if the rotuer is setting next-hop to itself, then it can compress the advertisements. (In fact, typically the advertisements will have the same AS path and so the compression is not even needed.) Yours, Joel M. Halpern At 01:50 PM 8/24/2006, John G. Scudder wrote: >At 11:46 PM +0100 8/23/06, Paul Jakma wrote: >>This isn't an issue. Only useable paths can be advertised. > >If true that seems like a deficiency, since it may be desirable in >some cases to advertise non-used but feasible routes (e.g., "best >external") for reasons of fast convergence. > >I'm not sure whether such routes need to be explicitly labeled as >not used for forwarding, but I am moderately sure we don't want to >preclude them. > >--John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:10:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNOY-00039X-7H; Thu, 24 Aug 2006 18:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNOW-00039R-OX for idr@ietf.org; Thu, 24 Aug 2006 18:09:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNOU-00036M-Gv for idr@ietf.org; Thu, 24 Aug 2006 18:09:48 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 18:09:46 -0400 X-IronPort-AV: i="4.08,166,1154923200"; d="scan'208"; a="98529000:sNHT30166060" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OM9kvt004456; Thu, 24 Aug 2006 18:09:46 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OM9idN011416; Thu, 24 Aug 2006 18:09:45 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.1.0.0.20060824165926.0376d508@stevecrocker.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <7.0.1.0.0.20060824165926.0376d508@stevecrocker.com> Date: Thu, 24 Aug 2006 18:09:35 -0400 To: "Joel M. Halpern" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1199; t=1156457386; x=1157321386; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20=20=20=0A=20draft-bhatia-bgp-multiple-n ext-hops-01.txt |To:=22Joel=20M.=20Halpern=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=XIe05eAg/g29JC0UdS/RfO0y2iD1Sz5s5rpL4qgQbEDTOarOVsdOxmUl7EHtQY1Ewna2TnpC 2fwmF92DYKh3sxwcvBvvbXfJahhNXOi0G9AMYfZduOQ8C3g5B6c0MDW5; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 5:01 PM -0400 8/24/06, Joel M. Halpern wrote: >I would not have raised elegance and simplicity as issues, except >that Mr. Chen chose to assert thoser properties for his solution. OK. And I'm suggesting to all concerned that assertions of elegance, simplicity, etc, are not likely to lead to productive discussion. >As for choosing the identifiers, part of the problem is that in fact >several of the proposed techniques (such as using the router-ID of >the router you receive the advertisement from) will not work. I beg to differ, with one caveat: I see that at least the -05 add-path draft doesn't mention that the path identifier is a per-connection value (really, it can be per-speaker, the point is that it may be regenenerated by anyone who advertises the route). As long as that's understood (and I hope it'll be fixed in -06), then any algorithm whatsoever that ensures uniqueness in the local context will work just fine. >The other aspect is that introducing a new identifier shared between >communicating devices is natural for certain architectures, but not >particularly natural for others. I really don't understand this point. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNTH-0004pg-5G; Thu, 24 Aug 2006 18:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNTF-0004pU-Fv for idr@ietf.org; Thu, 24 Aug 2006 18:14:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLBy-0003pa-Fw for idr@ietf.org; Thu, 24 Aug 2006 15:48:42 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGL7z-0004pi-La for idr@ietf.org; Thu, 24 Aug 2006 15:44:37 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+9w47svC7JaaUtXvjlms7qa3ix3SrjkvY@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OJiFYo007029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 20:44:27 +0100 Date: Thu, 24 Aug 2006 20:44:15 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EDEDB8.303@cisco.com> Message-ID: References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> <44EDEDB8.303@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.2 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Robert Raszuk' , "John G. Scudder" , idr@ietf.org, Manav Bhatia X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, Enke Chen wrote: > Let us give a trivial algorithm: > > For a prefix, allocate the path identifiers for paths sequentially starting > from 0, do not reuse until it wraps (that will take many many years). Now you receive a path update and must pass it on to this peer, how do you find out whether a previous path was advertised? Bear in mind, you can't just compare against peer path was received from, because there can be multiple such paths. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: It is easier for a camel to pass through the eye of a needle if it is lightly greased. -- Kehlog Albran, "The Profit" _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNj9-00018P-6G; Thu, 24 Aug 2006 18:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNj7-00018K-4p for idr@ietf.org; Thu, 24 Aug 2006 18:31:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGLSB-0006RP-0z for idr@ietf.org; Thu, 24 Aug 2006 16:05:27 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGLFD-0005Lo-2S for idr@ietf.org; Thu, 24 Aug 2006 15:52:06 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/snVndk5H4Fr5jkczEQ9BtsHxb1izj7GE@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OJpgmi007150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 20:51:54 +0100 Date: Thu, 24 Aug 2006 20:51:42 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: Message-ID: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44EC6277.8090000@cisco.com> <44EC7783.6060405@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1725/Thu Aug 24 17:00:01 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.3 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Robert Raszuk , "Joel M. Halpern" , Paul Jakma , Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi John, On Thu, 24 Aug 2006, John G. Scudder wrote: > As to the re-advertisement case -- yes, the path identifier has to be > reconstructed. Again, this seems to me a simple problem. If it's simple, could you give one solution? The add-path draft could then incorporate it as an example, retaining the freedom of implementation the draft has as a goal. (Obviously, next-hop is one answer). The draft though seems to encourage use of speaker identities as the additional identifier. That, above all else, is what worries us. > As to redundancy -- if you can make the case convincingly that there is > never, under any circumstance, a case where one might want to advertise more > than a single route with a given next hop, then I think you have a strong > argument. I'm not convinced of this premise yet, however. (See previous > message with example involving confederations, for one.) Thanks, will have a look. > If indeed there is ever a case where you want to advertise two > routes with the same next hop, then the path identifier is not > redundant. Agreed. We can't see how such cases would arise, but let me consider your other email. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "The pathology is to want control, not that you ever get it, because of course you never do." -- Gregory Bateson _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:37:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNoW-0006A1-FX; Thu, 24 Aug 2006 18:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNoV-00069t-8o for idr@ietf.org; Thu, 24 Aug 2006 18:36:39 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNoT-00088L-Uo for idr@ietf.org; Thu, 24 Aug 2006 18:36:39 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2006 15:36:38 -0700 X-IronPort-AV: i="4.08,166,1154934000"; d="scan'208"; a="338040866:sNHT31255338" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OMabHZ024973; Thu, 24 Aug 2006 15:36:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7OMabQV023052; Thu, 24 Aug 2006 15:36:37 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 15:36:36 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 15:36:36 -0700 Message-ID: <44EE29F4.5050109@cisco.com> Date: Thu, 24 Aug 2006 15:36:36 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> <44ED655E.8020702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 22:36:36.0703 (UTC) FILETIME=[C233B6F0:01C6C7CD] DKIM-Signature: a=rsa-sha1; q=dns; l=1460; t=1156458997; x=1157322997; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DT8SdnzoHdzNLTTtPmIm9CArt9KU=3D; b=tlTpojkXzk4aeyxlTVYXTRypuxlRsSxcAAc30sQTVbfFbNsQvmVju7XkFkT+e8nlhDom7MPt rS1JK3QKwDXAFW/m0ZuVFz6FHmR6QG+7adisqSBWL4psvHGmi7SmFI3A; Authentication-Results: sj-dkim-4.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Paul: Paul Jakma wrote: > On Thu, 24 Aug 2006, Enke Chen wrote: > >>> RR1 would advertise the following UPDATEs to RR2. >>> >>> UPDATE: feasible nlri X, next_hop N1, >>> UPDATE: feasible nlri X, multiple_hop N11, >>> UPDATE: feasible nlri X, multiple_hop N2, >>> UPDATE: feasible nlri X, multiple_hop N22, >>> >> >> Please note that B1 and B2 are clients and do not advertise >> multi-paths. How do (X, N1) and (X, N2) got withdrawn on RR2 as they >> are no longer valid (replaced by B1 and B2), in other words how does >> RR2 figure out (X, N11) is a replacement of (X, N1), and (X, N22) a >> replacement of (X, N2)? > > > They don't need to. > > The first above, with NEXT_HOP (or MP_REACH for MP) continues to imply > a full implicit withdrawal of the NLRI. So with that first UPDATE all > the previous (NLRI,nexthops) are withdrawn. The update sequence described by Manav is the following: UPDATE: feasible nlri X, next_hop N1, UPDATE: feasible nlri X, multiple_hop N2, UPDATE: unfeasible nlri X, multiple_hop N1 UPDATE: unfeasible nlri X, multiple_hop N2 UPDATE: feasible nlri X, multiple_hop N11, UPDATE: feasible nlri X, multiple_hop N12, You seem to be talking about a different approach. Could you detail the sequence of updates? -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNvh-0003Gy-ID; Thu, 24 Aug 2006 18:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNvg-0003Gs-G3 for idr@ietf.org; Thu, 24 Aug 2006 18:44:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNvf-0001Uw-5y for idr@ietf.org; Thu, 24 Aug 2006 18:44:04 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2006 15:44:03 -0700 X-IronPort-AV: i="4.08,166,1154934000"; d="scan'208"; a="313788877:sNHT31616184" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OMi2LX003061; Thu, 24 Aug 2006 15:44:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7OMi2QV000199; Thu, 24 Aug 2006 15:44:02 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 15:44:02 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 15:44:02 -0700 Message-ID: <44EE2BB1.1050801@cisco.com> Date: Thu, 24 Aug 2006 15:44:01 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <7.0.1.0.0.20060824165926.0376d508@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 22:44:02.0016 (UTC) FILETIME=[CBA11600:01C6C7CE] DKIM-Signature: a=rsa-sha1; q=dns; l=1071; t=1156459442; x=1157323442; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20=20=20=20draft-bhatia-bgp-multiple-next -hops-01.txt; X=v=3Dcisco.com=3B=20h=3D1TvTQ4hEIHLcURaCM+jLeUnTslg=3D; b=Xl/rY7PXBQYTMlaPL0jnKEAVSBEhpvEFk/x1vqZKCSKsirCFq0ref7sElc8T4brNrGiDVzu9 xlIIhpfXVcB/3Bgajgg2d1eIWOhR8BN8+uYERrbWVqcNvb+BvijImCjd; Authentication-Results: sj-dkim-2.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Joel M. Halpern" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, John: John G. Scudder wrote: > >> As for choosing the identifiers, part of the problem is that in fact >> several of the proposed techniques (such as using the router-ID of >> the router you receive the advertisement from) will not work. > > > I beg to differ, with one caveat: I see that at least the -05 add-path > draft doesn't mention that the path identifier is a per-connection > value (really, it can be per-speaker, the point is that it may be > regenenerated by anyone who advertises the route). As long as that's > understood (and I hope it'll be fixed in -06), then any algorithm > whatsoever that ensures uniqueness in the local context will work just > fine. We will emphasize the "local significance" of the path identifier in the next revision, something along these text (as you suggested): The Path Identifier is locally significant. Any BGP speaker which re-advertises a route (for example, a route reflector) MAY generate its own Path Identifier to associate with the re-advertised route. Thanks. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNyu-00043w-1p; Thu, 24 Aug 2006 18:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGNys-00043l-3R for idr@ietf.org; Thu, 24 Aug 2006 18:47:22 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGNyq-0001yA-FW for idr@ietf.org; Thu, 24 Aug 2006 18:47:22 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19eNh+1RD7yPfzlkT/Qo6GyNdBojRX70og@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OMkqI8009842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 23:47:04 +0100 Date: Thu, 24 Aug 2006 23:46:52 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EE29F4.5050109@cisco.com> Message-ID: References: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> <44ED655E.8020702@cisco.com> <44EE29F4.5050109@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1726/Thu Aug 24 19:45:50 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, Enke Chen wrote: > The update sequence described by Manav is the following: Ah, I missed the unfeasible's in my quoting somehow. > UPDATE: feasible nlri X, next_hop N1, This would implicitely withdraw all previously advertised paths for the NLRI (as it does for BGP today). And announces (X,N1). RIB under X: N1: > UPDATE: feasible nlri X, multiple_hop N2, This adds the path of (X,N2). (No 'traditional' next-hop, no implicit withdraw). RIB under X: N1: ..... N2: ..... > UPDATE: unfeasible nlri X, multiple_hop N1 > UPDATE: unfeasible nlri X, multiple_hop N2 Explicit withdraw of (X,N1) and (X,N2) > UPDATE: feasible nlri X, multiple_hop N11, > UPDATE: feasible nlri X, multiple_hop N12, Advertisements of (X,N11) and (X,N12). There is no particular ordering requirement between the withdrawals of (X,N1) and (X,N2), and the advertisement of (X,N11) and (X,N12). Additionally, advertisements of paths for an NLRI whose attributes are all the same, next-hop excepted, can be sent together in the same UPDATE (as an opportunistic optimisation, same as with different NLRIs but same attrs). > You seem to be talking about a different approach. Could you detail the > sequence of updates? See above. :) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: I found Rome a city of bricks and left it a city of marble. -- Augustus Caesar _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 18:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGO8o-0000vj-2y; Thu, 24 Aug 2006 18:57:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGO8m-0000vN-Vt for idr@ietf.org; Thu, 24 Aug 2006 18:57:36 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGO8m-00048Z-B0 for idr@ietf.org; Thu, 24 Aug 2006 18:57:36 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19IslknU/dMQaiEW8bJKxLTxxkzsgnNA0Q@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7OMvIMB009935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 23:57:30 +0100 Date: Thu, 24 Aug 2006 23:57:18 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EE29F4.5050109@cisco.com> Message-ID: References: <006b01c6c755$238cb790$260218ac@rs.riverstonenet.com> <44ED655E.8020702@cisco.com> <44EE29F4.5050109@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1726/Thu Aug 24 19:45:50 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Manav Bhatia , Inter-Domain Routing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, Enke Chen wrote: > The update sequence described by Manav is the following: > > UPDATE: feasible nlri X, next_hop N1, > UPDATE: feasible nlri X, multiple_hop N2, > UPDATE: unfeasible nlri X, multiple_hop N1 > UPDATE: unfeasible nlri X, multiple_hop N2 > UPDATE: feasible nlri X, multiple_hop N11, > UPDATE: feasible nlri X, multiple_hop N12, > You seem to be talking about a different approach. Could you detail the > sequence of updates? Err, you may have meant "detail the sequence for the other approach" rather than "detail the sequence above". I'm not sure what other approach you mean, unless you refer to the opportunistic bunching that is possible when, for a specific NLRI, the paths differ only by nexthop. E.g. if for all the above are equal, then it is possible to 'bunch' some of the UPDATEs together: - the first two UPDATEs differ only by nexthop, so they can be opportunistically bunched together into: UPDATE: feasible nlri X, next_hop N1, multiple_hop N2 - The second two explicit withdrawal UPDATEs can be bunched together: UPDATE: unfeasible nlri X, multiple_hop N1, N2 - The last two UPDATEs can be bunched together: UPDATE: feasible nlri X multiple_hop N11, N12 Whether it's possible obviously depends on timing, as it does today for UPDATE bunching. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: petribar: Any sun-bleached prehistoric candy that has been sitting in the window of a vending machine too long. -- Rich Hall, "Sniglets" _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 20:02:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGP7P-0004eh-78; Thu, 24 Aug 2006 20:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGP7N-0004ec-An for idr@ietf.org; Thu, 24 Aug 2006 20:00:13 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGP7L-00042J-JN for idr@ietf.org; Thu, 24 Aug 2006 20:00:13 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/E+L85IccWgCgTHZrTCXgUtNWTr4a55dI@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7ONxslK010653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 01:00:06 +0100 Date: Fri, 25 Aug 2006 00:59:54 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: Message-ID: References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> <44EDEDB8.303@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1726/Thu Aug 24 19:45:50 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Inter-Domain Routing List , "Joel M. Halpern" , joel@stevecrocker.com, Manav Bhatia , 'Robert Raszuk' , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, John G. Scudder wrote: > The referent of "this" isn't clear but I'll take a shot at answering anyway. Oops, and cheers. :) [snip] Right, an unstable per-path counter is what add-path boils down to, if you refuse to use information from the path itself. Could either yourself or Enke explain why the coupled-state objection does not apply here? The specific quote I have in mind (from Enke) is: "It means that at the time of sending update the info (such as the nexthop) for the old path may no longer available." With an unstable identifier you lose ability for a temporaly decoupled update sending process to 'bunch' a series of withdraws and readvertisements into one implicit withdrawal. Unless of course you add state to remember the IDs of removed paths (not too terrible) and a way to 'lose' that info once it becomes irrelevant (should be easy, but..). Why do none of these concerns apply to add-path and unstable IDs? And still, this counter seems redundant to us given next-hop appears to suffice for all known uses of BGP. 1. To Multiple-Hop, but which state actually does not need to be kept for Multiple-Hop. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Why can't you be a non-conformist like everyone else? _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 20:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGPOl-00065s-GL; Thu, 24 Aug 2006 20:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGPOk-00065j-EH for idr@ietf.org; Thu, 24 Aug 2006 20:18:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGPOj-0000Ie-7Z for idr@ietf.org; Thu, 24 Aug 2006 20:18:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2006 12:45:59 -0700 X-BrightmailFiltered: true X-IronPort-AV: i="4.08,166,1154934000"; d="scan'208"; a="37925618:sNHT1880201088" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OJk1N1004343; Thu, 24 Aug 2006 15:46:01 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OJjxdN000331; Thu, 24 Aug 2006 15:46:00 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> Date: Thu, 24 Aug 2006 15:45:56 -0400 To: Paul Jakma From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=711; t=1156448761; x=1157312761; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20=20draft-bhatia-bgp-multiple-next-hops- 01.txt |To:Paul=20Jakma=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=ONWOBmW0D3wd2VobbPAU5+Hfwn3oQzpQoO39y1QaScvv1pDIMMtNpyiwxyvk88rDsjjBm8Be f8HqGKJv2NcdMtriyioB87JMmxJrDZr+uw5W5GO+agcjwze7d9AAsSro; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Joel M. Halpern" , Inter-Domain Routing List , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 8:33 PM +0100 8/24/06, Paul Jakma wrote: >Our point therefore is that we should simply use next-hop as this >additional path-identity, as it is emminently suited to the task. I think this is the single interesting point in contention: whether or not next hop is always suitable for the task of uniquely identifying a path. Rather than responding individually to your further points about selection of path identifier, I'll just point to Enke: At 11:19 AM -0700 8/24/06, Enke Chen wrote: >Let us give a trivial algorithm: > >For a prefix, allocate the path identifiers for paths sequentially >starting from 0, do not reuse until it wraps (that will take many >many years). --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 20:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGPVC-0001FO-87; Thu, 24 Aug 2006 20:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGPVA-00019x-F0 for idr@ietf.org; Thu, 24 Aug 2006 20:24:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGPV7-0001Yr-WC for idr@ietf.org; Thu, 24 Aug 2006 20:24:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 20:24:45 -0400 X-IronPort-AV: i="4.08,166,1154923200"; d="scan'208"; a="98557092:sNHT32650360" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7P0OjaQ021822; Thu, 24 Aug 2006 20:24:45 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7P0OhdN013883; Thu, 24 Aug 2006 20:24:43 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> <44EDEDB8.303@cisco.com> Date: Thu, 24 Aug 2006 20:24:31 -0400 To: Paul Jakma From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2418; t=1156465485; x=1157329485; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt |To:Paul=20Jakma=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=G7Vjp4/lZAJmvo4uKB02cdTHCoGw//JEr3e+MnT5+YMXaszyGvFmX7OSrelP0EfKWaIp8EdI e11Nd+QiHEQ1XNxBShkSKSCqi6+ahSwq1RoXzKefjgpobnzBmVxLhsPj; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Inter-Domain Routing List , "Joel M. Halpern" , joel@stevecrocker.com, Manav Bhatia , 'Robert Raszuk' , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 12:59 AM +0100 8/25/06, Paul Jakma wrote: >On Thu, 24 Aug 2006, John G. Scudder wrote: > >>The referent of "this" isn't clear but I'll take a shot at answering anyway. > >Oops, and cheers. :) > >[snip] > >Right, an unstable Unstable? Not sure what you mean by that -- perhaps that the path ID isn't (necessarily) derived from anything in the path, nor is the initial value it will get be predictable. It's not unstable in the sense of shifting arbitrarily once assigned -- it remains the same for the life of the route (though should the peer withdraw and then later re-advertise the route, it'd change). >per-path counter is what add-path boils down to, if you refuse to >use information from the path itself. > >Could either yourself or Enke explain why the coupled-state >objection does not apply here? The specific quote I have in mind >(from Enke) is: > > "It means that at the time of sending update the info (such as the > nexthop) for the old path may no longer available." > >With an unstable identifier you lose ability for a temporaly >decoupled update sending process to 'bunch' a series of withdraws >and readvertisements into one implicit withdrawal. I don't understand why you should say so. (N.b. a more familiar term than 'bunch' -- to me, anyway -- is 'pack'.) Again, perhaps you're saying this because you think the identifier changes with re-advertisement? Not so. >Unless of course you add state to remember the IDs of removed paths >(not too terrible) and a way to 'lose' that info once it becomes >irrelevant (should be easy, but..). I'll defer to Enke for the real answer, but I think you've got it in the paragraph above. >Why do none of these concerns apply to add-path and unstable IDs? Because the "should be easy" paragraph is effectively something any existing BGP implementation already does. And because it only applies in the case of outright withdraws, not replacement by different next hop. Indeed, the replacement by different next hop case could be termed an "unstable identifier" (in the second sense I defined above). >And still, this counter seems redundant to us given next-hop appears >to suffice for all known uses of BGP. > >1. To Multiple-Hop, but which state actually does not need to be kept > for Multiple-Hop. This footnote seems to be a non-sequitur? --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 24 21:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGQA9-0006ES-OO; Thu, 24 Aug 2006 21:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGQA8-0006ED-8Z for idr@ietf.org; Thu, 24 Aug 2006 21:07:08 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGQA7-0002iv-Iq for idr@ietf.org; Thu, 24 Aug 2006 21:07:08 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18CVdxJmiDxfjDn4UGDyaLtP4MA7uwd86U@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7P16g1i011248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 02:06:55 +0100 Date: Fri, 25 Aug 2006 02:06:42 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: Message-ID: References: <004a01c6c741$3f9726f0$260218ac@rs.riverstonenet.com> <44EDEDB8.303@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1726/Thu Aug 24 19:45:50 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Inter-Domain Routing List , "Joel M. Halpern" , joel@stevecrocker.com, Manav Bhatia , 'Robert Raszuk' , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, 24 Aug 2006, John G. Scudder wrote: > Unstable? Not sure what you mean by that -- perhaps that the path > ID isn't (necessarily) derived from anything in the path, Yes, that is what I meant. > remains the same for the life of the route (though should the peer > withdraw and then later re-advertise the route, it'd change). Right. > I don't understand why you should say so. (N.b. a more familiar > term than 'bunch' -- to me, anyway -- is 'pack'.) I'll use that term so. :) > Again, perhaps you're saying this because you think the identifier > changes with re-advertisement? Not so. Unless it had been withdrawn before. > different next hop. Indeed, the replacement by different next hop > case could be termed an "unstable identifier" (in the second sense > I defined above). Sure, but if the next-hop "changes" it is really a different path (in that plane anyway). It's fundamental to the concept of a path surely? To go back to add-path: If the path identity is to be temporal in nature, are we abandoning the concept of dampening[1] for BGP? A \ RS--B / C A and C advertise P to the Route-Server. A withdraws and updates P at intervals. B sees: UPDATE: feasible P:1, nexthop A UPDATE: feasible P:2, nexthop C UPDATE: unfeasible P:3 UPDATE: feasible P:4, nexthop C UPDATE: unfeasible P:5 The path identity of the flapping path keeps changing, so B can not damp it (unless it goes by the nexthop..). Maybe dampening isn't relevant anymore today. What about BGP data collectors and analysers (RIS, etc..)? To be honest: I'm as uncomfortable with constantly changing identities for paths as you are with using nexthop as the identity. >> 1. To Multiple-Hop, but which state actually does not need to be kept >> for Multiple-Hop. > > This footnote seems to be a non-sequitur? Oops, that was intended to apply to text about Enke's state/coupling comment. 1. Ok, this might be a good thing ;). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "All my life I wanted to be someone; I guess I should have been more specific." -- Jane Wagner _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 04:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXMt-0007cV-BJ; Fri, 25 Aug 2006 04:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXMr-0007cO-Jl for idr@ietf.org; Fri, 25 Aug 2006 04:48:45 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGXMq-0007YL-93 for idr@ietf.org; Fri, 25 Aug 2006 04:48:45 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA16776; Fri, 25 Aug 2006 01:48:41 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 14:18:40 +0530 From: "Manav Bhatia" To: "'John G. Scudder'" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Fri, 25 Aug 2006 14:18:33 +0530 Message-ID: <007601c6c823$3f0b3ef0$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHpw999DW9gWBtRdiAtnikc5vcwwAfBa/Q X-OriginalArrivalTime: 25 Aug 2006 08:48:40.0262 (UTC) FILETIME=[43261E60:01C6C823] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >> >> An UPDATE message which contains an IP address prefix in the >> WITHDRAWN ROUTES marks all the associated routes as being no longer >> available for use. >> >> An UPDATE message consisting of an IP address prefix in the NLRI >> field and only the NEXT_HOP attribute implicitly withdraws all the >> routes to that address prefix and replaces it with the one >advertised >> by the NEXT_HOP. > >Apart from any other issue the paragraph above seems incorrect as >written. I presume that you don't mean an update that has only >(fixed header, NLRI, NEXT_HOP) but rather an update that has all of >the required attributes but doesn't have MULTIPLE_HOP. Yes, precisely. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 05:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXft-00005g-Ct; Fri, 25 Aug 2006 05:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGXfr-00005b-Ex for idr@ietf.org; Fri, 25 Aug 2006 05:08:23 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGXfq-0003sn-4e for idr@ietf.org; Fri, 25 Aug 2006 05:08:23 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA18200; Fri, 25 Aug 2006 02:08:20 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 14:38:16 +0530 From: "Manav Bhatia" To: "'John G. Scudder'" , Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Fri, 25 Aug 2006 14:38:09 +0530 Message-ID: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHpyiGkKfhC5YrTrmu+YFpy53I9AAfCOqg X-OriginalArrivalTime: 25 Aug 2006 09:08:16.0497 (UTC) FILETIME=[003D5610:01C6C826] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John, >Second, the draft specifies a set of flags in the multiple-hop >capability. The only defined flag is the "receive multiple" flag. >Under what circumstances would a router ever advertise the capability >without setting the RM flag? RR / | \ A B C The RR may not be interested in learning *all* the routes from each client (A, B and C). It may only want the client to advertise its best path, which would be reflected to other clients/non clients. This bit provides the granularity for a speaker to indicate that it is NOT willing to accept multiple paths. This was done because learning and advertising multiple paths consumes resources and should only be done if necessary. This is beneficial as it can avoid generation of unwanted routing updates at the source itself. Cheers, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 05:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGY7t-0005wK-6G; Fri, 25 Aug 2006 05:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGY7s-0005wF-Al for idr@ietf.org; Fri, 25 Aug 2006 05:37:20 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGY7r-00084B-0H for idr@ietf.org; Fri, 25 Aug 2006 05:37:20 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA20038; Fri, 25 Aug 2006 02:37:08 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:07:06 +0530 From: "Manav Bhatia" To: "'Joel M. Halpern'" , "'John G. Scudder'" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Fri, 25 Aug 2006 15:06:59 +0530 Message-ID: <007e01c6c82a$03632a50$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7.0.1.0.0.20060824175929.03547378@stevecrocker.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHyPEoK/xOLw+eSkWuzZGL5TtfhgAXvoOQ X-OriginalArrivalTime: 25 Aug 2006 09:37:06.0725 (UTC) FILETIME=[07892D50:01C6C82A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >In once sense one can argue that it is deficiency. >However, I want to avoid designing for hypothetical goals which will >not be needed. Couldn't have been stated any better. Also next-hop-self is set on an EBGP router when its advertising routes to IBGP so that they use this router as the next hop for all the EBGP learnt routes. I am unable to envisage a case when we would have the same for multiple paths. I don't think we should be optimizing a protocol design for the unknown. I call it unknown as we're thinking that some day we may come up with an AFI/SAFI in which we'll have multiple routes of the same that need to be passed on. However, if the majority thinks that it's a worthy case that should be handled then this can be easily incorporated in the multiple hop attribute. Thanks, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 06:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYdu-0005U8-2f; Fri, 25 Aug 2006 06:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYdr-0005U3-VS for idr@ietf.org; Fri, 25 Aug 2006 06:10:23 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYdq-0005PP-Fb for idr@ietf.org; Fri, 25 Aug 2006 06:10:23 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id DAA24613; Fri, 25 Aug 2006 03:10:14 -0700 (PDT) Received: from pfloyd ([172.24.2.38]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:40:13 +0530 From: "Manav Bhatia" To: "'Paul Jakma'" , "'Enke Chen'" Subject: RE: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Fri, 25 Aug 2006 15:40:06 +0530 Message-ID: <009c01c6c82e$a3979930$260218ac@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbHopxyodSPICffQ/yRhIuj9RYsLAAiwalQ X-OriginalArrivalTime: 25 Aug 2006 10:10:13.0559 (UTC) FILETIME=[A7C7FC70:01C6C82E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: 'Inter-Domain Routing List' , paul.jakma@sun.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I didn't see a reply on how add-path proposal aims to address an issue raised by Paul below? This illustrates the general concern that we have with arbitrarily picking up a path ID. I think it has been disambiguated that the Router ID will not work as a Path Id and an implementation needs to pick up its own unique numbers .. >The problem, and Joel's point (I think), is that in not giving any >guidance on how this identifier is to be picked, implementations will >settle on picking this identifier in a deficient way. E.g. >particularly as the draft suggests that router-ID is one possible >choice of such identifier (and indeed you suggest same the below). > >Such a choice would not work for re-advertising multiple paths, e.g. >a cluster of route-reflectors: > > RR1-RR2 > / | | > A B C > >Say A, B and C all advertise a certain NLRI, P. > >RR1 and RR2 use add-path with their clients and between themselves so >as to allow all paths to be distributed to all RR-clients. Both the >RR implementations go for the simple approach (as suggested in the >draft and your email) of using the router-ID of the speaker a path >was received from as the Add-Path-ID. So RR1 sends to RR2: > > UPDATE: feasible P:A, > UPDATE: feasible P:B, > >Where X:Y is: add-path NLRI for Prefix X and add-path-id of Y. > >Now, how should RR2 advertise these to its clients? > >It clearly can not blindly just use the Router-ID of the speaker it >received the paths from (RR1 in both cases). > >It could however just reuse the path-ids. So the RR's add-path >implementation now becomes (wrt choosing Add-Path-ID): > > "If the received path already has a path-ID, and no other > received paths have the same, just re-use that path-id. > > Otherwise, use the Router-ID of speaker the path was > received from" > >So now RR2 /can/ easily advertise the two paths received from RR1 to >C and D. > >However, our friendly BGP network administrator now figures out he >really ought to have clients peer with both RRs, he does so for B >(e.g. A and C's sessions to other RR may be broken for some reason): > > RR1-RR2 > / |/ | > A B C > > >RR2 now has recieved: > >>From RR1: > > P:A > P:B > >>From B: > > P > >What should it advertise to C? > >The choices seem to be: > >- Figure out that P and P:B are the exact same path (e.g. they'll > have the exact same next-hop..), and advertise just P:B to C. > > - remember, that RR1 used 'B' as the path-ID is wholly at the > discretion of RR1 > > - the nexthop however... > >or > >- Advertise both P:B and P:B' to C > > - where B' is some constructed identifier for the path > for P received from B > >It seems to us that behaviour of the add-path draft with RR clusters >may be quite indeterminable, given that the issue of the additional >path-identifier is left completely at the discretion of speakers. > >One could say "Ah, but ORIGINATOR_ID can be used!", but that's a >route-reflection specific attribute. It won't work for other cases >that could make use of add-path, e.g. ECMP.. > >Also, for ECMP, a lot of the details of whether not multiple-paths >should be advertised or else whether or not the AS_PATH must be 'ECMP >aggregated' revolve around next-hop. > >> the routes (simulating full-mesh). It is actually the (prefix, >> router-id) that would identify a path instead of the prefix itself. > >And see above :) > >> As the issue of how to identify a path is so fundamental to >a solution, I >> hope that it can be clarified before we dive into other details. > >Yep, fully agreed. > >And for any two paths to the same destination a speaker may have, the >next-hop(s) serve(s) as an identity, regardless of other attributes >of the paths. > >- if they are not to the same remote speaker, the paths obviously are > different (at least in that "plane" of routing) > >- if they are the same, the two paths are effectively the same, > regardless of the other attributes. > >We maintain so anyway and think it to be fundamental to routing. > >In which case, we might as well make use of this property, rather >than having speakers left to reinvent identifiers, which we think is >not quite as easy and problem-free in the general case as it is for >simple RR cases. > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 06:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZBI-0005Nz-Hn; Fri, 25 Aug 2006 06:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZBH-0005No-Tf for idr@ietf.org; Fri, 25 Aug 2006 06:44:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGZBH-0005mv-RS for idr@ietf.org; Fri, 25 Aug 2006 06:44:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGJUK-0002Qv-LF for idr@ietf.org; Thu, 24 Aug 2006 13:59:33 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 13:59:33 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208"; a="98484068:sNHT32022060" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OHxWGe030554; Thu, 24 Aug 2006 13:59:32 -0400 Received: from [10.0.1.5] (rtp-jgs-vpn1.cisco.com [10.82.179.66]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id k7OHxVdN018668; Thu, 24 Aug 2006 13:59:31 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <017201c6c65d$6b1d2c50$0201a8c0@rs.riverstonenet.com> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <004b01c6c65a$67f65130$860c6f0a@china.huawei.com> <017201c6c65d$6b1d2c50$0201a8c0@rs.riverstonenet.com> Date: Thu, 24 Aug 2006 12:27:42 -0400 To: "Manav Bhatia" From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=1052; t=1156442372; x=1157306372; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt |To:=22Manav=20Bhatia=22=20; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=ObY/w5wQLMYnHj4t9LSEDaHisy9x83udTUQdkZBDzZVmFrRuIzFUWUa/lPEaoYkmW/sz4XZz g7yCv6OxJMFrgCSXkBaP4quONp3T4aYkM0GjLygcloqWrKD200uZ6euE; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.3 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 8:09 AM +0530 8/23/06, Manav Bhatia wrote: >3.2 Withdrawal Procedures > > An UPDATE message which contains an IP address prefix in the > WITHDRAWN ROUTES marks all the associated routes as being no longer > available for use. > > An UPDATE message consisting of an IP address prefix in the NLRI > field and only the NEXT_HOP attribute implicitly withdraws all the > routes to that address prefix and replaces it with the one advertised > by the NEXT_HOP. Apart from any other issue the paragraph above seems incorrect as written. I presume that you don't mean an update that has only (fixed header, NLRI, NEXT_HOP) but rather an update that has all of the required attributes but doesn't have MULTIPLE_HOP. --John P.S.: Also, a nit: the draft is full of characters that don't render properly. I assume that at some point these were curly quotation marks and apostrophes, but now they're just textual junk. (For example, "Author's Address" in the ToC contains one such in place of the apostrophe.) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 09:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGc3u-0006yZ-6J; Fri, 25 Aug 2006 09:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGc3s-0006yR-EA; Fri, 25 Aug 2006 09:49:28 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGc3r-0007UG-3D; Fri, 25 Aug 2006 09:49:28 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k7PDnQX20359; Fri, 25 Aug 2006 06:49:26 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7PDnLg52930; Fri, 25 Aug 2006 06:49:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608251349.k7PDnLg52930@merlot.juniper.net> To: Bill Fenner Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard In-Reply-To: Your message of "Thu, 24 Aug 2006 04:38:44 PDT." <200608241138.k7OBcjgA018217@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27397.1156513760.1@juniper.net> Date: Fri, 25 Aug 2006 06:49:21 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: idr@ietf.org, Sam Hartman , IESG X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Bill, > >How does this interact with softwires? > > Sam, > > This protocol fits into more or less the Mesh problem of softwires > (section 3.1 of draft-ietf-softwire-problem-statement). The problem > statement says: > > > It should also be noted that the mesh problem can be considered as a > > derivative of L3VPN, where the core provides transit in one address > > family and the islands are connected via L3VPN of another address > > family. > > And indeed, the draft-ooms document is more or less an application of the > L3VPN technology to the IPv6 address family. > > I don't know what the softwires participants' position is with respect > to this draft, but it predates the softwires work [at least, by that > name] by about 5 years. I think it would be very useful to get the softwires participatns' position with respect to this draft. Specifically, if the draft does solve their problem, then the softwires WG should document it as a solution, and if not, then again the softwires WG should document it with an explanation on why it does not solve their problem. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 11:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdP8-0000Vj-6s; Fri, 25 Aug 2006 11:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdP6-0000Va-LF for idr@ietf.org; Fri, 25 Aug 2006 11:15:28 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdOr-0004LZ-A1 for idr@ietf.org; Fri, 25 Aug 2006 11:15:14 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 89F1C4E7F2; Fri, 25 Aug 2006 11:15:04 -0400 (EDT) Date: Fri, 25 Aug 2006 11:15:04 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060825151504.GB27172@scc.mi.org> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44ED48AC.1020702@cisco.com> <7.0.1.0.0.20060824080059.03349d20@stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.0.20060824080059.03349d20@stevecrocker.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, Aug 24, 2006 at 08:02:47AM -0400, Joel M. Halpern wrote: > A route reflector does not insert itself into the data path. Rather, > it preserves the next-hop on all routes it receives. To state something that is obvious and somewhat tangential, route reflectors still perform route selection. This means that while they may not (in the absence of a next-hop-self behavior) insert themselves into the forwarding path, they currently prune available paths for a given destination within an AS in some circumstances. This is part of the reason why we have MED oscillation issues. Since a route reflector prunes paths, injecting other paths into the AS may lead to convergence of reflector clients to different route instances than they may have previously selected. Is this ever bad? That's what I'm trying to figure out. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 11:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdPC-0000W6-QP; Fri, 25 Aug 2006 11:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdPB-0000Va-AW; Fri, 25 Aug 2006 11:15:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdON-0004F5-LC; Fri, 25 Aug 2006 11:14:46 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2006 08:14:43 -0700 X-IronPort-AV: i="4.08,169,1154934000"; d="scan'208"; a="314027619:sNHT33911032" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PFEg58005926; Fri, 25 Aug 2006 08:14:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7PFEg1E008720; Fri, 25 Aug 2006 08:14:42 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 08:14:42 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 08:14:41 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 10:14:41 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Yakov Rekhter , Bill Fenner , , "Durand, Alain" Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbIWTAGbl4QjjRMEduUXgAKlcR7kg== In-Reply-To: <200608251349.k7PDnLg52930@merlot.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 15:14:41.0388 (UTC) FILETIME=[30417AC0:01C6C859] DKIM-Signature: a=rsa-sha1; q=dns; l=1711; t=1156518882; x=1157382882; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using=20IPv6=20Provider=20Edge=20Routers=20(6PE)'=2 0to=20Proposed=20Standard=20; X=v=3Dcisco.com=3B=20h=3DLSzpRHTxX+blzpOhNnNOaTcbAmw=3D; b=phximyjggpWVx9BtMfH9rkr/8febp9PkQTZOj+ZQSIFDMbUBo7hSCQjB3dKtDECFARE7PvLx bOwIgQWigZQPFD7PuuwDj4s6LG+SbGOE0YKNZLG/f7QWpAsQQZf8LjFv; Authentication-Results: sj-dkim-1.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: idr@ietf.org, Sam Hartman , IESG X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I will take this to our list and we will additionally discuss at our interim meeting (mid Sept). In all likelihood (without having gone over the entire draft with a fine toothed comb), it will satisfy one item in our problem space. If for some reason the softwires WG finds deficiencies, we will explain ourselves. -DWard On 8/25/06 8:49 AM, "Yakov Rekhter" wrote: > Bill, > >>> How does this interact with softwires? >> >> Sam, >> >> This protocol fits into more or less the Mesh problem of softwires >> (section 3.1 of draft-ietf-softwire-problem-statement). The problem >> statement says: >> >>> It should also be noted that the mesh problem can be considered as a >>> derivative of L3VPN, where the core provides transit in one address >>> family and the islands are connected via L3VPN of another address >>> family. >> >> And indeed, the draft-ooms document is more or less an application of the >> L3VPN technology to the IPv6 address family. >> >> I don't know what the softwires participants' position is with respect >> to this draft, but it predates the softwires work [at least, by that >> name] by about 5 years. > > I think it would be very useful to get the softwires participatns' > position with respect to this draft. Specifically, if the draft > does solve their problem, then the softwires WG should document it > as a solution, and if not, then again the softwires WG should > document it with an explanation on why it does not solve their > problem. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 11:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdP8-0000Vj-6s; Fri, 25 Aug 2006 11:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdP6-0000Va-LF for idr@ietf.org; Fri, 25 Aug 2006 11:15:28 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdOr-0004LZ-A1 for idr@ietf.org; Fri, 25 Aug 2006 11:15:14 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 89F1C4E7F2; Fri, 25 Aug 2006 11:15:04 -0400 (EDT) Date: Fri, 25 Aug 2006 11:15:04 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060825151504.GB27172@scc.mi.org> References: <20060822200947.3141.qmail@web60725.mail.yahoo.com> <44EB7461.9090101@cisco.com> <002b01c6c64d$43e72100$0201a8c0@rs.riverstonenet.com> <44EBA7D4.1080002@cisco.com> <00d001c6c650$18fb8d20$0201a8c0@rs.riverstonenet.com> <44EC07A3.7000304@cisco.com> <7.0.1.0.0.20060823075243.040b5ce8@stevecrocker.com> <44ED48AC.1020702@cisco.com> <7.0.1.0.0.20060824080059.03349d20@stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.0.20060824080059.03349d20@stevecrocker.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, Aug 24, 2006 at 08:02:47AM -0400, Joel M. Halpern wrote: > A route reflector does not insert itself into the data path. Rather, > it preserves the next-hop on all routes it receives. To state something that is obvious and somewhat tangential, route reflectors still perform route selection. This means that while they may not (in the absence of a next-hop-self behavior) insert themselves into the forwarding path, they currently prune available paths for a given destination within an AS in some circumstances. This is part of the reason why we have MED oscillation issues. Since a route reflector prunes paths, injecting other paths into the AS may lead to convergence of reflector clients to different route instances than they may have previously selected. Is this ever bad? That's what I'm trying to figure out. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 11:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdPC-0000W6-QP; Fri, 25 Aug 2006 11:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdPB-0000Va-AW; Fri, 25 Aug 2006 11:15:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdON-0004F5-LC; Fri, 25 Aug 2006 11:14:46 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2006 08:14:43 -0700 X-IronPort-AV: i="4.08,169,1154934000"; d="scan'208"; a="314027619:sNHT33911032" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PFEg58005926; Fri, 25 Aug 2006 08:14:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7PFEg1E008720; Fri, 25 Aug 2006 08:14:42 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 08:14:42 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 08:14:41 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 10:14:41 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Yakov Rekhter , Bill Fenner , , "Durand, Alain" Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbIWTAGbl4QjjRMEduUXgAKlcR7kg== In-Reply-To: <200608251349.k7PDnLg52930@merlot.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 15:14:41.0388 (UTC) FILETIME=[30417AC0:01C6C859] DKIM-Signature: a=rsa-sha1; q=dns; l=1711; t=1156518882; x=1157382882; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using=20IPv6=20Provider=20Edge=20Routers=20(6PE)'=2 0to=20Proposed=20Standard=20; X=v=3Dcisco.com=3B=20h=3DLSzpRHTxX+blzpOhNnNOaTcbAmw=3D; b=phximyjggpWVx9BtMfH9rkr/8febp9PkQTZOj+ZQSIFDMbUBo7hSCQjB3dKtDECFARE7PvLx bOwIgQWigZQPFD7PuuwDj4s6LG+SbGOE0YKNZLG/f7QWpAsQQZf8LjFv; Authentication-Results: sj-dkim-1.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: idr@ietf.org, Sam Hartman , IESG X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I will take this to our list and we will additionally discuss at our interim meeting (mid Sept). In all likelihood (without having gone over the entire draft with a fine toothed comb), it will satisfy one item in our problem space. If for some reason the softwires WG finds deficiencies, we will explain ourselves. -DWard On 8/25/06 8:49 AM, "Yakov Rekhter" wrote: > Bill, > >>> How does this interact with softwires? >> >> Sam, >> >> This protocol fits into more or less the Mesh problem of softwires >> (section 3.1 of draft-ietf-softwire-problem-statement). The problem >> statement says: >> >>> It should also be noted that the mesh problem can be considered as a >>> derivative of L3VPN, where the core provides transit in one address >>> family and the islands are connected via L3VPN of another address >>> family. >> >> And indeed, the draft-ooms document is more or less an application of the >> L3VPN technology to the IPv6 address family. >> >> I don't know what the softwires participants' position is with respect >> to this draft, but it predates the softwires work [at least, by that >> name] by about 5 years. > > I think it would be very useful to get the softwires participatns' > position with respect to this draft. Specifically, if the draft > does solve their problem, then the softwires WG should document it > as a solution, and if not, then again the softwires WG should > document it with an explanation on why it does not solve their > problem. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 11:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdhM-0003eT-U9; Fri, 25 Aug 2006 11:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdhK-0003e8-W3 for idr@ietf.org; Fri, 25 Aug 2006 11:34:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdhH-0007fW-Hq for idr@ietf.org; Fri, 25 Aug 2006 11:34:18 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 08:34:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PFYFH6018835; Fri, 25 Aug 2006 08:34:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7PFYEQV015377; Fri, 25 Aug 2006 08:34:14 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 08:34:14 -0700 Received: from [10.21.148.8] ([10.21.148.8]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 08:34:12 -0700 Message-ID: <44EF186E.8050107@cisco.com> Date: Fri, 25 Aug 2006 08:34:06 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> In-Reply-To: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 15:34:13.0492 (UTC) FILETIME=[EAE25B40:01C6C85B] DKIM-Signature: a=rsa-sha1; q=dns; l=1434; t=1156520055; x=1157384055; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DFMt196C98OMaGny/tdknCAVss/0=3D; b=1vT2WHecVCcmnktmkcbQpGyScCUgMcHaAfEiFrs1OSg/CoWUsDrq3CpMYqWBac1mbmdeM3Lh MaOlsaWgG5X6/3BTO1zXE+OmsU9VXz9ufSRdC+RdgEBr4d/FahHVZu1L; Authentication-Results: sj-dkim-2.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'John G. Scudder'" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav, > The RR may not be interested in learning *all* the routes from each > client (A, B and C). It may only want the client to advertise its best > path, which would be reflected to other clients/non clients. Then RR would negotiate the corresponding capability with only those peers he is willing to accept all/external paths from ? Would not that serve the same purpose ? Thx, R. > John, > >> Second, the draft specifies a set of flags in the multiple-hop >> capability. The only defined flag is the "receive multiple" flag. >> Under what circumstances would a router ever advertise the capability >> without setting the RM flag? > > RR > / | \ > A B C > > The RR may not be interested in learning *all* the routes from each client > (A, B and C). It may only want the client to advertise its best path, which > would be reflected to other clients/non clients. > > This bit provides the granularity for a speaker to indicate that it is NOT > willing to accept multiple paths. This was done because learning and > advertising multiple paths consumes resources and should only be done if > necessary. This is beneficial as it can avoid generation of unwanted routing > updates at the source itself. > > Cheers, > Manav > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 11:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdk6-0005eH-LZ; Fri, 25 Aug 2006 11:37:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGdk4-0005dm-V6 for idr@ietf.org; Fri, 25 Aug 2006 11:37:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdk4-0007xg-TN for idr@ietf.org; Fri, 25 Aug 2006 11:37:08 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGdWt-00079X-1K for idr@ietf.org; Fri, 25 Aug 2006 11:23:34 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 6F1C34E807; Fri, 25 Aug 2006 11:23:30 -0400 (EDT) Date: Fri, 25 Aug 2006 11:23:30 -0400 From: Jeffrey Haas To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Message-ID: <20060825152330.GC27172@scc.mi.org> References: <20060823181150.GG13706@scc.mi.org> <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> User-Agent: Mutt/1.3.28i X-Spam-Score: -2.3 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Thu, Aug 24, 2006 at 06:59:05AM +0530, Manav Bhatia wrote: > A simple addition of the following text would perhaps fix the issue that > you have: > > Between Multiple-Hop capable speakers, the MULTIPLE_HOP attribute MUST be > used in addition to the existing NEXT_HOP/MP_REACH_NLRI in order to > announce multiple next-hops for the destinations listed in the > NLRI/MP_REACH_NLRI of the UPDATE message. If the speaker has installed one > of the next-hops concerned in its FIB, then that particular next-hop MUST > be listed in the NEXT_HOP/MP_REACH_NLRI attribute. Unless I am grossly mis-understanding your proposal, this allows for an ecmp case of the same path, same destination but multiple nexthops. The scenario I am concerned with is same destination, different path, different nexthop. The above doesn't seem to cover that. > This is possible in our approach, but can *never* be done in add-paths btw. I'm not sure that's the case. The add-paths mechanism allows for multiple BGP routes with any attributes as long as they have distinct keys. The key simply identifies a given route instance. I think that point may be understood now, but I'm responding to this point a bit further back in the thread history. > However, we must also keep in mind that there are applications that require > multiple BGP paths where none of them are actually installed in the FIB > (eBGP IXes). I'm well aware of the requirements for a route server. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 12:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeol-0002zJ-Tk; Fri, 25 Aug 2006 12:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeok-0002zD-JQ for idr@ietf.org; Fri, 25 Aug 2006 12:46:02 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGeoj-0006Ko-8d for idr@ietf.org; Fri, 25 Aug 2006 12:46:02 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA01922; Fri, 25 Aug 2006 09:45:58 -0700 (PDT) Received: from manavLpt ([10.128.16.128]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 09:45:57 -0700 Message-ID: <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Fri, 25 Aug 2006 22:15:52 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 Aug 2006 16:45:57.0945 (UTC) FILETIME=[F089C290:01C6C865] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'John G. Scudder'" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Robert, >> The RR may not be interested in learning *all* the routes from each >> client (A, B and C). It may only want the client to advertise its best >> path, which would be reflected to other clients/non clients. > > Then RR would negotiate the corresponding capability with only those > peers he is willing to accept all/external paths from ? Would not that > serve the same purpose ? No. We may want the RR to reflect all the routes that it learns from the other clients. Not negotiating this capability would lead to the RR advertising only the one best path to its client. Cheers, Manav > > Thx, > R. > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 12:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGesJ-00048w-EA; Fri, 25 Aug 2006 12:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGesI-00048n-57 for idr@ietf.org; Fri, 25 Aug 2006 12:49:42 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGesG-0006i3-Ej for idr@ietf.org; Fri, 25 Aug 2006 12:49:42 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18x5Q2uYbxgzymV6l9Z8ydqxJ2o2ppJ/q4@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7PGnQoo029796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Aug 2006 17:49:38 +0100 Date: Fri, 25 Aug 2006 17:49:26 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Jeffrey Haas Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <20060825152330.GC27172@scc.mi.org> Message-ID: References: <20060823181150.GG13706@scc.mi.org> <00c301c6c71c$b317c910$0201a8c0@rs.riverstonenet.com> <20060825152330.GC27172@scc.mi.org> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1728/Fri Aug 25 06:55:58 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, 25 Aug 2006, Jeffrey Haas wrote: > The scenario I am concerned with is same destination, different path, > different nexthop. The above doesn't seem to cover that. Can we think of an example involving two paths that are "the same but different" in this way? E.g. (and apologies for any obviousness, but just to ensure its all clear): A---\ C---D B---/ A and B originate a path for P. D, potentially, could get: P via C, path C_B or P via C, path A_D Why would we ever want C to be able to advertise both these paths to D? Only of them is useable by D. Indeed, we're pretty sure no plausible counter examples exist[1], as the (destination,nexthop(s)) identity simply is fundamental to D-V. As such, there really is no conceptual need for an additional identifier[2]. We'd be happy to hear of a counter-example, but the authors of the draft are unable to (and believe me, we have tried for quite a while to find one), and none has yet been raised in the spirited discussion here this week[3]. I'll finish with a quote from an earlier email of Joel's: "I want to avoid designing for hypothetical goals which will not be needed." Look forward to your reply! :) --paulj 1. The only examples so far that come close are the "Use BGP as a flooding mechanism for information unrelated to paths" cases, but no multiple-advertisements will ever be needed for flooding such - again as this is fundamental to flooding. 2. Not even for 'feasible but unuseable' paths. 3. Though, good humoured, interesting and useful, whatever the outcome is to be, I feel. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Everyone is more or less mad on one point. -- Rudyard Kipling _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 13:41:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfen-0006RD-8j; Fri, 25 Aug 2006 13:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfem-0006QF-5V; Fri, 25 Aug 2006 13:39:48 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfZ2-000623-Ke; Fri, 25 Aug 2006 13:33:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2006 10:33:52 -0700 X-IronPort-AV: i="4.08,169,1154934000"; d="scan'208"; a="441615371:sNHT35679094" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PHXpi9004699; Fri, 25 Aug 2006 10:33:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7PHXpQV028735; Fri, 25 Aug 2006 10:33:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:33:51 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:33:51 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 12:33:49 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Yakov Rekhter , Bill Fenner , "Durand, Alain" , , David Ward , "Mark Townsley (townsley)" Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbIbJ/R3qHQ+zRfEduDGAAKlcR7kg== In-Reply-To: <200608251349.k7PDnLg52930@merlot.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 17:33:51.0210 (UTC) FILETIME=[A12334A0:01C6C86C] DKIM-Signature: a=rsa-sha1; q=dns; l=2962; t=1156527231; x=1157391231; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using=20IPv6=20Provider=20Edge=20Routers=20(6PE)'=2 0to=20Proposed=20Standard=20; X=v=3Dcisco.com=3B=20h=3DLSzpRHTxX+blzpOhNnNOaTcbAmw=3D; b=GHVC5/FCQB/9HX/qLnhH1JuYLGDsSHxXA4EcXqO8hoEuqaCd5RD3PKVz7na96PZdGcWLMRsq cge6Hih6ClpmpfMufsPquzdS2swjmBCJYjZ8kNzrLnXKISZqsWrQPHvj; Authentication-Results: sj-dkim-2.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: idr@ietf.org, Sam Hartman , IESG X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov, Bill - Having read the document I have some initial comments. First, 6PE is an excellent solution. Overstating the obvious (perhaps my greatest talent), this is a solution for the subset of softwire problems that would be used for 6-over-4 when the encaps policy is "always use MPLS" and there are no security requirements. I will leave the question of 'no security requirements' for this solution to others. The major deficiency from a softwires vantage point is that the v4 NH gets encoded in a v6 format, but semantically it's v4 and this encoding trick doesn't work when you're doing v6 over v4. This is not to say the solution doesn't work but, since softwires has to solve both v4 over v6 and v6 over v4 (and variants including VPNs); I strongly urge that we don't have multiple techniques to derive the AF of the NH. The current advancement of multiple techniques that require either encoding or length-check should be cleared up and made obvious and consistent. I recommend some number of bits (or a byte) be used to state clearly what the AF of the NH is and leave in original encoding. A capability can be added to make sure that a peer can understand the new bits. Of course, I am looking for the minimal change to the doc and to BGP but, this matter needs to be discussed. The assumptions becoming embedded in the techniques of how to figure out what the actual AF of the NH could be easily cleared up w/ the suggestion of just very small number of bits and a capability in BGP. Flames? You know where to send them ... ;-) -DWard On 8/25/06 8:49 AM, "Yakov Rekhter" wrote: > Bill, > >>> How does this interact with softwires? >> >> Sam, >> >> This protocol fits into more or less the Mesh problem of softwires >> (section 3.1 of draft-ietf-softwire-problem-statement). The problem >> statement says: >> >>> It should also be noted that the mesh problem can be considered as a >>> derivative of L3VPN, where the core provides transit in one address >>> family and the islands are connected via L3VPN of another address >>> family. >> >> And indeed, the draft-ooms document is more or less an application of the >> L3VPN technology to the IPv6 address family. >> >> I don't know what the softwires participants' position is with respect >> to this draft, but it predates the softwires work [at least, by that >> name] by about 5 years. > > I think it would be very useful to get the softwires participatns' > position with respect to this draft. Specifically, if the draft > does solve their problem, then the softwires WG should document it > as a solution, and if not, then again the softwires WG should > document it with an explanation on why it does not solve their > problem. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 14:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgPo-0006BS-Be; Fri, 25 Aug 2006 14:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgPn-0006B7-CV; Fri, 25 Aug 2006 14:28:23 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgPl-0008KI-Ui; Fri, 25 Aug 2006 14:28:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k7PISLX24860; Fri, 25 Aug 2006 11:28:21 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7PISFg11936; Fri, 25 Aug 2006 11:28:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608251828.k7PISFg11936@merlot.juniper.net> To: David Ward Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard In-Reply-To: Your message of "Fri, 25 Aug 2006 12:33:49 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46311.1156530495.1@juniper.net> Date: Fri, 25 Aug 2006 11:28:15 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: idr@ietf.org, Bill Fenner , Yakov Rekhter , "Durand, Alain" , IESG , softwires@ietf.org, "Mark Townsley \(townsley\)" , Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org David, > Yakov, Bill - > > Having read the document I have some initial comments. First, 6PE is an > excellent solution. Overstating the obvious (perhaps my greatest talent), > this is a solution for the subset of softwire problems that would be used > for 6-over-4 when the encaps policy is "always use MPLS" and there are no > security requirements. I will leave the question of 'no security > requirements' for this solution to others. > > The major deficiency from a softwires vantage point is that the v4 NH gets > encoded in a v6 format, but semantically it's v4 and this encoding trick > doesn't work when you're doing v6 over v4. This is not to say the solution > doesn't work but, since softwires has to solve both v4 over v6 and v6 over > v4 (and variants including VPNs); I strongly urge that we don't have > multiple techniques to derive the AF of the NH. As we move forward, I agree with the goal of having a single technique to derive AF of the NH within the context of MP_REACH/MP_UNREACH. > The current advancement of multiple techniques that require either encoding > or length-check should be cleared up and made obvious and consistent. > > I recommend some number of bits (or a byte) be used to state clearly what the > AF of the NH is and leave in original encoding. A capability can be added to > make sure that a peer can understand the new bits. Of course, I am looking > for the minimal change to the doc and to BGP but, this matter needs to be > discussed. The assumptions becoming embedded in the techniques of how to > figure out what the actual AF of the NH could be easily cleared up w/ the > suggestion of just very small number of bits and a capability in BGP. While having "new bits" may be sufficient, it is by no means necessary. This is because the current/original encoding already provides a way to distinguish between IPv4 and IPv6 addresses in the NH of MP_REACH/MP_UNREACH. I am referring to the approach already used in several documents approved by the IETF (e.g., draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain, draft-ietf-l2vpn-vpls-bgp) where the NH Length field is used to distinguish between IPv4 and IPv6 as the NH. And just for completeness, the current/original encoding provides yet another way to distingush between IPv4 and IPv6 as the NH addresses - use two different SAFIs to distinguish between IPv4 and IPv6 as the NH. However, I am not aware of any IETF technologies that use this approach. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 15:06:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgyy-0005Nb-Kb; Fri, 25 Aug 2006 15:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgyw-0005NF-Rm for idr@ietf.org; Fri, 25 Aug 2006 15:04:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgL9-0007ZW-7T for idr@ietf.org; Fri, 25 Aug 2006 14:23:35 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGftH-0002gc-AO for idr@ietf.org; Fri, 25 Aug 2006 13:54:49 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA06415; Fri, 25 Aug 2006 10:54:45 -0700 (PDT) Received: from manavLpt ([10.128.16.128]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:54:44 -0700 Message-ID: <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> <44EF35E9.4020501@cisco.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Fri, 25 Aug 2006 23:24:40 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 Aug 2006 17:54:44.0647 (UTC) FILETIME=[8C3E8370:01C6C86F] X-Spam-Score: -2.2 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Robert, Yes this can be done via ORFs, outbound routemaps, etc. We had some feedback from the IX operators where they wanted asymmetric routes exchange. That is, while the IX clients would advertise their best routes, the route server needs to advertise *all* the routes learnt from all its IX clients to each client. Adding a bit in the capability that does this didn't seem to be much of an overhead! :) Cheers, Manav ----- Original Message ----- From: "Robert Raszuk" To: "Manav Bhatia" Cc: "'John G. Scudder'" ; Sent: Friday, August 25, 2006 11:09 PM Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt > Manav, > > Well this has been already solved in the ORF capability where we > explicitly say send/receive willingness. > > Then negotiating one does not prevent from not negotiating the other :). > > Cheers, > R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 15:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGh7f-0000DI-Uc; Fri, 25 Aug 2006 15:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGh7d-0000Ct-Cc; Fri, 25 Aug 2006 15:13:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGh7a-0007Hx-TW; Fri, 25 Aug 2006 15:13:41 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 12:13:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PJDcD2007159; Fri, 25 Aug 2006 12:13:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7PJD5Yv002602; Fri, 25 Aug 2006 12:13:37 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:13:34 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:13:34 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 14:13:31 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Yakov Rekhter , David Ward Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbIeo1ey/5/zzRtEdujugAKlcR7kg== In-Reply-To: <200608251828.k7PISFg11936@merlot.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 19:13:34.0504 (UTC) FILETIME=[8F756A80:01C6C87A] DKIM-Signature: a=rsa-sha1; q=dns; l=3950; t=1156533218; x=1157397218; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using=20IPv6=20Provider=20Edge=20Routers=20(6PE)'=2 0to=20Proposed=20Standard=20; X=v=3Dcisco.com=3B=20h=3DLSzpRHTxX+blzpOhNnNOaTcbAmw=3D; b=RcKPyorQRgaCY2hOTxn2gMPhpPGDUWXNm9r828SpMmmYJiTIHJySX6uxuCu4+vsRSQC4faDP 6RujKswz9YOIn6302aVV/kgP0AWrwYRlsrv/YIgNdLvggObqxv9pYjMx; Authentication-Results: sj-dkim-4.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: idr@ietf.org, Bill Fenner , "Durand, Alain" , IESG , softwires@ietf.org, "Mark Townsley \(townsley\)" , Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov, Bill - Since we allow the route to an X-prefix to have a Y-address as its next hop, we still need an SOFTWIRE|IDR document to specify how to do that. For the cases where (a) X is VPN-IPv4 and Y is IPv4, (b) X is VPN-IPv6 and Y is IPv4, (c) X is VPN-IPv6 and Y is IPv6, we have legacy solutions in deployment which could easily remain valid. In addition, we need to handle the "X is VPN-IPv4 and Y is IPv6" case, as well as the case where X is IPv4 and Y is IPv6 and the case where X is IPv6 and Y is IPv4. The necessary document being proposed needs at least the following components: - A reinterpretation of IPv4 AFI/SAFI and IPv6 AFI/SAFI which allows the NH to be of a different AF than the NLRI. Since we are changing the interpretation of the existing AFI/SAFIs, we could define a capability (see earlier suggestion - below in thread). - A specification of how you tell what the address family of the NH is. - Rules to specify what address family the NH should be specified in when a route is advertised. I am willing to write the document which will attempt to preserve and clarify legacy techniques as well as specify the solution to the the issues listed above to make progress. Thoughts? -DWard On 8/25/06 1:28 PM, "Yakov Rekhter" wrote: > David, > >> Yakov, Bill - >> >> Having read the document I have some initial comments. First, 6PE is an >> excellent solution. Overstating the obvious (perhaps my greatest talent), >> this is a solution for the subset of softwire problems that would be used >> for 6-over-4 when the encaps policy is "always use MPLS" and there are no >> security requirements. I will leave the question of 'no security >> requirements' for this solution to others. >> >> The major deficiency from a softwires vantage point is that the v4 NH gets >> encoded in a v6 format, but semantically it's v4 and this encoding trick >> doesn't work when you're doing v6 over v4. This is not to say the solution >> doesn't work but, since softwires has to solve both v4 over v6 and v6 over >> v4 (and variants including VPNs); I strongly urge that we don't have >> multiple techniques to derive the AF of the NH. > > As we move forward, I agree with the goal of having a single technique > to derive AF of the NH within the context of MP_REACH/MP_UNREACH. > >> The current advancement of multiple techniques that require either encoding >> or length-check should be cleared up and made obvious and consistent. >> >> I recommend some number of bits (or a byte) be used to state clearly what the >> AF of the NH is and leave in original encoding. A capability can be added to >> make sure that a peer can understand the new bits. Of course, I am looking >> for the minimal change to the doc and to BGP but, this matter needs to be >> discussed. The assumptions becoming embedded in the techniques of how to >> figure out what the actual AF of the NH could be easily cleared up w/ the >> suggestion of just very small number of bits and a capability in BGP. > > While having "new bits" may be sufficient, it is by no means > necessary. This is because the current/original encoding already > provides a way to distinguish between IPv4 and IPv6 addresses in > the NH of MP_REACH/MP_UNREACH. I am referring to the approach > already used in several documents approved by the IETF (e.g., > draft-ietf-l2vpn-signaling, draft-ietf-l3vpn-rt-constrain, > draft-ietf-l2vpn-vpls-bgp) where the NH Length field is used > to distinguish between IPv4 and IPv6 as the NH. > > And just for completeness, the current/original encoding provides > yet another way to distingush between IPv4 and IPv6 as the NH > addresses - use two different SAFIs to distinguish between IPv4 and > IPv6 as the NH. However, I am not aware of any IETF technologies > that use this approach. > > Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 15:19:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhCb-0003JF-60; Fri, 25 Aug 2006 15:18:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhCa-0003J2-4g for idr@ietf.org; Fri, 25 Aug 2006 15:18:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfrE-0001pI-Tk for idr@ietf.org; Fri, 25 Aug 2006 13:52:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGfey-0002EN-QO for idr@ietf.org; Fri, 25 Aug 2006 13:40:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2006 10:40:01 -0700 X-IronPort-AV: i="4.08,169,1154934000"; d="scan'208"; a="338195764:sNHT32269646" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PHdxBp011372; Fri, 25 Aug 2006 10:39:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7PHdxYr005559; Fri, 25 Aug 2006 10:39:59 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:39:59 -0700 Received: from [128.107.99.143] ([128.107.99.143]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:39:59 -0700 Message-ID: <44EF35E9.4020501@cisco.com> Date: Fri, 25 Aug 2006 10:39:53 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> In-Reply-To: <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 17:39:59.0462 (UTC) FILETIME=[7CA20060:01C6C86D] DKIM-Signature: a=rsa-sha1; q=dns; l=882; t=1156527600; x=1157391600; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DFMt196C98OMaGny/tdknCAVss/0=3D; b=yz/jd0R238xtbf7IN4e7YyYeilBQPDU7FMszqLwxNCqKb9/VEuOnpz4D7mahaRWBf4cf5YaH 4cPYHhajfPDDsR/ZWOesPTNiEMvh/qjjz0LmMK6LQWYYYg3tm0UN7xes; Authentication-Results: sj-dkim-2.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "'John G. Scudder'" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav, Well this has been already solved in the ORF capability where we explicitly say send/receive willingness. Then negotiating one does not prevent from not negotiating the other :). Cheers, R. > Robert, > >>> The RR may not be interested in learning *all* the routes from each >>> client (A, B and C). It may only want the client to advertise its best >>> path, which would be reflected to other clients/non clients. >> >> Then RR would negotiate the corresponding capability with only those >> peers he is willing to accept all/external paths from ? Would not that >> serve the same purpose ? > > No. We may want the RR to reflect all the routes that it learns from the > other clients. Not negotiating this capability would lead to the RR > advertising only the one best path to its client. > > Cheers, > Manav > >> >> Thx, >> R. >> > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 15:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGha4-0006dl-BU; Fri, 25 Aug 2006 15:43:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGha2-0006dN-La; Fri, 25 Aug 2006 15:43:02 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGha1-00041n-Dq; Fri, 25 Aug 2006 15:43:02 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 25 Aug 2006 12:41:13 -0700 X-IronPort-AV: i="4.08,169,1154934000"; d="scan'208"; a="575474280:sNHT27587392" Received: from [172.25.51.51] ([172.25.51.51] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:42:59 -0400 Message-ID: <44EF52C0.2070706@juniper.net> Date: Fri, 25 Aug 2006 15:42:56 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dward@cisco.com, yakov@juniper.net, Alain_Durand@cable.comcast.com, idr@ietf.org, iesg@ietf.org Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using, IPv6 Provider Edge Routers (6PE)' to Proposed Standard References: <200608251926.k7PJQlg25532@merlot.juniper.net> In-Reply-To: <200608251926.k7PJQlg25532@merlot.juniper.net> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 19:42:59.0724 (UTC) FILETIME=[AB9C9CC0:01C6C87E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org > > I am willing to write the document which will attempt to preserve and > clarify legacy techniques as well as specify the solution to the the issues > listed above to make progress. Thoughts? > > - -DWard Dave, If it helps at all, I am currently working on a draft that describes procedures by which an operator can deliver IPv4 services over an IPv6 L3VPN infrastructure. Ron _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 15:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhnh-0001k2-Ir; Fri, 25 Aug 2006 15:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGhng-0001ju-KH; Fri, 25 Aug 2006 15:57:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGhnf-0006kb-A2; Fri, 25 Aug 2006 15:57:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 12:57:06 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PJv679030943; Fri, 25 Aug 2006 12:57:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7PJv6Yp026672; Fri, 25 Aug 2006 12:57:06 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:57:06 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:57:05 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 14:57:04 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using, IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Ron Bonica , , , , , David Ward Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using, IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbIgKLW4T/CgzRzEdujugAKlcR7kg== In-Reply-To: <44EF52C0.2070706@juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 19:57:06.0077 (UTC) FILETIME=[A413D4D0:01C6C880] DKIM-Signature: a=rsa-sha1; q=dns; l=944; t=1156535826; x=1157399826; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using, =20IPv6=20Provider=20Edge=20Routers=20(6PE)'= 20to=20Proposed=20Standard; X=v=3Dcisco.com=3B=20h=3DOMn0xhpx6cvC6IXMsWqVcRjRA9Y=3D; b=PUtXTELVMjYqCKVoGYI6MiCBf7lsR2+50PM4482SM1EW+r0VFu6yTXGThFx80pz/+atHLdo7 0q5c+YvHWsO80c0hLh5WVju/4BdmPSXkWUsXkgTMIs39TZ4xXOlLg9UR; Authentication-Results: sj-dkim-3.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Ron - Can you send me a pointer or copy of the proposal? Going by the brief description below, it addresses another case we need to solve in softwires. Depending on the status of the draft and proposal for NH derivation, it may or may not necessarily fall into the 'legacy' bucket. So, we may or may not want to legacy techniques for deriving the AF of the NH and subsequent rules for use. Thanks -DWard On 8/25/06 2:42 PM, "Ron Bonica" wrote: > >> >> I am willing to write the document which will attempt to preserve and >> clarify legacy techniques as well as specify the solution to the the issues >> listed above to make progress. Thoughts? >> >> - -DWard > > Dave, > > If it helps at all, I am currently working on a draft that describes > procedures by which an operator can deliver IPv4 services over an IPv6 > L3VPN infrastructure. > > Ron _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 16:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGi7z-00057y-4q; Fri, 25 Aug 2006 16:18:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGi7x-00056Y-KD; Fri, 25 Aug 2006 16:18:05 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGi7v-000133-6x; Fri, 25 Aug 2006 16:18:05 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7PKI11Z080493; Fri, 25 Aug 2006 13:18:01 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7PKHvg37865; Fri, 25 Aug 2006 13:17:57 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608252017.k7PKHvg37865@merlot.juniper.net> To: David Ward Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard In-Reply-To: Your message of "Fri, 25 Aug 2006 14:13:31 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53348.1156537077.1@juniper.net> Date: Fri, 25 Aug 2006 13:17:57 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: idr@ietf.org, Bill Fenner , Yakov Rekhter , "Durand, Alain" , IESG , softwires@ietf.org, "Mark Townsley \(townsley\)" , Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Dave, > Yakov, Bill - > > Since we allow the route to an X-prefix to have a Y-address as its next hop, > we still need an SOFTWIRE|IDR document to specify how to do that. For the > cases where (a) X is VPN-IPv4 and Y is IPv4, (b) X is VPN-IPv6 and Y is > IPv4, (c) X is VPN-IPv6 and Y is IPv6, we have legacy solutions in > deployment which could easily remain valid. We also have "legacy solutions" for the cases where (d) X is IPv6 and Y is IPv4, (e) X is L2VPN and Y is IPv4, (f) X is L2VPN and Y is IPv6, (g) X is RT and Y is IPv4, (h) X is RT and Y is IPv6, ... > In addition, we need to handle the "X is VPN-IPv4 and Y is IPv6" case, See e-mail from Ron Bonica on this. > as well as the case where X is IPv4 and Y is IPv6 and the case > where X is IPv6 and Y is IPv4. X is IPv6 and Y is IPv4 is done (6PE). The only item from your list above for which the IETF does not have a solution is the case where X is IPv4 and Y is IPv6. With this in mind, why would not the softwires WG take the existing 6PE as the base and modify it to cover the case where X is IPv4 and Y is IPv6 ? > The necessary document being proposed > needs at least the following components: > > - A reinterpretation of IPv4 AFI/SAFI and IPv6 AFI/SAFI which allows the NH > to be of a different AF than the NLRI. Since the interpretation of MP_REACH/MP_UNREACH depends on a combination of AFI/SAFI, and since IPv4 or IPv6 only define AFI, which of the currently defined SAFIs need the reinterpretation ? Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 17:37:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjJf-0001jU-IT; Fri, 25 Aug 2006 17:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjJe-0001jB-3l; Fri, 25 Aug 2006 17:34:14 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGjJd-0003i0-LB; Fri, 25 Aug 2006 17:34:14 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k7PLXped004145; Sat, 26 Aug 2006 00:33:51 +0300 Date: Sat, 26 Aug 2006 00:33:51 +0300 (EEST) From: Pekka Savola To: David Ward Subject: Re: [Softwires] Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr@ietf.org, Bill Fenner , Yakov Rekhter , "Durand, Alain" , IESG , softwires@ietf.org, Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Fri, 25 Aug 2006, David Ward wrote: > I will take this to our list and we will additionally discuss at our > interim meeting (mid Sept). In all likelihood (without having gone over the > entire draft with a fine toothed comb), it will satisfy one item in our > problem space. > > If for some reason the softwires WG finds deficiencies, we will explain > ourselves. Just to shed some light to the background, as I was a v6ops co-chair at the time, this draft _specifically_ removed support for tunnel-based encapsulation as the draft's applicability was geared at MPLS deployment. I'm not sure if I'd want to have it added back. Of course, this WG is free to build on existing work to do its deliverables. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 18:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGkOO-0007m1-Cr; Fri, 25 Aug 2006 18:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGkOM-0007lF-Gp; Fri, 25 Aug 2006 18:43:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGkOL-0007uh-3G; Fri, 25 Aug 2006 18:43:10 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2006 15:43:07 -0700 X-IronPort-AV: i="4.08,170,1154934000"; d="scan'208"; a="338253519:sNHT33487040" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PMh6cw012193; Fri, 25 Aug 2006 15:43:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7PMh51E018648; Fri, 25 Aug 2006 15:43:06 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:43:05 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 15:43:05 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 17:43:04 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Yakov Rekhter , David Ward Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbIl9N2Ef3E1zSLEduUsgAKlcR7kg== In-Reply-To: <200608252017.k7PKHvg37865@merlot.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 22:43:05.0451 (UTC) FILETIME=[D453B3B0:01C6C897] DKIM-Signature: a=rsa-sha1; q=dns; l=1887; t=1156545786; x=1157409786; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using=20IPv6=20Provider=20Edge=20Routers=20(6PE)'=2 0to=20Proposed=20Standard=20; X=v=3Dcisco.com=3B=20h=3DLSzpRHTxX+blzpOhNnNOaTcbAmw=3D; b=SVMCVaHsImZbE/fU+BHgOS8p6iYY13tB0v94unUn3Uqvhmmfw/v2npZHhwnn+9/IxSi0/wP1 bSNgltWMbBMpGxVC5Jk6gpUR2T/sE0IZ4pe2FhCndY0z5fKje86dfOjG; Authentication-Results: sj-dkim-3.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: idr@ietf.org, Bill Fenner , "Durand, Alain" , IESG , softwires@ietf.org, "Mark Townsley \(townsley\)" , Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov - Please note that we have to solve the scenarios that include tunnel encapsulation aka non-MPLS deployments. Therefore, the AF/SAF needs some reinterpretation. Thanks -DWard On 8/25/06 3:17 PM, "Yakov Rekhter" wrote: > Dave, > >> Yakov, Bill - >> >> Since we allow the route to an X-prefix to have a Y-address as its next hop, >> we still need an SOFTWIRE|IDR document to specify how to do that. For the >> cases where (a) X is VPN-IPv4 and Y is IPv4, (b) X is VPN-IPv6 and Y is >> IPv4, (c) X is VPN-IPv6 and Y is IPv6, we have legacy solutions in >> deployment which could easily remain valid. > > We also have "legacy solutions" for the cases where (d) X is IPv6 > and Y is IPv4, (e) X is L2VPN and Y is IPv4, (f) X is L2VPN and Y > is IPv6, (g) X is RT and Y is IPv4, (h) X is RT and Y is IPv6, ... > >> In addition, we need to handle the "X is VPN-IPv4 and Y is IPv6" case, > > See e-mail from Ron Bonica on this. > >> as well as the case where X is IPv4 and Y is IPv6 and the case >> where X is IPv6 and Y is IPv4. > > X is IPv6 and Y is IPv4 is done (6PE). > > The only item from your list above for which the IETF does not have > a solution is the case where X is IPv4 and Y is IPv6. With this in > mind, why would not the softwires WG take the existing 6PE as the > base and modify it to cover the case where X is IPv4 and Y is IPv6 ? > >> The necessary document being proposed >> needs at least the following components: >> >> - A reinterpretation of IPv4 AFI/SAFI and IPv6 AFI/SAFI which allows the NH >> to be of a different AF than the NLRI. > > Since the interpretation of MP_REACH/MP_UNREACH depends on a combination > of AFI/SAFI, and since IPv4 or IPv6 only define AFI, which of the > currently defined SAFIs need the reinterpretation ? > > Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 19:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGkjL-0001iz-6H; Fri, 25 Aug 2006 19:04:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGkjI-0001ij-Pt for idr@ietf.org; Fri, 25 Aug 2006 19:04:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGhxi-0008NH-JZ for idr@ietf.org; Fri, 25 Aug 2006 16:07:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGhl0-0005CX-Fa for idr@ietf.org; Fri, 25 Aug 2006 15:54:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 12:54:22 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PJsLcj008892; Fri, 25 Aug 2006 12:54:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7PJsLQV022109; Fri, 25 Aug 2006 12:54:21 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:54:21 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 12:54:20 -0700 Message-ID: <44EF556C.8040906@cisco.com> Date: Fri, 25 Aug 2006 12:54:20 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> <44EF35E9.4020501@cisco.com> <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> In-Reply-To: <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 19:54:20.0805 (UTC) FILETIME=[41915350:01C6C880] DKIM-Signature: a=rsa-sha1; q=dns; l=1724; t=1156535661; x=1157399661; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DyIdn9HPC+c1w1MkpvqaleAkNvAg=3D; b=qsK56ZZYPwcDyjhH9I0+3ipLZzRfvIymRrDruJUT40MVNyzyoYbGkjsyr88FHTMp2iJxa5FF 83tR6SYLJirtI6FO8MGcPbn5fEEXbOzUtLuP2W7CbGLbpyN+DfdaTfE/; Authentication-Results: sj-dkim-2.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: raszuk@cisco.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav: Manav Bhatia wrote: > > We had some feedback from the IX operators where they wanted > asymmetric routes exchange. That is, while the IX clients would > advertise their best routes, the route server needs to advertise *all* > the routes learnt from all its IX clients to each client. Adding a bit > in the capability that does this didn't seem to be much of an > overhead! :) > Here you emphasize the need for the route server to advertise *all* the routes. I think that is valid, and a solution must be able to accomplish that. This point is also presented in your proposal: ----------------------------------------------------------------------------------------------------------- 9.3 eBGP mesh scaling at IXes via Route Servers [...] If there were a mechanism in BGP to allow an IX route-server to pass all other advertisements to a customer peer, without performing any path selection or applying any policy, then ... ----------------------------------------------------------------------------- Let us look at this example: (X) R1 R2 R3 | | | -------------------------- | RS The RS peers with R1, R2, and R3 and advertise *all* the routes back. However, once R1 and R2 start to peer with each other: - R1 learns X from R2. - Both R1 and R2 advertise X (with R2 as the nexthop) to RS. How does RS advertise two paths from R1 and R2 for X to R3? (The two paths have the same nexthop, but different as-path attributes). -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 25 23:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGp9i-0007UX-LB; Fri, 25 Aug 2006 23:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGp9h-0007Tk-5L for idr@ietf.org; Fri, 25 Aug 2006 23:48:21 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGp9f-0000Rq-Qj for idr@ietf.org; Fri, 25 Aug 2006 23:48:21 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id UAA17694; Fri, 25 Aug 2006 20:48:18 -0700 (PDT) Received: from manavLpt ([10.128.16.181]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 20:48:17 -0700 Message-ID: <022201c6c8c2$774d40c0$0201a8c0@rs.riverstonenet.com> From: "Manav Bhatia" To: "Enke Chen" References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> <44EF35E9.4020501@cisco.com> <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> <44EF556C.8040906@cisco.com> Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Date: Sat, 26 Aug 2006 09:18:12 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Aug 2006 03:48:17.0836 (UTC) FILETIME=[775BE6C0:01C6C8C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: raszuk@cisco.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Enke, In addition to what Joel said. > Let us look at this example: > > > (X) > R1 R2 R3 > | | | > -------------------------- > | > RS > > > The RS peers with R1, R2, and R3 and advertise *all* the routes back. > > However, once R1 and R2 start to peer with each other: > > - R1 learns X from R2. > - Both R1 and R2 advertise X (with R2 as the nexthop) to RS. Are you suggesting that R1 will advertise the route (X) it learnt from the RS back to the RS? This goes against the basic tenets of BGP; You cannot advertise a route that you learnt from a peer back to that peer. This isnt how BGP works in the IXes. If it did this way then R3 would be lying by advertising X (with R2 as the nexthop) and path { R1 R2 .. } because the path *does not* go through R1. Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 26 00:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpik-0001Mj-Cu; Sat, 26 Aug 2006 00:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpij-0001Md-2D for idr@ietf.org; Sat, 26 Aug 2006 00:24:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGpih-0006wg-OC for idr@ietf.org; Sat, 26 Aug 2006 00:24:33 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 21:24:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7Q4OVMM000608; Fri, 25 Aug 2006 21:24:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7Q4OVYp003949; Fri, 25 Aug 2006 21:24:31 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 21:24:30 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 21:24:30 -0700 Message-ID: <44EFCCF9.3040907@cisco.com> Date: Fri, 25 Aug 2006 21:24:25 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manav Bhatia Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> <44EF35E9.4020501@cisco.com> <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> <44EF556C.8040906@cisco.com> <022201c6c8c2$774d40c0$0201a8c0@rs.riverstonenet.com> In-Reply-To: <022201c6c8c2$774d40c0$0201a8c0@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2006 04:24:30.0616 (UTC) FILETIME=[866FD180:01C6C8C7] DKIM-Signature: a=rsa-sha1; q=dns; l=1947; t=1156566271; x=1157430271; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20draft-bhatia-bgp-multiple-next-hops-01. txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=SdKQ4WFGtZnCNtCO2ixFx+o/6BaSSdxsw71UIiQnOvh7zIh8i1vqUzrcMhFMS5ObirFhCG5G 4REswWlncCR39g0QlFAqIeNwsUs553D3L3pbDU1vWOgveCy+BW3+5KhX; Authentication-Results: sj-dkim-1.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: raszuk@cisco.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Manav, Manav Bhatia wrote: > Enke, > > In addition to what Joel said. > >> Let us look at this example: >> >> >> (X) >> R1 R2 R3 >> | | | >> -------------------------- >> | >> RS >> >> >> The RS peers with R1, R2, and R3 and advertise *all* the routes back. >> >> However, once R1 and R2 start to peer with each other: >> >> - R1 learns X from R2. >> - Both R1 and R2 advertise X (with R2 as the nexthop) to RS. > > > Are you suggesting that R1 will advertise the route (X) it learnt from > the RS back to the RS? This goes against the basic tenets of BGP; You > cannot advertise a route that you learnt from a peer back to that peer. No, see above ("R1 learns X from R2" via their direct peering session). > > This isnt how BGP works in the IXes. If it did this way then R3 would > be lying by advertising X (with R2 as the nexthop) and path { R1 R2 .. > } because the path *does not* go through R1. There are various types of relationships among the peers at the IXes, including provider- provider, customer-provider, and 3rd party nexthops. (I do know a little bit about the IXes as I used to work for a large ISP, and dealt with the peering issues at the IXes.) I do not think it is up to us to decide what the providers can do or can not do at the IXes. Clearly these are two different paths with different as-paths. As you stated in your proposal, the RS should not apply policy. It is up to the clients of the RS to apply policy (such as filtering, assigning preferences). Due to the difference in the as-paths, the policy of a client may treat these paths differently. I am not sure if we are getting into the debate about the definition of *all* routes on the RS. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 26 00:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpoX-0004TR-FK; Sat, 26 Aug 2006 00:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGpoW-0004TM-2C for idr@ietf.org; Sat, 26 Aug 2006 00:30:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGpoT-0007Rn-MC for idr@ietf.org; Sat, 26 Aug 2006 00:30:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 25 Aug 2006 21:30:29 -0700 X-IronPort-AV: i="4.08,170,1154934000"; d="scan'208"; a="1850449967:sNHT33670148" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7Q4UT8F016207; Fri, 25 Aug 2006 21:30:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7Q4USQV002138; Fri, 25 Aug 2006 21:30:28 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 21:30:28 -0700 Received: from [10.21.113.249] ([10.21.113.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 21:30:28 -0700 Message-ID: <44EFCE63.8020804@cisco.com> Date: Fri, 25 Aug 2006 21:30:27 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> <44EF35E9.4020501@cisco.com> <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> <44EF556C.8040906@cisco.com> <7.0.1.0.0.20060825231208.033231c0@stevecrocker.com> In-Reply-To: <7.0.1.0.0.20060825231208.033231c0@stevecrocker.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2006 04:30:28.0230 (UTC) FILETIME=[5B976260:01C6C8C8] DKIM-Signature: a=rsa-sha1; q=dns; l=2622; t=1156566629; x=1157430629; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20=20=20draft-bhatia-bgp-multiple-next-hops- 01.txt; X=v=3Dcisco.com=3B=20h=3DD/xXM8993FtgmwQe1uOqxBX5ju0=3D; b=Isswgm2qclaKK695z4d16FTdDd5QMPZ5Gh+eC55Mvq7J9reT7WrSixSPvgRpzfWMv1jd3wGf SGPXsZ4YTG4ulJrnrIXJdnynIQayMtaBeSk9W9PzSjNG6UtGPFi1+rQ7; Authentication-Results: sj-dkim-3.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Joel: They are different routes on the RS as the AS-PATHs are different. Each client needs to prepend its AS number when advertising to the RS. (The RS may skip its own AS number in advertising.) -- Enke Joel M. Halpern wrote: > I am missing something. I don't believe that "all" the routes > requires the inclusion of redundancy. Whether R1 or R2 sends the > advertisement, with the same AS Path and the same Next Hop (R2), there > is no need for the route server to send that advertisement twice. it > will not add information. > Yours, > Joel > > At 03:54 PM 8/25/2006, Enke Chen wrote: > >> Manav: >> >> Manav Bhatia wrote: >> >>> >>> We had some feedback from the IX operators where they wanted >>> asymmetric routes exchange. That is, while the IX clients would >>> advertise their best routes, the route server needs to advertise >>> *all* the routes learnt from all its IX clients to each client. >>> Adding a bit in the capability that does this didn't seem to be much >>> of an overhead! :) >> >> >> Here you emphasize the need for the route server to advertise *all* >> the routes. I think that is valid, and a solution must be able to >> accomplish that. This point is also presented in your proposal: >> >> ----------------------------------------------------------------------------------------------------------- >> >> >> 9.3 eBGP mesh scaling at IXes via Route Servers >> [...] >> >> If there were a mechanism in BGP to allow an IX route-server to pass >> all other advertisements to a customer peer, without performing any >> path selection or applying any policy, then ... >> >> ----------------------------------------------------------------------------- >> >> >> >> Let us look at this example: >> >> >> (X) >> R1 R2 R3 >> | | | >> -------------------------- >> | >> RS >> >> >> The RS peers with R1, R2, and R3 and advertise *all* the routes back. >> >> However, once R1 and R2 start to peer with each other: >> >> - R1 learns X from R2. >> - Both R1 and R2 advertise X (with R2 as the nexthop) to RS. >> >> How does RS advertise two paths from R1 and R2 for X to R3? (The two >> paths >> have the same nexthop, but different as-path attributes). >> >> -- Enke >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 26 17:54:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH62W-0002wf-0f; Sat, 26 Aug 2006 17:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH62V-0002wa-3w for idr@ietf.org; Sat, 26 Aug 2006 17:50:03 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GH62Q-0006GY-7n for idr@ietf.org; Sat, 26 Aug 2006 17:50:03 -0400 Received: from gihm3.apnic.net (dhcp14.potaroo.net [203.10.60.14]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k7QLna1f053911; Sun, 27 Aug 2006 07:49:37 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20060827073433.0110e550@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 27 Aug 2006 07:49:33 +1000 To: MAEMURA Akinori , enkechen@cisco.com From: Geoff Huston Subject: Re: [Idr] 4byteASN? In-Reply-To: <200608181431.DGD82352.FNBN@maem.org> References: <200608181252.CHH65179.FNNB@maem.org> <44E54D26.7090706@cisco.com> <200608181431.DGD82352.FNBN@maem.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: rcallon@juniper.net, idr@ietf.org, fenner@research.att.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The pace of this document through IESG review so far is not exactly quick to day the least: * Publication requested:12 November 2005 * Publication Request entered into the Datatracker: 16 December 2005 * State Change to AD Evaluation: 12 June 2006 Its now late August 2006, so its now taken 9 months to get the document this far. At this pace it looks more and more likely that the Internet will run out of 16bit AS numbers well before this draft ever gets close to publication. The RIRs are on a track to commence allocation of these 4 byte AS values by January 2007 in order to meet the anticipated lead times for production deployment in the industry today. To meet this objective IANA will need to expand the AS number registry and make initial assignments to the RIRs from the 4-byte AS number range before this date. Naturally this would be preferred if the IANA (and the RIRs, and vendors, and ISPs, and...) were acting on a published RFC that specified this as an industry standard, rather than having to make ad hoc arrangements based on draft that is anticipated to be published as a standard sometime this century. My question to the ADs is: why this document appears to be on such a remarkably slow IESG evaluation track? regards, Geoff At 03:31 PM 18/08/2006, MAEMURA Akinori wrote: >Thanks Enke. > >Only I needed to learn was this datatracker... :-( > >Regards, >Akinori > > >In message <44E54D26.7090706@cisco.com> > "Re: [Idr] 4byteASN?" > "Enke Chen " wrote: > >| The draft finished the IDR WG last call, and was submitted to the IESG >| for review last November. >| >| The current status of the draft is "AD Evaluation" according to the IESG >| status page: >| >| >| >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6498&rfc_flag=0 >| >| -- Enke >| >| MAEMURA Akinori wrote: >| >| >Folks, >| > >| >draft-ietf-idr-as4bytes-12.txt was to be expired in May 2006. >| > >| >I'm not a regular IETF participant, then my only information >| >sources are idr@ietf and ietf@ietf. I haven't seen any >| >discussion since then, nor I cannot find anything in rfc- >| >queue. >| > >| >Can someone tell me what the status for this draft? >| > >| > >| >Since RIRs move forward assignment of 4byte ASN - e.g. APNIC >| >>from January 2007 on-demand, I'd like to think about >| >experimental assignment like net39 class-A subnetting before >| >4byte ASN is widely used. >| > >| > >| >Regards, >| >Akinori >| > >| >----- >| >MAEMURA Akinori maem@maem.org >| > >| >_______________________________________________ >| >Idr mailing list >| >Idr@ietf.org >| >https://www1.ietf.org/mailman/listinfo/idr >| > >| > >| > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 27 12:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHNkH-0007LX-2K; Sun, 27 Aug 2006 12:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHNkF-0007Ic-3E; Sun, 27 Aug 2006 12:44:23 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHNkC-0007pZ-N9; Sun, 27 Aug 2006 12:44:23 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7RGiI1Z092585; Sun, 27 Aug 2006 09:44:18 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7RGiIg53535; Sun, 27 Aug 2006 09:44:18 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608271644.k7RGiIg53535@merlot.juniper.net> To: David Ward Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard In-Reply-To: Your message of "Fri, 25 Aug 2006 17:43:04 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39284.1156697058.1@juniper.net> Date: Sun, 27 Aug 2006 09:44:18 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: idr@ietf.org, Bill Fenner , "Durand, Alain" , IESG , softwires@ietf.org, "Mark Townsley \(townsley\)" , Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Dave, > Yakov - > > Please note that we have to solve the scenarios that include tunnel > encapsulation aka non-MPLS deployments. By "non-MPLS deployment" do you mean that the tunnels can not be LSPs, or do you mean that there should be no MPLS at all, even at the edges (PEs) ? > Therefore, the AF/SAF needs some reinterpretation. You still did not answer my question. Namely, which of the AFI/SAFIs currently defined by IETF need "some reinterpretation" ? Yakov. > > > Thanks > > -DWard > > > On 8/25/06 3:17 PM, "Yakov Rekhter" wrote: > > > Dave, > > > >> Yakov, Bill - > >> > >> Since we allow the route to an X-prefix to have a Y-address as its next ho p, > >> we still need an SOFTWIRE|IDR document to specify how to do that. For th e > >> cases where (a) X is VPN-IPv4 and Y is IPv4, (b) X is VPN-IPv6 and Y is > >> IPv4, (c) X is VPN-IPv6 and Y is IPv6, we have legacy solutions in > >> deployment which could easily remain valid. > > > > We also have "legacy solutions" for the cases where (d) X is IPv6 > > and Y is IPv4, (e) X is L2VPN and Y is IPv4, (f) X is L2VPN and Y > > is IPv6, (g) X is RT and Y is IPv4, (h) X is RT and Y is IPv6, ... > > > >> In addition, we need to handle the "X is VPN-IPv4 and Y is IPv6" case, > > > > See e-mail from Ron Bonica on this. > > > >> as well as the case where X is IPv4 and Y is IPv6 and the case > >> where X is IPv6 and Y is IPv4. > > > > X is IPv6 and Y is IPv4 is done (6PE). > > > > The only item from your list above for which the IETF does not have > > a solution is the case where X is IPv4 and Y is IPv6. With this in > > mind, why would not the softwires WG take the existing 6PE as the > > base and modify it to cover the case where X is IPv4 and Y is IPv6 ? > > > >> The necessary document being proposed > >> needs at least the following components: > >> > >> - A reinterpretation of IPv4 AFI/SAFI and IPv6 AFI/SAFI which allows the NH > >> to be of a different AF than the NLRI. > > > > Since the interpretation of MP_REACH/MP_UNREACH depends on a combination > > of AFI/SAFI, and since IPv4 or IPv6 only define AFI, which of the > > currently defined SAFIs need the reinterpretation ? > > > > Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 27 16:27:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHRAS-0002RF-Pi; Sun, 27 Aug 2006 16:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHRAR-0002Qy-7r; Sun, 27 Aug 2006 16:23:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHP4t-0002Ir-Ih; Sun, 27 Aug 2006 14:09:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHOsC-0004OP-LA; Sun, 27 Aug 2006 13:56:42 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2006 10:56:40 -0700 X-IronPort-AV: i="4.08,174,1154934000"; d="scan'208"; a="314531479:sNHT35823192" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7RHudxF020462; Sun, 27 Aug 2006 10:56:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7RHudw7004859; Sun, 27 Aug 2006 10:56:39 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Aug 2006 10:56:39 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Aug 2006 10:56:38 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 27 Aug 2006 12:56:36 -0500 Subject: Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard From: David Ward To: Yakov Rekhter , David Ward Message-ID: Thread-Topic: [Idr] Re: Last Call: 'Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to Proposed Standard Thread-Index: AcbKAiNxYiPotDX1EduABQAKlcR7kg== In-Reply-To: <200608271644.k7RGiIg53535@merlot.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Aug 2006 17:56:38.0507 (UTC) FILETIME=[24EFABB0:01C6CA02] DKIM-Signature: a=rsa-sha1; q=dns; l=4800; t=1156701399; x=1157565399; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Connecting=20IPv6=20Islands=20 over=20IPv4=20MPLS=0A=20using=20IPv6=20Provider=20Edge=20Routers=20(6PE)'=2 0to=20Proposed=20Standard=20; X=v=3Dcisco.com=3B=20h=3DLSzpRHTxX+blzpOhNnNOaTcbAmw=3D; b=qkOajDpNElIXAsHl7GlVsCyLQzH6SRf+AY5/LcvU70aWAUJMuUKMbboyAJX7DzyDMAZjWjFE lP9InVsqNd4vWEnx+PoydH6CLAvdLsQ0mkTWnfSnnZn/1OII9ZXh8kPc; Authentication-Results: sj-dkim-8.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: idr@ietf.org, Bill Fenner , "Durand, Alain" , IESG , softwires@ietf.org, "Mark Townsley \(townsley\)" , Sam Hartman X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov - On 8/27/06 11:44 AM, "Yakov Rekhter" wrote: > Dave, > >> Yakov - >> >> Please note that we have to solve the scenarios that include tunnel >> encapsulation aka non-MPLS deployments. > > By "non-MPLS deployment" do you mean that the tunnels can not be LSPs, > or do you mean that there should be no MPLS at all, even at the edges > (PEs) ? > The tunnels cannot be LSPs in all scenarios. The Softwires framework (under evolution) states that VPNs and non VPNs must be allowed to be present (as well as mcast and secure solutions). The point is definitely NOT to dictate that the entire network MUST be MPLS-free. We want our cake and eat it too. >> Therefore, the AF/SAF needs some reinterpretation. > > You still did not answer my question. Namely, which of the AFI/SAFIs > currently defined by IETF need "some reinterpretation" ? > As discussed earlier, it appears that the 6PE solution applies in a particular scenario. Also, I mentioned the upcoming softwires interim meeting where we are working to further pull together a framework that will describe in more detail the applicability of NH reinterpretation. My first goal here was stated in the thread but, it was lost in our exchange: - A specification of how you tell what the address family of the NH is. - Rules to specify what address family the NH should be specified in when a route is advertised. - A reinterpretation of IPv4 AFI/SAFI and IPv6 AFI/SAFI which allows the NH to be of a different AF than the NLRI. This would include the requirements for non-MPLS tunneled scenarios. The last piece we can work through in our WGs as the softwires framework becomes more mature. If you feel it would help, I'd be willing to attempt to draft some clarity as our thread isn't a good mechanism of archiving any conclusions we have reached. My second goal w/ softwires is not to create an upheaval in massive deployments of existing technology. Where there are cases of emerging technology (softwires, unseen Bonica draft, multiple NH in BGP), the WGs can discuss if "length assumptions|addr translation" works in all cases or, if an extension is appropriate to clearly state semantics of the protocol. I bring up the multiple-NH issue as it is another case where NH semantics may need reinterpretation. Since there are multiple discussions on NH semantics in BGP, I don't think we can avoid clarification and eventual resolution. Unfort our discusson may have been of little use for the review of the 6PE draft. We have been discussing a tangential issue. The only point is that the 6PE solution (addr translation) is not a universal solution to the softwires problem and does not solve all our scenarios. Should my comments in any way prevent the draft from progressing? At the very least, it may cause a draft to be written that clarifies BGP NH semantics and interpretation techniques in different scenarios. -DWard > Yakov. > >> >> >> Thanks >> >> -DWard >> >> >> On 8/25/06 3:17 PM, "Yakov Rekhter" wrote: >> >>> Dave, >>> >>>> Yakov, Bill - >>>> >>>> Since we allow the route to an X-prefix to have a Y-address as its next ho > p, >>>> we still need an SOFTWIRE|IDR document to specify how to do that. For th > e >>>> cases where (a) X is VPN-IPv4 and Y is IPv4, (b) X is VPN-IPv6 and Y > is >>>> IPv4, (c) X is VPN-IPv6 and Y is IPv6, we have legacy solutions in >>>> deployment which could easily remain valid. >>> >>> We also have "legacy solutions" for the cases where (d) X is IPv6 >>> and Y is IPv4, (e) X is L2VPN and Y is IPv4, (f) X is L2VPN and Y >>> is IPv6, (g) X is RT and Y is IPv4, (h) X is RT and Y is IPv6, ... >>> >>>> In addition, we need to handle the "X is VPN-IPv4 and Y is IPv6" case, >>> >>> See e-mail from Ron Bonica on this. >>> >>>> as well as the case where X is IPv4 and Y is IPv6 and the case >>>> where X is IPv6 and Y is IPv4. >>> >>> X is IPv6 and Y is IPv4 is done (6PE). >>> >>> The only item from your list above for which the IETF does not have >>> a solution is the case where X is IPv4 and Y is IPv6. With this in >>> mind, why would not the softwires WG take the existing 6PE as the >>> base and modify it to cover the case where X is IPv4 and Y is IPv6 ? >>> >>>> The necessary document being proposed >>>> needs at least the following components: >>>> >>>> - A reinterpretation of IPv4 AFI/SAFI and IPv6 AFI/SAFI which allows the > NH >>>> to be of a different AF than the NLRI. >>> >>> Since the interpretation of MP_REACH/MP_UNREACH depends on a combination >>> of AFI/SAFI, and since IPv4 or IPv6 only define AFI, which of the >>> currently defined SAFIs need the reinterpretation ? >>> >>> Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 28 14:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmGH-0007Up-DP; Mon, 28 Aug 2006 14:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmGG-0007Uk-Da for idr@ietf.org; Mon, 28 Aug 2006 14:55:04 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmGF-0008EC-6o for idr@ietf.org; Mon, 28 Aug 2006 14:55:04 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id ECED8147C71; Mon, 28 Aug 2006 14:55:02 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k7SIt2jJ015684; Mon, 28 Aug 2006 11:55:02 -0700 From: Bill Fenner Message-Id: <200608281855.k7SIt2jJ015684@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Geoff Huston Subject: Re: [Idr] 4byteASN? References: <200608181252.CHH65179.FNNB@maem.org> <44E54D26.7090706@cisco.com> <200608181431.DGD82352.FNBN@maem.org> <7.0.0.16.2.20060827073433.0110e550@apnic.net> Date: Mon, 28 Aug 2006 11:55:02 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rcallon@juniper.net, idr@ietf.org, MAEMURA Akinori X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >The pace of this document through IESG review so far is not exactly >quick to day the least. You're right, it hasn't been. I worked last week to get the implementation report posted in preparation for IETF Last Call. It's now posted, and the Last Call should go out today or tomorrow. >My question to the ADs is: why this document appears to be on such a >remarkably slow IESG evaluation track? The short answer is that it's not unusual. While we have goals that add up to about 1.5 months to get through the IESG, it's common to miss the goals by an order of magnitude. http://rtg.ietf.org:8080/Test/tracker_exceptions lists documents by their desired action date; I've been working down this list by worst-missed milestone and got to the as4bytes draft last week. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 28 17:48:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHovE-0007tM-4I; Mon, 28 Aug 2006 17:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHovC-0007tD-QQ; Mon, 28 Aug 2006 17:45:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHnXx-0003IL-GG; Mon, 28 Aug 2006 16:17:25 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHnIn-0006zi-Od; Mon, 28 Aug 2006 16:01:47 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7ADAC176A4; Mon, 28 Aug 2006 20:01:15 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GHnIJ-00054j-2W; Mon, 28 Aug 2006 16:01:15 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 28 Aug 2006 16:01:15 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: idr@ietf.org Subject: [Idr] Last Call: 'BGP Support for Four-octet AS Number Space' to Proposed Standard (draft-ietf-idr-as4bytes) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'BGP Support for Four-octet AS Number Space ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-12.txt The implementation report can be obtained via http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 28 21:30:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHsPA-00005E-Fr; Mon, 28 Aug 2006 21:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHsP9-000050-59; Mon, 28 Aug 2006 21:28:39 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHsP8-0001hk-MF; Mon, 28 Aug 2006 21:28:39 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7T1SV1Z017145; Mon, 28 Aug 2006 18:28:31 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7T1SRg42046; Mon, 28 Aug 2006 18:28:27 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200608290128.k7T1SRg42046@merlot.juniper.net> To: "Chris Metz \(chmetz\)" Subject: Re: [Softwires] Re: [Idr] Re: Last Call: 'Connecting IPv6 Islands overIPv4 MPLS using IPv6 Provider Edge Routers (6PE)' to ProposedStandard In-Reply-To: Your message of "Mon, 28 Aug 2006 20:14:55 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78620.1156814907.1@juniper.net> Date: Mon, 28 Aug 2006 18:28:27 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: idr@ietf.org, Bill Fenner , Yakov Rekhter , "Durand, Alain" , IESG , softwires@ietf.org, Sam Hartman , David Ward X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Chris, > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, August 25, 2006 11:28 AM > > To: David Ward > > Cc: idr@ietf.org; Bill Fenner; Durand,Alain; IESG; > > softwires@ietf.org; Sam Hartman > > Subject: [Softwires] Re: [Idr] Re: Last Call: 'Connecting > > IPv6 Islands overIPv4 MPLS using IPv6 Provider Edge Routers > > (6PE)' to ProposedStandard > > > > David, > > > > > Yakov, Bill - > > > > > > Having read the document I have some initial comments. > > First, 6PE is > > > an excellent solution. Overstating the obvious (perhaps my greatest > > > talent), this is a solution for the subset of softwire > > problems that > > > would be used for 6-over-4 when the encaps policy is > > "always use MPLS" > > > and there are no security requirements. I will leave the > > question of > > > 'no security requirements' for this solution to others. > > > > > > The major deficiency from a softwires vantage point is that > > the v4 NH > > > gets encoded in a v6 format, but semantically it's v4 and this > > > encoding trick doesn't work when you're doing v6 over v4. > > This is not > > > to say the solution doesn't work but, since softwires has to solve > > > both v4 over v6 and v6 over > > > v4 (and variants including VPNs); I strongly urge that we > > don't have > > > multiple techniques to derive the AF of the NH. > > > > As we move forward, I agree with the goal of having a single > technique to derive AF of the NH within the context of > > MP_REACH/MP_UNREACH. > > Second that ... > > > > The current advancement of multiple techniques that require either > > > encoding or length-check should be cleared up and made > > > obvious and consistent. > > > > > > I recommend some number of bits (or a byte) be used to state clearly > > > what the AF of the NH is and leave in original encoding. A capability > > > can be added to make sure that a peer can understand the new bits. > > > Of course, I am looking for the minimal change to the doc and to > > > BGP but, this matter needs to be discussed. The assumptions becoming > > > embedded in the techniques of how to figure out what the actual AF > > > of the NH could be easily cleared up w/ the suggestion of just very > > > small number of bits and a capability in BGP. > > > > While having "new bits" may be sufficient, it is by no means > > necessary. This is because the current/original encoding > > already provides a way to distinguish between IPv4 and IPv6 > > addresses in the NH of MP_REACH/MP_UNREACH. I am referring to > > the approach already used in several documents approved by > > the IETF (e.g., draft-ietf-l2vpn-signaling, > > draft-ietf-l3vpn-rt-constrain, > > draft-ietf-l2vpn-vpls-bgp) where the NH Length field is used > > to distinguish between IPv4 and IPv6 as the NH. > > In the IETF docs you site, it seems like the use of NH length as a > protocol distinguisher is driven by the fact that MP-BGP is functioning > not as a routing protocol but rather as a multi-router distribution > vehicle for provisioning/signaling/policy information. Are you sure that in the docs I site the use of NH length as a protocol distinguisher "is driven by the fact that MP-BGP is functioning not as a routing protocol but rather as a multi-router distribution vehicle" ? The reason I am asking this question is that I happened to be a co-author on one of the docs (draft-ietf-l2vpn-vpls-bgp), and be quite involved in the design of the other (draft-ietf-l3vpn-rt-constrain). And in both of these cases the use of NH length was driven solely by pragmatism, rather than by a rather theoretical (and largely irrelevant) consideration on whether BGP is "a routing protocol", or "a multi-router distribution vehicle". > One must > use what fields are available in the MP_REACH/MP_UNREACH even if > the length of a particular field indicates its type. > > With routing protocols I have always assumed that there are explicit > type fields to identify a particular protocol value. May I suggest that you revisit this assumption, as it clearly does not match the reality of BGP. > > And just for completeness, the current/original encoding > > provides yet another way to distingush between IPv4 and IPv6 > > as the NH addresses - use two different SAFIs to distinguish > > between IPv4 and > > IPv6 as the NH. However, I am not aware of any IETF > > technologies that use this approach. > > Is SAFI explosion a potential problem? Perhaps, but only in theory. Of course, as I like to say while in theory there is no difference between the theory and the practice, in practice there is... > I am thinking we would need > O(X * Y) number of new values where X is the AFI/SAFI carried across the > transport network and Y is the AFI/SAFI of the transport network. In the context of IETF the transport network is either IPv4 or IPv6. Which means that that if one uses two different SAFIs for every application that uses Multiprotocol BGP (one to indicate IPv4 transport and another to indicate IPv6 transport), then we'll be able to support 128 of such applications. That seems more than enough from a practical point of view... Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 30 15:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIViJ-0002dp-PE; Wed, 30 Aug 2006 15:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIViI-0002dZ-J1 for idr@ietf.org; Wed, 30 Aug 2006 15:27:02 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIViG-00051z-Td for idr@ietf.org; Wed, 30 Aug 2006 15:27:02 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+C4XBkmpbvFj/oM9R/CMhWQJVZ8gjHxf8@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7UJQPH8025726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 20:26:38 +0100 Date: Wed, 30 Aug 2006 20:26:25 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Enke Chen Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <44EFCCF9.3040907@cisco.com> Message-ID: References: <007d01c6c825$fc1d94a0$260218ac@rs.riverstonenet.com> <44EF186E.8050107@cisco.com> <016901c6c865$f05ce630$0201a8c0@rs.riverstonenet.com> <44EF35E9.4020501@cisco.com> <021c01c6c86f$8c1e2a30$0201a8c0@rs.riverstonenet.com> <44EF556C.8040906@cisco.com> <022201c6c8c2$774d40c0$0201a8c0@rs.riverstonenet.com> <44EFCCF9.3040907@cisco.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1772/Wed Aug 30 17:01:16 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Enke, On Fri, 25 Aug 2006, Enke Chen wrote: > There are various types of relationships among the peers at the > IXes, including provider- provider, customer-provider, and 3rd > party nexthops. (I do know a little bit about the IXes as I used > to work for a large ISP, and dealt with the peering issues at the > IXes.) I do not think it is up to us to decide what the providers > can do or can not do at the IXes. We don't think it's a problem. The job of the RS is to propogate paths from the one speaker to all other participating speakers. Ergo only the 'exit' path needs be propogated, and the speaker providing that exit path can peer with the RS and advertise it to the RS if it wishes all other RS-client speakers to see it. The cases I've seen of 3rd-nexthop at shared networks have been simply due to people not bothering to setup peering due to administrative overheads - the removal of such overheads being the reason for this draft. For cases where the 'exit' speaker does not wish to directly provide the path to an RS, it likely would not want others to do so either. It makes no difference whether in such a case whether the RS uses add-path/multiple-next-hop. In short, the RS solves the reason for much of the use of 3rd-p-n. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Teacher, my shoes are making noise." --Ralph Wiggum Last Tap Dance in Springfield (Episode BABF15) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 30 16:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWVJ-0007qG-H2; Wed, 30 Aug 2006 16:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWVI-0007pv-1A for idr@ietf.org; Wed, 30 Aug 2006 16:17:40 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWVF-0004OD-J7 for idr@ietf.org; Wed, 30 Aug 2006 16:17:40 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k7UKOSEO084246; Wed, 30 Aug 2006 16:24:28 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> To: Paul Jakma Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-reply-to: Your message of "Wed, 30 Aug 2006 20:26:25 BST." Date: Wed, 30 Aug 2006 16:24:28 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Paul Jakma writes: > > Hi Enke, > > On Fri, 25 Aug 2006, Enke Chen wrote: > > > There are various types of relationships among the peers at the > > IXes, including provider- provider, customer-provider, and 3rd > > party nexthops. (I do know a little bit about the IXes as I used > > to work for a large ISP, and dealt with the peering issues at the > > IXes.) I do not think it is up to us to decide what the providers > > can do or can not do at the IXes. > > We don't think it's a problem. The job of the RS is to propogate > paths from the one speaker to all other participating speakers. Ergo > only the 'exit' path needs be propogated, and the speaker providing > that exit path can peer with the RS and advertise it to the RS if it > wishes all other RS-client speakers to see it. > > The cases I've seen of 3rd-nexthop at shared networks have been > simply due to people not bothering to setup peering due to > administrative overheads - the removal of such overheads being the > reason for this draft. > > For cases where the 'exit' speaker does not wish to directly provide > the path to an RS, it likely would not want others to do so either. > It makes no difference whether in such a case whether the RS uses > add-path/multiple-next-hop. > > In short, the RS solves the reason for much of the use of 3rd-p-n. > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > "Teacher, my shoes are making noise." Paul, You can't propose a protocol extension where routes cannot be distinguished when a legitimate example is given just because the example is in your opinion "something no one would want to do". It is true that most peerings use "next hop self" at an exchange where a route server is located, however if two peers did not set next hop self and provided third party routes with the same next hop to the RS, there would be no way to make these routes unambiguous. So far we haven't seen a similar case that might arise with similar slight misconfiguration of RR however RR are all within a single administrative domain making any misconfiguration easier to fix. If the major difference between draft-bhatia-bgp-multiple-next-hops and draft-walton-bgp-add-paths is that the latter provides a way to make such cases unambiguous, then IDR needs to set aside the former. It seems that we now have an example where the path identifier in draft-walton-bgp-add-paths-05.txt is needed. It is a case where a RS is in use and some routers with private peerings are not setting next-hop-self. It is not a likely configuration given the policies of most public interconnects but it is a legitimate configuration. Even if it were considered a misconfiguration protocol extensions must accommodate minor misconfigurations. I don't recall seeing any objections to the use of path identifier in draft-walton-bgp-add-paths that held up. A clarification is needed regarding the path identifier being only session specific and not global but otherwise no change has been called for. draft-walton-bgp-add-paths is also a shorter document due to the approach being simpler. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 05:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIile-0007uQ-JT; Thu, 31 Aug 2006 05:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIilc-0007nd-P2 for idr@ietf.org; Thu, 31 Aug 2006 05:23:20 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIilb-0000uS-Us for idr@ietf.org; Thu, 31 Aug 2006 05:23:20 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1917nv2dUxsTRIB6NvGkpKGW+2/FcrqY5s@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7V9MkZ9011575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Aug 2006 10:22:59 +0100 Date: Thu, 31 Aug 2006 10:22:46 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Curtis Villamizar Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> Message-ID: References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1779/Thu Aug 31 08:56:15 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Curtis, On Wed, 30 Aug 2006, Curtis Villamizar wrote: > You can't propose a protocol extension where routes cannot be > distinguished when a legitimate example is given just because the > example is in your opinion "something no one would want to do". It's not a consideration because the exit-peer can easily peer with the RS in Enke's example. 3-p-n generally is discouraged, it has reliability problems - it's the poor man's substitute for direct peering (usually administrative overhead of setting it up). Certainly at IXes we know of it is generally discouraged. Its use tends to be primarily because of the /lack/ of eBGP RS solutions. We'd be interested in any plausible cases where a peer would /not/ want to advertise the path to the RS, but would be happy for other peers to advertise the path to the RS (and hence all RS-client peers). We can't quite think of them. > It is true that most peerings use "next hop self" at an exchange > where a route server is located, however if two peers did not set > next hop self and provided third party routes with the same next > hop to the RS, there would be no way to make these routes > unambiguous. There's no ambiguity, the RS just doesn't accept paths from peers which won't forward the path. That's not a problem a route-server is there to solve. However, if the exit peer wants to peer with the RS, and hence *remove* the need for others to advertise path with it as nexthop, then that is exactly what the RS is there for, that's exactly the problem the IX operators /want/ solved (they don't care about 3-p-n at all). If not, then *neither* add-path nor multiple-hop can help the peers involved btw.. > It seems that we now have an example where the path identifier in > draft-walton-bgp-add-paths-05.txt is needed. I would tend to disagree. > I don't recall seeing any objections to the use of path identifier > in draft-walton-bgp-add-paths that held up. There are none against multiple-hop, except vague ones about some unspecified, unknown cases (possibly future). E.g. where multiple-hop "restricts" paths advertisements in accordance with (destination,target), the add-path approach on the other hand can make it impossible to reconcile that two paths are identical[2]. In other words, add-path turns BGP into a flooding protocol between contiguous sets of add-path speakers[1]. The problem is, in chasing ultimate flexibility, add-path makes itself a quite inefficient flooding mechanism. BGP paths will be flooded along /every/ possible path between a contiguous set of add-path speakers: RR2 / | \ (P)A | B \ | / RR1 Based on Add-Path alone, B would receive: (A->RR2->B): P:a (A->RR1->B): P:b (A->RR2->RR1->B): P:c (A->RR1->RR2->B): P:d Now think about convergence if A withdraws P. B is going to just switch between the different 'ghosts', as they are all equal bar the path-ID, until /all/ are withdrawn[3]. And that's just with two hops of add-path. So the flexibility is not quite free. --paulj 1. It took a while to tease out that add-path does indeed amount to random local IDs, rather than distinguishable IDs derived in some way though.. 2. Other than by comparing path-attributes, but not having to care about path attributes (inc. nexthop) is part of the attraction of add-path. 3. Course, we could just say that the two RR's must never enable Add-Path between each other (as is the case for reflection today), but doesn't that seem restrictive? :) The Add-Path draft does not disallow 2-way add-path. Maybe Add-Path for inter-RR could be defined to compare router-ID of paths from clients against ORIGINATOR_ID of paths from RRs? But that defeats the point somewhat of using a new opaque ID as discriminator. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system." (By Linus Torvalds) _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 08:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlbO-0003Oi-AE; Thu, 31 Aug 2006 08:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlbN-0003Od-6K for idr@ietf.org; Thu, 31 Aug 2006 08:24:57 -0400 Received: from mailout18.yourhostingaccount.com ([65.254.253.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIlbM-0006nC-0B for idr@ietf.org; Thu, 31 Aug 2006 08:24:57 -0400 Received: from scan10.yourhostingaccount.com ([10.1.1.240] helo=scan10.yourhostingaccount.com) by mailout18.yourhostingaccount.com with esmtp (Exim) id 1GIlbL-0005Co-Kh for idr@ietf.org; Thu, 31 Aug 2006 08:24:55 -0400 Received: from authsmtp11.yourhostingaccount.com ([10.1.18.11] ident=exim) by scan10.yourhostingaccount.com with spamscanlookuphost (Exim) id 1GIlbL-0004Ea-HS for idr@ietf.org; Thu, 31 Aug 2006 08:24:55 -0400 Received: from authsmtp11.yourhostingaccount.com ([10.1.18.11] helo=authsmtp11.yourhostingaccount.com) by scan10.yourhostingaccount.com with esmtp (Exim) id 1GIlbL-0004EW-80 for idr@ietf.org; Thu, 31 Aug 2006 08:24:55 -0400 Received: from 108.114.2.81.in-addr.arpa ([81.2.114.108] helo=[192.168.0.43]) by authsmtp11.yourhostingaccount.com with esmtpa (Exim) id 1GIlbK-0000g4-St for idr@ietf.org; Thu, 31 Aug 2006 08:24:55 -0400 Message-ID: <44F6D50D.90501@abelon.com> Date: Thu, 31 Aug 2006 13:24:45 +0100 From: Neil Matthew User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-EN-UserInfo: e65bfd3d72dfaaaf5ffb0de99fd01ea2:0d98aba8e5f6749be2df7f931a889135 X-EN-AuthUser: neilrm X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Idr] Dynamic Capability for BGP-4 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Folks I note that the topic of dynamic capability support has gone kind of quiet. Can anyone update me with the current state of play? My primary concern is how it impacts the features (such as ORF and Graceful Restart) that lie behind these capabilities. Is there any work going on behind the scenes to detail this or is the intention that such matters be left to the developer? There was some discussion on this subject around 4 years ago! On a related note, are there any implementations in existence? Cheers Neil _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 10:22:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInOw-0001iV-2J; Thu, 31 Aug 2006 10:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInOu-0001iN-Je for idr@ietf.org; Thu, 31 Aug 2006 10:20:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInOt-0001ZD-Ct for idr@ietf.org; Thu, 31 Aug 2006 10:20:12 -0400 Received: by wr-out-0506.google.com with SMTP id i4so200798wra for ; Thu, 31 Aug 2006 07:20:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XGQgaKBSZHoqwp654Pxa3GygN0vPFJ4WhcRULNUD26bS9hxSQxGvx+NN7eNLme1g94MC4tnrc1oV6SN6H0tP2HbXmZzL7dFpjQDbla9cEEx90HQpgQATzxy60Ey/wi6eSGu+N4XOSMQRqKh6BOcwTwUt15JAFFzu7m0qeznp46E= Received: by 10.90.56.14 with SMTP id e14mr133831aga; Thu, 31 Aug 2006 07:20:10 -0700 (PDT) Received: by 10.90.95.20 with HTTP; Thu, 31 Aug 2006 07:20:10 -0700 (PDT) Message-ID: <92c950310608310720n1939b3a8p6701d4435e5c3366@mail.gmail.com> Date: Thu, 31 Aug 2006 19:50:10 +0530 From: "Glen Kent" To: curtis@occnc.com, "Inter-Domain Routing Mailing List" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org A quick Q while we're discussing various mechanisms to advertise multiple paths. What is a router supposed to do if it recieves two paths from a BGP speaker as described below? Path 1 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 100 NEXT_HOP 1.1.1.1 Path 2 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 189 NEXT_HOP 1.1.1.1 What useful information can any router possibly derive from this? Which route should it select? I see now value and would appreciate if someone can enlighten me on this. Another day, another time, but the same BGP speakers. This router recieves two paths for 192/8 from the same BGP speaker. Path 1 - NLRI 192/8 AS_PATH {10 20} NEXT_HOP 1.1.1.1 Path 2 - NLRI 192/8 AS_PATH {30 20} NEXT_HOP 1.1.1.1 How does this router determine which route is being used by the upstream? I dont think we should progress any proposal without incorporating ways to indicate which path is being actually used in the forwarding. I know one of the authors of multiple_hop indicated that this could be easily done by introducing a field in the path attribute. Its not difficult but they need to show this to us. The same goes for add-paths. Curtis said: > I don't recall seeing any objections to the use of path identifier in > draft-walton-bgp-add-paths that held up. I think its well known that silence means lack of interest, not acceptance. You of all the persons, should be well aware of this. Glen _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 10:37:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIneP-0003Ls-GV; Thu, 31 Aug 2006 10:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIneO-0003Ln-RW for idr@ietf.org; Thu, 31 Aug 2006 10:36:12 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIneN-0003Rt-IY for idr@ietf.org; Thu, 31 Aug 2006 10:36:12 -0400 Received: from [71.254.20.130] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GIneJ-0000Oy-4p; Thu, 31 Aug 2006 10:36:07 -0400 Message-Id: <7.0.1.0.0.20060831102630.03588d98@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 31 Aug 2006 10:35:56 -0400 To: "Glen Kent" , "Inter-Domain Routing Mailing List" From: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <92c950310608310720n1939b3a8p6701d4435e5c3366@mail.gmail.co m> References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> <92c950310608310720n1939b3a8p6701d4435e5c3366@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112081f0db369520e7576741684f4bbd8cc0900f0771c95f4286350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.20.130 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Both of the examples you provided highlight the fact that if one allows BGP to send multiple advertisements for the same NLRI and same next-hop then the receiver must treat them as an atomic collection (i.e. the receivers considers that all the advertised paths are being used.) This means that the case where the paths differ only on local-pref is, as you suggest, useless. With regard to the case where the paths differ on AS PAth, as copied below from your note, this requires that the receiver consider all the AS Paths. For example, if the receiver appears in any of the AS Paths, then none of the advertisements can be used. And when passing the advertisements on further, either all the advertisements must be sent, or the collection of advertisements must be compressed in a way that preserves the presence of all distinct AS values and has the correct AS Path length. How to perform such aggregation of AS Paths if the paths might be of different lengths is not something I currently know how to do. (Merging AS Paths in ways that change properties relevant to the mandatory BGP decision algorithm introduces a whole new set of oscillation risks, which is why the merging has to preserve the properties mandated by the decision algorithm.) When one uses the next-hop has the differentiator, the first case never comes up. And the receiver can select from among the multiple paths, since they each have a different next-hop. This is what led to the text in the ECMP draft that restricts the set of paths a receiver may choose. And the definition of how to merge those eligable advertisements if the receiver chooses to use them. There is an argument that we may, for theoretical reasons still subject to analysis or hypothesis, want to advertise secondary paths that are not used. That would require a flag to indicate which paths are used vs unused. Yours, Joel M. Halpern At 10:20 AM 8/31/2006, Glen Kent wrote: >This router recieves two paths for 192/8 from the same BGP speaker. > >Path 1 - NLRI 192/8 AS_PATH {10 20} NEXT_HOP 1.1.1.1 > >Path 2 - NLRI 192/8 AS_PATH {30 20} NEXT_HOP 1.1.1.1 > >How does this router determine which route is being used by the >upstream? I dont think we should progress any proposal without >incorporating ways to indicate which path is being actually used in >the forwarding. > >I know one of the authors of multiple_hop indicated that this could be >easily done by introducing a field in the path attribute. Its not >difficult but they need to show this to us. The same goes for >add-paths. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 12:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIp5L-0003nt-HK; Thu, 31 Aug 2006 12:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIp5K-0003n5-6n for idr@ietf.org; Thu, 31 Aug 2006 12:08:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIp5I-000669-S5 for idr@ietf.org; Thu, 31 Aug 2006 12:08:06 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2006 09:08:04 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VG84uE021755; Thu, 31 Aug 2006 09:08:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7VG841E004315; Thu, 31 Aug 2006 09:08:04 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 09:08:03 -0700 Received: from [10.21.81.138] ([10.21.81.138]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 09:08:03 -0700 Message-ID: <44F7095F.2090901@cisco.com> Date: Thu, 31 Aug 2006 09:07:59 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Neil Matthew Subject: Re: [Idr] Dynamic Capability for BGP-4 References: <44F6D50D.90501@abelon.com> In-Reply-To: <44F6D50D.90501@abelon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 16:08:03.0838 (UTC) FILETIME=[A38B11E0:01C6CD17] DKIM-Signature: a=rsa-sha1; q=dns; l=1080; t=1157040484; x=1157904484; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Dynamic=20Capability=20for=20BGP-4; X=v=3Dcisco.com=3B=20h=3DPCsf7Sm5mVTF9J2qP6Df3VGwbdo=3D; b=eWmOgy1RJRHxLHE+tgtQTl0fiDgbvLp+V/C6W8gPQBgVaR8wpVZgYVLU4t0EDu4apJKPN1VU p6AX5tGGpGzHp8tiLpKWI/vbtyYoQmUp/XqT8UbfNLV1fn2Zt9U4yrUK; Authentication-Results: sj-dkim-1.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Neil: Just noticed that the draft has expired, will refresh. In the meantime, you can find the draft here: http://ietfreport.isoc.org/all-ids/draft-ietf-idr-dynamic-cap-08.txt Regarding its status, the spec has been stable since the sync mechanism was introduced several years ago. -- Enke Neil Matthew wrote: > Hi Folks > > I note that the topic of dynamic capability support has gone kind of > quiet. Can anyone update me with the current state of play? > > My primary concern is how it impacts the features (such as ORF and > Graceful Restart) that lie behind these capabilities. Is there any > work going on behind the scenes to detail this or is the intention > that such matters be left to the developer? > > There was some discussion on this subject around 4 years ago! > > On a related note, are there any implementations in existence? > > Cheers > > Neil > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 12:15:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpC7-0002J4-C2; Thu, 31 Aug 2006 12:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpC5-0002Iz-Mc for idr@ietf.org; Thu, 31 Aug 2006 12:15:05 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpC4-0006Jy-En for idr@ietf.org; Thu, 31 Aug 2006 12:15:05 -0400 Received: by wr-out-0506.google.com with SMTP id i4so238950wra for ; Thu, 31 Aug 2006 09:15:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XV/QifLxGESGt/FXMvsYF9tgZPr8vnBzb8g3NTuWqTZ1w3gvPlVdN9/gImMghuGqJDHSEKzeKsy2h9xgvgb3HeWiJ9CxOnF9tgvByCxRvEo0UHGWL621vMH73a9/5nIEOpmcmX2ZJxtlZrg8XpO6aPK1/XnqmVvqDpHo1IkDW84= Received: by 10.90.120.6 with SMTP id s6mr241011agc; Thu, 31 Aug 2006 09:15:02 -0700 (PDT) Received: by 10.90.95.20 with HTTP; Thu, 31 Aug 2006 09:14:59 -0700 (PDT) Message-ID: <92c950310608310914t2fd4d7dci996457492e1fd4b6@mail.gmail.com> Date: Thu, 31 Aug 2006 21:44:59 +0530 From: "Glen Kent" To: "Joel M. Halpern" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-Reply-To: <7.0.1.0.0.20060831102630.03588d98@stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> <92c950310608310720n1939b3a8p6701d4435e5c3366@mail.gmail.com> <7.0.1.0.0.20060831102630.03588d98@stevecrocker.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Inter-Domain Routing Mailing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Joel, I'm having trouble in understanding the notion of "all" paths here. I think its important that we converge on this so that everyones on the same page. Does "all paths" cover paths that describe different forwarding paths (i.e. traces a path that a packet will actually take) or does it include every conceivable path that exists in ones BGP routing tables (including the kind that i had described in my earlier mail)? I cant think of a sound reason why anyone would possibly want to "flood", every path that one has, to all its neighbors. More so, when the reciever cannot make any intelligent decision based on such routes. If nothing else, wouldnt doing this lead to serious scalability issues (full internet tables, multiple speakers, etc) ? Glen. Joel M. Halpern said: > Both of the examples you provided highlight the fact that if one > allows BGP to send multiple advertisements for the same NLRI and same > next-hop then the receiver must treat them as an atomic collection > (i.e. the receivers considers that all the advertised paths are being used.) > > This means that the case where the paths differ only on local-pref > is, as you suggest, useless. > > With regard to the case where the paths differ on AS PAth, as copied > below from your note, this requires that the receiver consider all > the AS Paths. For example, if the receiver appears in any of the AS > Paths, then none of the advertisements can be used. And when passing > the advertisements on further, either all the advertisements must be > sent, or the collection of advertisements must be compressed in a way > that preserves the presence of all distinct AS values and has the > correct AS Path length. How to perform such aggregation of AS Paths > if the paths might be of different lengths is not something I > currently know how to do. (Merging AS Paths in ways that change > properties relevant to the mandatory BGP decision algorithm > introduces a whole new set of oscillation risks, which is why the > merging has to preserve the properties mandated by the decision algorithm.) > > When one uses the next-hop has the differentiator, the first case > never comes up. And the receiver can select from among the multiple > paths, since they each have a different next-hop. This is what led > to the text in the ECMP draft that restricts the set of paths a > receiver may choose. And the definition of how to merge those > eligable advertisements if the receiver chooses to use them. > > There is an argument that we may, for theoretical reasons still > subject to analysis or hypothesis, want to advertise secondary paths > that are not used. That would require a flag to indicate which paths > are used vs unused. > > Yours, > Joel M. Halpern > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 12:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpdK-0001LV-Io; Thu, 31 Aug 2006 12:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpdJ-0001Kf-JC for idr@ietf.org; Thu, 31 Aug 2006 12:43:13 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpdI-0008ED-C3 for idr@ietf.org; Thu, 31 Aug 2006 12:43:13 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id CEE184F2F7; Thu, 31 Aug 2006 12:42:55 -0400 (EDT) Date: Thu, 31 Aug 2006 12:42:55 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20060831164255.GD10053@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Idr] Suggested breakdown of problem space for multiple bgp paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org A lot of the churn on the list on this topic seems to be over the different problem spaces each solution is trying to address. I'd like to see them presented clearly so we're sure we're all talking about the same things: 1. Ability to send multiple routes for purposes of route oscillation suppression. 2. Ability to send multiple routes as a "route-server". 3. Ability to send multiple routes for ecmp purposes. While the solution space for these three issues has large amounts of overlap, I think the predisposition of a solution towards a subset of these problem spaces has been tainting arguments in this thread. The solution spaces thus far are: 1. Inject multiple routes keyed on nexthop(s) and NLRI 2. Inject multiple routes keyed abstractly on a route identifier of bgp session significance. I've presented the argument that the lack of a "used for forwarding" bit is problematic. I've constructed an example case that I believe illustrates this, and I'll send that as a separate e-mail. Curtis has made an argument where distinguishing on nexthop(s) as a key alone is incompatible with the route server argument. I agree. The authors of the ecmp draft have made an argument regarding the fate-sharing of ecmp routes. I believe the IDR members agree with the basics of this argument: If you're going to use multiple routes for forwarding, these routes have a fate-sharing relationship. You can't process these routes separately. You also can't advertise them externally of whatever solution we come up with for multiple routes without some form aggregation. Some forms of this aggregation are, IMO, problematic. As we discuss any possible solution, I suggest we keep these things in mind. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 12:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpmC-0004oA-8I; Thu, 31 Aug 2006 12:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpmB-0004o1-GC for idr@ietf.org; Thu, 31 Aug 2006 12:52:23 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpmA-0000xG-7K for idr@ietf.org; Thu, 31 Aug 2006 12:52:23 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id E3C3D4F2F7; Thu, 31 Aug 2006 12:52:19 -0400 (EDT) Date: Thu, 31 Aug 2006 12:52:19 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20060831165219.GE10053@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Idr] Example of multiple-path route selection issue X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Neither proposed solution for the injectin of multiple bgp routes makes use of a "used for forwarding" bit. Looking at the case of BGP route oscillation, proposed solutions involve injecting "enough" additional BGP routes into the entire routing mesh to suppress the oscillation. The scope of "enough" is outside this example. Consider the case where multiple instances of a route are injected into a routing mesh without any delineation of its use in forwarding state. This example is meant to illustrate a case where, when this happens, that we may converge in a forwarding loop. This example does not cover the oscillation case. It is meant to illustrate that one solution to the oscillation case may be an issue. Please excuse the complexity of this example. It's what I have doodled on my whiteboard and some of this may be extraneous. A-----B-----C------D \ / \ / E Outgoing link metrics for IGP: A->B 1 B->C 10 C->D 1 B->E 1 E->C 1 D->C 1 C->B 1 B->A 4 C->E 10 E->B 10 Presume ebgp confederation connections for all routers in the above set. B and C prepend one extra AS to each other to keep the loop equally preferable for AS_PATH length purposes. C is configured to prefer routes from A. (Insert your mechanism of choice here) A and D both receive a destination, R. We'll call this R(A) and R(D) to distinguish ingress. R is coming from outside the confederation. R is otherwise equally preferable regardless of who it comes from. If we're running stock BGP, we expect to see the following: Allow R(A) to percolate through first: A: R(A) local B: R(A) via B->A C: R(A) via C->B D: R(A) via D->C E: R(A) via E->C Allow R(D) to be injected *without* policy on C: A: R(A) local B: R(D) via B->E C: R(D) via C->D E: R(D) via E->C Now, consider what happens if we use policy on C: Start with our original case of R(A) to percolate. If C has policy, we have a form of wedgie: A: R(A) local B: R(A) via B->A C: R(A) via C->B (preferred by policy) D: R(D) local E: R(A) via E->C Were we to let R(A) and R(D) to flow simultaneously, depending on the order things happen, we'll converge differently. Specifically, if B selects R(D), R(A) will never percolate through the rest of the network. Either answer is *fine* because we converge. Consider what happens if we're able to circulate both R(A) and R(D) within the network without regards to which route is used for forwarding: A: R(A) local B: R(D) via B->E (lowest IGP metric) C: R(A) via C->B (prefer A) D: R(D) local E: R(D) via E->C (lowest IGP metric) We now have a forwarding loop: B->E->C->B. This loop isn't contingent on order the routes come in, only that R(A) and R(D) are available everywhere without regard to forwarding state. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 14:19:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIr7c-0008JE-T3; Thu, 31 Aug 2006 14:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIr7b-0008J7-PV for idr@ietf.org; Thu, 31 Aug 2006 14:18:35 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIr7a-0002eZ-57 for idr@ietf.org; Thu, 31 Aug 2006 14:18:35 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k7VIP6sn020601; Thu, 31 Aug 2006 14:25:06 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200608311825.k7VIP6sn020601@workhorse.brookfield.occnc.com> To: Paul Jakma In-reply-to: Your message of "Thu, 31 Aug 2006 10:22:46 BST." Date: Thu, 31 Aug 2006 14:25:06 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org Subject: [Idr] draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Paul Jakma writes: > > Hi Curtis, > > On Wed, 30 Aug 2006, Curtis Villamizar wrote: > > > You can't propose a protocol extension where routes cannot be > > distinguished when a legitimate example is given just because the > > example is in your opinion "something no one would want to do". > > It's not a consideration because the exit-peer can easily peer with > the RS in Enke's example. This is true that the two peers *can* peer with the route server only. It is common practice that major providers rely on private peerings rather than get their routes for other major providers from a RS. This is not a hypothetical, it is common practice. You cannot dismiss existing common practice. > 3-p-n generally is discouraged, it has reliability problems - it's > the poor man's substitute for direct peering (usually administrative > overhead of setting it up). Certainly at IXes we know of it is > generally discouraged. > > Its use tends to be primarily because of the /lack/ of eBGP RS > solutions. Or distrust of anything that could become a single point of failure. Some providers have more than one router at some major IX and direct peer in pairs with other major providers. > We'd be interested in any plausible cases where a peer would /not/ > want to advertise the path to the RS, but would be happy for other > peers to advertise the path to the RS (and hence all RS-client > peers). We can't quite think of them. The case is where the route is not a direct customer of the provider and is not getting transit to the IX through that provider but is peering with another major provider with agreement to exchange all routes. The other providers readvertising the path would be a misconfiguration unless the route was learned at a distant exchange and the transit provided readvertising the routes. Avoiding circumventing the policy of another provider was the main purpose of "next hop self". That exact situation existed at one point when NSFNET readvertised Sprint routes and the remedy was the NSFNET routers implementing and configuring "next hop self" (which Cisco already had at the time). > > It is true that most peerings use "next hop self" at an exchange > > where a route server is located, however if two peers did not set > > next hop self and provided third party routes with the same next > > hop to the RS, there would be no way to make these routes > > unambiguous. > > There's no ambiguity, the RS just doesn't accept paths from peers > which won't forward the path. That's not a problem a route-server is > there to solve. This is solvable if the RS does not accept routes for with the BGP identifier does not match the next-hop. > However, if the exit peer wants to peer with the RS, and hence > *remove* the need for others to advertise path with it as nexthop, > then that is exactly what the RS is there for, that's exactly the > problem the IX operators /want/ solved (they don't care about 3-p-n > at all). > > If not, then *neither* add-path nor multiple-hop can help the peers > involved btw.. add-path does solve this. The must be unique, not the next-hop. > > It seems that we now have an example where the path identifier in > > draft-walton-bgp-add-paths-05.txt is needed. > > I would tend to disagree. Clearly you do. > > I don't recall seeing any objections to the use of path identifier > > in draft-walton-bgp-add-paths that held up. > > There are none against multiple-hop, except vague ones about some > unspecified, unknown cases (possibly future). You've just dismissed a real case above. A minor misconfiguration (not setting next-hop self) could result in routes being ambiguous. > E.g. where multiple-hop "restricts" paths advertisements in > accordance with (destination,target), the add-path approach on the > other hand can make it impossible to reconcile that two paths are > identical[2]. In other words, add-path turns BGP into a flooding > protocol between contiguous sets of add-path speakers[1]. Nice try but you have a clearly flawed argument. You can still compare attributes in the above RS example to reduce the multipath set to a minimal set when readvertising. You can disambiguate the advertisements with the same next hop from different peers with different AS path such that you know to keep two copies and delete only one of them when one router withdraws the route. > The problem is, in chasing ultimate flexibility, add-path makes > itself a quite inefficient flooding mechanism. BGP paths will be > flooded along /every/ possible path between a contiguous set of > add-path speakers: > > RR2 > / | \ > (P)A | B > \ | / > RR1 > > Based on Add-Path alone, B would receive: > > (A->RR2->B): P:a > (A->RR1->B): P:b > (A->RR2->RR1->B): P:c > (A->RR1->RR2->B): P:d > > Now think about convergence if A withdraws P. B is going to just > switch between the different 'ghosts', as they are all equal bar the > path-ID, until /all/ are withdrawn[3]. > > And that's just with two hops of add-path. > > So the flexibility is not quite free. > > --paulj > > 1. It took a while to tease out that add-path does indeed amount to > random local IDs, rather than distinguishable IDs derived in some > way though.. > > 2. Other than by comparing path-attributes, but not having to care > about path attributes (inc. nexthop) is part of the attraction of > add-path. > > 3. Course, we could just say that the two RR's must never enable > Add-Path between each other (as is the case for reflection today), > but doesn't that seem restrictive? :) The Add-Path draft does not > disallow 2-way add-path. > > Maybe Add-Path for inter-RR could be defined to compare > router-ID of paths from clients against ORIGINATOR_ID of paths > from RRs? But that defeats the point somewhat of using a new > opaque ID as discriminator. > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > "If you want to travel around the world and be invited to speak at a lot > of different places, just write a Unix operating system." > (By Linus Torvalds) You argument that multiple-next-hops is not flawed boils down to arguing that you can never have the same next hop with other attributes differing. Enke's exmaple is is an EBGP peering example. Next-hop-self is not required by BGP. A similar situation exists with confederations. A route may be passed through different private AS but with BGP confederations the next hop is generally not changed, relying on the next hop advertised by the router that borders the external AS and relying on the IGP rather than the set of EIBGP advertisers. In this case the AS Paths would be different *until* the confederation AS were dropped before advertising the route externally. Consider this case. ASe1 - R1/NH1 ----- R3/AS65001 \ / \ X R5/AS65003 - R6/AS65004 / \ / ASe2 - R2/NH2 ---- R4/AS65002 R5 gets the following routes: R3: AS65001 ASexternal1 NH1 AS65001 ASexternal2 NH2 R4: AS65002 ASexternal1 NH1 AS65001 ASexternal2 NH2 It doesn't seem that based on NH there is a good way to disambiguate the components of this multipath. A good question is exactly what R5 should advertise to R6 such that the AS path is correct. It seems that the tuple adds an ability to disambiguate this case. My understanding of add-path is that the advertisement would be: R5 -> R6: prefix X path-id 1 AS65003 AS65001 ASexternal1 NH1 prefix X path-id 2 AS65003 AS65001 ASexternal2 NH2 prefix X path-id 3 AS65003 AS65002 ASexternal1 NH1 prefix X path-id 4 AS65003 AS65001 ASexternal2 NH2 Maybe the multiple-next-hops and add-path advocates can kick this example around for a while. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 14:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIrOW-0003Dw-4q; Thu, 31 Aug 2006 14:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIrOV-0003CB-3j for idr@ietf.org; Thu, 31 Aug 2006 14:36:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIrOR-0006ca-JW for idr@ietf.org; Thu, 31 Aug 2006 14:36:03 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 31 Aug 2006 11:35:59 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VIZwl9030263; Thu, 31 Aug 2006 11:35:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7VIZw1E028950; Thu, 31 Aug 2006 11:35:58 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Aug 2006 11:35:58 -0700 Received: from [128.107.134.9] ([128.107.134.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 11:35:58 -0700 Message-ID: <44F72C0D.2020506@cisco.com> Date: Thu, 31 Aug 2006 11:35:57 -0700 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 18:35:58.0023 (UTC) FILETIME=[4CF83D70:01C6CD2C] DKIM-Signature: a=rsa-sha1; q=dns; l=4733; t=1157049358; x=1157913358; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:Enke=20Chen=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DT8SdnzoHdzNLTTtPmIm9CArt9KU=3D; b=f+YE7/iLWh0/BSpRzrBnlckU5xmh1F1Kd778idBP8i0wRJGlWLgp02mWLl8YeaBfKjK7xCBY wO5timwleJOCpasNCEbD9W3LnhzOIczGFFRnL/lONoLIh17I1exy1wYi; Authentication-Results: sj-dkim-1.cisco.com; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Paul: It is clear from the current discussion thread that we lost some of the semantics on the path-id when we merged the relevant documents and went through revisions. The intention was to use the router-id or the neighboring -AS as the natural path identifiers inside an AS, but that was not clear enough in the current version. In draft-walton-bgp-add-paths-03.txt, there was a "Path Identifier Type" defined. With the Path Identifier Type, a BGP speaker will be able to tell if a path identifier is a natural id (such as router-id), and will not re-generate one for ibgp. We will clarify this point in the next revision. -- Enke Paul Jakma wrote: > Hi Curtis, > > On Wed, 30 Aug 2006, Curtis Villamizar wrote: > >> You can't propose a protocol extension where routes cannot be >> distinguished when a legitimate example is given just because the >> example is in your opinion "something no one would want to do". > > > It's not a consideration because the exit-peer can easily peer with > the RS in Enke's example. > > 3-p-n generally is discouraged, it has reliability problems - it's the > poor man's substitute for direct peering (usually administrative > overhead of setting it up). Certainly at IXes we know of it is > generally discouraged. > > Its use tends to be primarily because of the /lack/ of eBGP RS solutions. > > We'd be interested in any plausible cases where a peer would /not/ > want to advertise the path to the RS, but would be happy for other > peers to advertise the path to the RS (and hence all RS-client peers). > We can't quite think of them. > >> It is true that most peerings use "next hop self" at an exchange >> where a route server is located, however if two peers did not set >> next hop self and provided third party routes with the same next hop >> to the RS, there would be no way to make these routes unambiguous. > > > There's no ambiguity, the RS just doesn't accept paths from peers > which won't forward the path. That's not a problem a route-server is > there to solve. > > However, if the exit peer wants to peer with the RS, and hence > *remove* the need for others to advertise path with it as nexthop, > then that is exactly what the RS is there for, that's exactly the > problem the IX operators /want/ solved (they don't care about 3-p-n at > all). > > If not, then *neither* add-path nor multiple-hop can help the peers > involved btw.. > >> It seems that we now have an example where the path identifier in >> draft-walton-bgp-add-paths-05.txt is needed. > > > I would tend to disagree. > >> I don't recall seeing any objections to the use of path identifier in >> draft-walton-bgp-add-paths that held up. > > > There are none against multiple-hop, except vague ones about some > unspecified, unknown cases (possibly future). > > E.g. where multiple-hop "restricts" paths advertisements in accordance > with (destination,target), the add-path approach on the other hand can > make it impossible to reconcile that two paths are identical[2]. In > other words, add-path turns BGP into a flooding protocol between > contiguous sets of add-path speakers[1]. > > The problem is, in chasing ultimate flexibility, add-path makes itself > a quite inefficient flooding mechanism. BGP paths will be flooded > along /every/ possible path between a contiguous set of add-path > speakers: > > RR2 > / | \ > (P)A | B > \ | / > RR1 > > Based on Add-Path alone, B would receive: > > (A->RR2->B): P:a > (A->RR1->B): P:b > (A->RR2->RR1->B): P:c > (A->RR1->RR2->B): P:d > > Now think about convergence if A withdraws P. B is going to just > switch between the different 'ghosts', as they are all equal bar the > path-ID, until /all/ are withdrawn[3]. > > And that's just with two hops of add-path. > > So the flexibility is not quite free. > > --paulj > > 1. It took a while to tease out that add-path does indeed amount to > random local IDs, rather than distinguishable IDs derived in some > way though.. > > 2. Other than by comparing path-attributes, but not having to care > about path attributes (inc. nexthop) is part of the attraction of > add-path. > > 3. Course, we could just say that the two RR's must never enable > Add-Path between each other (as is the case for reflection today), > but doesn't that seem restrictive? :) The Add-Path draft does not > disallow 2-way add-path. > > Maybe Add-Path for inter-RR could be defined to compare > router-ID of paths from clients against ORIGINATOR_ID of paths > from RRs? But that defeats the point somewhat of using a new > opaque ID as discriminator. > > regards, _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 17:44:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIuIx-0001IG-JM; Thu, 31 Aug 2006 17:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIuIw-0001Av-9x for idr@ietf.org; Thu, 31 Aug 2006 17:42:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIriT-00016s-5K for idr@ietf.org; Thu, 31 Aug 2006 14:56:41 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIrWR-00070R-RO for idr@ietf.org; Thu, 31 Aug 2006 14:44:17 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k7VIoote020714; Thu, 31 Aug 2006 14:50:50 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200608311850.k7VIoote020714@workhorse.brookfield.occnc.com> To: "Glen Kent" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt In-reply-to: Your message of "Thu, 31 Aug 2006 19:50:10 +0530." <92c950310608310720n1939b3a8p6701d4435e5c3366@mail.gmail.com> Date: Thu, 31 Aug 2006 14:50:50 -0400 From: Curtis Villamizar X-Spam-Score: -1.0 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Inter-Domain Routing Mailing List X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <92c950310608310720n1939b3a8p6701d4435e5c3366@mail.gmail.com> "Glen Kent" writes: > > A quick Q while we're discussing various mechanisms to advertise > multiple paths. > > What is a router supposed to do if it recieves two paths from a BGP > speaker as described below? > > Path 1 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 100 NEXT_HOP 1.1.1.1 > > Path 2 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 189 NEXT_HOP 1.1.1.1 If this came from the same router then complain because the sender of this is broken. On the priciple of "being liberal in what you accept" just toss the second path. > What useful information can any router possibly derive from this? > Which route should it select? I see now value and would appreciate if > someone can enlighten me on this. > > Another day, another time, but the same BGP speakers. > > This router recieves two paths for 192/8 from the same BGP speaker. > > Path 1 - NLRI 192/8 AS_PATH {10 20} NEXT_HOP 1.1.1.1 > > Path 2 - NLRI 192/8 AS_PATH {30 20} NEXT_HOP 1.1.1.1 > > How does this router determine which route is being used by the > upstream? I dont think we should progress any proposal without > incorporating ways to indicate which path is being actually used in > the forwarding. If its a multipath it is considering both to be valid. This may be possible at an IX if next-hop-self is not set and there is an odd set of routing policies. btw- no where in BGP does it require that routing policies be sane (and they can be seemingly quite wierd). If the AS are 65010, 65020, and 65030, this is perfectly valid in an AS confederation setup. In AS confederations you'd just forward to 1.1.1.1 but retain the AS paths for readvertising. > I know one of the authors of multiple_hop indicated that this could be > easily done by introducing a field in the path attribute. Its not > difficult but they need to show this to us. The same goes for > add-paths. With add-paths the path-id would be used to disambiguate path 1 and path 2 in the second case so I'm not sure what your point is. > Curtis said: > > > I don't recall seeing any objections to the use of path identifier in > > draft-walton-bgp-add-paths that held up. > > I think its well known that silence means lack of interest, not > acceptance. You of all the persons, should be well aware of this. > > Glen There seems to be equal or more people arguing in favor of add-paths. Enke Chen, John Scuder, Robert Raszuk, Jeffrey Haas seem interested. I'm interested. I'm less sure about others. The contributors to this thread are (alphabetic by first name): Curtis Villamizar Enke Chen Glen Kent Jeffrey Haas Joel M. Halpern John G. Scudder Mach Chen Manav Bhatia Paul Jakma Robert Raszuk Tulip Rasputin Yakov Rekhter To me it seems comments show interest in multiple-next-hops and add-path even though the majority of the mail carried multiple-next-hops in the subject line. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 20:00:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIwQx-0003Qx-Lu; Thu, 31 Aug 2006 19:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIwQw-0003Q2-IL for idr@ietf.org; Thu, 31 Aug 2006 19:58:54 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIwQv-0003dH-6k for idr@ietf.org; Thu, 31 Aug 2006 19:58:54 -0400 Received: by wx-out-0506.google.com with SMTP id t4so837721wxc for ; Thu, 31 Aug 2006 16:58:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ubHn2/f5Hd2uHk+vmE1kQ36DyIfkrtKUmOfw3f6DkDnOsOCroo8N77C3bPOk/POmtBp5V6CER1mnLs2mwu26hKvhJszLwhpKitu1np/HT9VLR1swIXP9lyLdyq6SdzQSDvIqGXJDBJCFKBODtqmvDjxpz0+kVYYCFWx1avXGfak= Received: by 10.90.94.2 with SMTP id r2mr348522agb; Thu, 31 Aug 2006 16:58:52 -0700 (PDT) Received: by 10.90.95.20 with HTTP; Thu, 31 Aug 2006 16:58:52 -0700 (PDT) Message-ID: <92c950310608311658x55877185q53061ec6f95f688a@mail.gmail.com> Date: Fri, 1 Sep 2006 05:28:52 +0530 From: "Glen Kent" To: curtis@occnc.com Subject: Re: [Idr] draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths In-Reply-To: <200608311825.k7VIP6sn020601@workhorse.brookfield.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200608311825.k7VIP6sn020601@workhorse.brookfield.occnc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Curtis, > You've just dismissed a real case above. A minor misconfiguration > (not setting next-hop self) could result in routes being ambiguous. Similarly, a minor misconfiguration (of setting as-override) can result in possible occurances of routing loops. So whats the point? Is BGP flawed to not inherently work with misconfigurations around? I think its a well known that there are infinite ways to axe your foot with BGP; not setting next-hop-self in IXes would be just one of them. > > > E.g. where multiple-hop "restricts" paths advertisements in > > accordance with (destination,target), the add-path approach on the > > other hand can make it impossible to reconcile that two paths are > > identical[2]. In other words, add-path turns BGP into a flooding > > protocol between contiguous sets of add-path speakers[1]. > > Nice try but you have a clearly flawed argument. > > You can still compare attributes in the above RS example to reduce the > multipath set to a minimal set when readvertising. You can The idea behind add-paths is to NOT to look at the path attributes. Moreover, i did not see your views on the scenario given below where add-paths would result in a lot many Updates? Glen. > disambiguate the advertisements with the same next hop from different > peers with different AS path such that you know to keep two copies and > delete only one of them when one router withdraws the route. > > > The problem is, in chasing ultimate flexibility, add-path makes > > itself a quite inefficient flooding mechanism. BGP paths will be > > flooded along /every/ possible path between a contiguous set of > > add-path speakers: > > > > RR2 > > / | \ > > (P)A | B > > \ | / > > RR1 > > > > Based on Add-Path alone, B would receive: > > > > (A->RR2->B): P:a > > (A->RR1->B): P:b > > (A->RR2->RR1->B): P:c > > (A->RR1->RR2->B): P:d > > > > Now think about convergence if A withdraws P. B is going to just > > switch between the different 'ghosts', as they are all equal bar the > > path-ID, until /all/ are withdrawn[3]. > > > > And that's just with two hops of add-path. > > > > So the flexibility is not quite free. > > > > --paulj > > > > 1. It took a while to tease out that add-path does indeed amount to > > random local IDs, rather than distinguishable IDs derived in some > > way though.. > > > > 2. Other than by comparing path-attributes, but not having to care > > about path attributes (inc. nexthop) is part of the attraction of > > add-path. > > > > 3. Course, we could just say that the two RR's must never enable > > Add-Path between each other (as is the case for reflection today), > > but doesn't that seem restrictive? :) The Add-Path draft does not > > disallow 2-way add-path. > > > > Maybe Add-Path for inter-RR could be defined to compare > > router-ID of paths from clients against ORIGINATOR_ID of paths > > from RRs? But that defeats the point somewhat of using a new > > opaque ID as discriminator. > > > > regards, _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 20:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIwgx-0000FW-6i; Thu, 31 Aug 2006 20:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIwgC-0007t8-1l for idr@ietf.org; Thu, 31 Aug 2006 20:14:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIwa4-0004aL-T1 for idr@ietf.org; Thu, 31 Aug 2006 20:08:22 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 Aug 2006 17:08:20 -0700 X-IronPort-AV: i="4.08,195,1154934000"; d="scan'208"; a="316654486:sNHT35587478" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8108KAn020550; Thu, 31 Aug 2006 17:08:20 -0700 Received: from [10.0.1.5] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8108E6X004420; Thu, 31 Aug 2006 17:08:18 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> Date: Thu, 31 Aug 2006 18:36:37 -0400 To: Paul Jakma From: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" DKIM-Signature: a=rsa-sha1; q=dns; l=2851; t=1157069300; x=1157933300; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jgs@cisco.com; z=From:=22John=20G.=20Scudder=22=20 |Subject:Re=3A=20[Idr]=20Progressing=20draft-bhatia-bgp-multiple-next-hops-01.txt; X=v=3Dcisco.com=3B=20h=3DjjqtlVkL9whR6GHPOZyXd6rwgcM=3D; b=Mbf9OWqd/S4VMcXoBE2EYutxaeJlraYABMbjeDmmcUmMq/NVTMWm1z5ru9bPWBslwJsjyZNA YRy5ter55u+PsiIs9lY5wJ8ZmuYJx6dI8x1QuL44qMNSc01mW0oMpxPW; Authentication-Results: sj-dkim-5.cisco.com; header.From=jgs@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: raszuk@cisco.com, Manav Bhatia , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 10:22 AM +0100 8/31/06, Paul Jakma wrote: >Hi Curtis, > >On Wed, 30 Aug 2006, Curtis Villamizar wrote: > >>You can't propose a protocol extension where routes cannot be >>distinguished when a legitimate example is given just because the >>example is in your opinion "something no one would want to do". > >It's not a consideration because the exit-peer can easily peer with >the RS in Enke's example. That is incorrect. As Enke pointed out (twice now) the AS path will be different depending on which peer advertises the route. As Enke also pointed out, the two different AS paths may result in different filtering, localpref, etc, by the recipient. If you want to deprecate third-party next hop, please raise it as a separate topic, but I don't think you can just pretend it's semantically identical to direct advertisement. (By the way, if we're going to start deprecating our least favorite features of BGP, there are a few I'd like to add to the list. :-) >3-p-n generally is discouraged, it has reliability problems - it's >the poor man's substitute for direct peering (usually administrative >overhead of setting it up). Certainly at IXes we know of it is >generally discouraged. N.b. neither Enke, Curtis nor I are entirely lacking in experience with IXes, network operations, etc. >Its use tends to be primarily because of the /lack/ of eBGP RS solutions. > >We'd be interested in any plausible cases where a peer would /not/ >want to advertise the path to the RS, but would be happy for other >peers to advertise the path to the RS (and hence all RS-client >peers). We can't quite think of them. Again, it's not an either-or. As detailed above (and in several previous messages) since the semantics of the advertisements from the direct and third-party advertisers differ (in particular, different AS paths may reflect different business relationships) it's quite reasonable for both versions of the route to be of genuine use to various consumers of the routes. If there were no way to support third-party next hop and still get multiple path support, then I'd be more sympathetic to the argument that it's a corner feature which regrettably has to be abandoned to enable progress. But the fact is, it's entirely possible to continue to support it. Also, the fact that one non-obvious casualty of using next hop as identifier has been identified leads me to be concerned that others, as yet unidentified, may also exist. BGP is a surprisingly subtle protocol, and just because I can't quite think of another bad interaction doesn't mean there isn't one. On the other hand, if one picks (or at least, retains the option to pick) an identifier which has no other semantics then the risk of such interactions is eliminated. --John _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 20:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIwyn-0001jh-Tb; Thu, 31 Aug 2006 20:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIwym-0001jc-A2 for idr@ietf.org; Thu, 31 Aug 2006 20:33:52 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIwyk-0008MA-Te for idr@ietf.org; Thu, 31 Aug 2006 20:33:52 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k810eHBw052103; Thu, 31 Aug 2006 20:40:17 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200609010040.k810eHBw052103@workhorse.brookfield.occnc.com> To: "Glen Kent" Subject: Re: [Idr] draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths In-reply-to: Your message of "Fri, 01 Sep 2006 05:28:52 +0530." <92c950310608311658x55877185q53061ec6f95f688a@mail.gmail.com> Date: Thu, 31 Aug 2006 20:40:16 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <92c950310608311658x55877185q53061ec6f95f688a@mail.gmail.com> "Glen Kent" writes: > > Curtis, > > > You've just dismissed a real case above. A minor misconfiguration > > (not setting next-hop self) could result in routes being ambiguous. > > Similarly, a minor misconfiguration (of setting as-override) can > result in possible occurances of routing loops. > > So whats the point? Unless I'm mistaken, omitting next-hop-self is the default. > Is BGP flawed to not inherently work with misconfigurations around? I > think its a well known that there are infinite ways to axe your foot > with BGP; not setting next-hop-self in IXes would be just one of them. > > > > > > E.g. where multiple-hop "restricts" paths advertisements in > > > accordance with (destination,target), the add-path approach on the > > > other hand can make it impossible to reconcile that two paths are > > > identical[2]. In other words, add-path turns BGP into a flooding > > > protocol between contiguous sets of add-path speakers[1]. > > > > Nice try but you have a clearly flawed argument. > > > > You can still compare attributes in the above RS example to reduce the > > multipath set to a minimal set when readvertising. You can > > The idea behind add-paths is to NOT to look at the path attributes. > Moreover, i did not see your views on the scenario given below where > add-paths would result in a lot many Updates? > > Glen. This is a silly RR configuration. Two RR within the same RR cluster for redundancy would not send routes to each other. If they were different RR clusters the client A would not be in both clusters. Anyway it would still work, just have extra routes. Curtis > > disambiguate the advertisements with the same next hop from different > > peers with different AS path such that you know to keep two copies and > > delete only one of them when one router withdraws the route. > > > > > The problem is, in chasing ultimate flexibility, add-path makes > > > itself a quite inefficient flooding mechanism. BGP paths will be > > > flooded along /every/ possible path between a contiguous set of > > > add-path speakers: > > > > > > RR2 > > > / | \ > > > (P)A | B > > > \ | / > > > RR1 > > > > > > Based on Add-Path alone, B would receive: > > > > > > (A->RR2->B): P:a > > > (A->RR1->B): P:b > > > (A->RR2->RR1->B): P:c > > > (A->RR1->RR2->B): P:d > > > > > > Now think about convergence if A withdraws P. B is going to just > > > switch between the different 'ghosts', as they are all equal bar the > > > path-ID, until /all/ are withdrawn[3]. > > > > > > And that's just with two hops of add-path. > > > > > > So the flexibility is not quite free. > > > > > > --paulj > > > > > > 1. It took a while to tease out that add-path does indeed amount to > > > random local IDs, rather than distinguishable IDs derived in some > > > way though.. > > > > > > 2. Other than by comparing path-attributes, but not having to care > > > about path attributes (inc. nexthop) is part of the attraction of > > > add-path. > > > > > > 3. Course, we could just say that the two RR's must never enable > > > Add-Path between each other (as is the case for reflection today), > > > but doesn't that seem restrictive? :) The Add-Path draft does not > > > disallow 2-way add-path. > > > > > > Maybe Add-Path for inter-RR could be defined to compare > > > router-ID of paths from clients against ORIGINATOR_ID of paths > > > from RRs? But that defeats the point somewhat of using a new > > > opaque ID as discriminator. > > > > > > regards, _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 20:35:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIx0I-0002yb-46; Thu, 31 Aug 2006 20:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIx0G-0002vt-KG for idr@ietf.org; Thu, 31 Aug 2006 20:35:24 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIx0F-0000By-CI for idr@ietf.org; Thu, 31 Aug 2006 20:35:24 -0400 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 31 Aug 2006 17:33:30 -0700 X-IronPort-AV: i="4.08,195,1154934000"; d="scan'208"; a="577737066:sNHT28039106" Received: from [172.24.92.153] ([172.24.92.153]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 17:35:22 -0700 Message-ID: <44F7804A.2040202@juniper.net> Date: Thu, 31 Aug 2006 17:35:22 -0700 From: Pedro Roque Marques User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: "John G. Scudder" Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt References: <200608302024.k7UKOSEO084246@workhorse.brookfield.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2006 00:35:22.0168 (UTC) FILETIME=[8233A380:01C6CD5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org John G. Scudder wrote: > Also, the fact that one non-obvious casualty of using next hop as > identifier has been identified leads me to be concerned that others, as > yet unidentified, may also exist. I'd like to suggest that rough consensus has been reached that the next-hop attribute is not a viable path identifier. Except for the authors, is there anyone that doesn't consider this to be a "self evident truth" by now ? Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 21:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIxVP-0003Lw-VW; Thu, 31 Aug 2006 21:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIxVP-0003Lr-7p for idr@ietf.org; Thu, 31 Aug 2006 21:07:35 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIxVK-0005Xf-UH for idr@ietf.org; Thu, 31 Aug 2006 21:07:35 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k811E0u2055257; Thu, 31 Aug 2006 21:14:00 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200609010114.k811E0u2055257@workhorse.brookfield.occnc.com> To: curtis@occnc.com Subject: Re: [Idr] draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths In-reply-to: Your message of "Thu, 31 Aug 2006 20:40:16 EDT." <200609010040.k810eHBw052103@workhorse.brookfield.occnc.com> Date: Thu, 31 Aug 2006 21:14:00 -0400 From: Curtis Villamizar X-Spam-Score: 1.2 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <200609010040.k810eHBw052103@workhorse.brookfield.occnc.com> Curtis Villamizar writes: In message <92c950310608311658x55877185q53061ec6f95f688a@mail.gmail.com> "Glen Kent" writes: > > > > Curtis, > > > > > You've just dismissed a real case above. A minor misconfiguration > > > (not setting next-hop self) could result in routes being ambiguous. > > > > Similarly, a minor misconfiguration (of setting as-override) can > > result in possible occurances of routing loops. > > > > So whats the point? > > Unless I'm mistaken, omitting next-hop-self is the default. Forgot to mention that configuring AS-override results in a violation of the BGP spec and therefore need not be considered. Third party next hop is explicitly mentioned in the BGP spec in "5.1.3. NEXT_HOP" on page 26 and it is perfectly legal to use this feature. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 31 21:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIxZL-0005cx-Gn; Thu, 31 Aug 2006 21:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIxZJ-0005cs-Uh for idr@ietf.org; Thu, 31 Aug 2006 21:11:37 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIxZI-000637-LH for idr@ietf.org; Thu, 31 Aug 2006 21:11:37 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k811I7Z4055302; Thu, 31 Aug 2006 21:18:07 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200609010118.k811I7Z4055302@workhorse.brookfield.occnc.com> To: idr@ietf.org Date: Thu, 31 Aug 2006 21:18:07 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Idr] multiple-next-hops vs add-paths : AS confed example X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org There was no response to my AS confed example probably since it was at the end of a long message and changed the topic. So I'm resending the example as a separate message. Curtis A similar situation exists with confederations. A route may be passed through different private AS but with BGP confederations the next hop is generally not changed, relying on the next hop advertised by the router that borders the external AS and relying on the IGP rather than the set of EIBGP advertisers. In this case the AS Paths would be different *until* the confederation AS were dropped before advertising the route externally. Consider this case. ASe1 - R1/NH1 ----- R3/AS65001 \ / \ X R5/AS65003 - R6/AS65004 / \ / ASe2 - R2/NH2 ---- R4/AS65002 R5 gets the following routes: R3: AS65001 ASexternal1 NH1 AS65001 ASexternal2 NH2 R4: AS65002 ASexternal1 NH1 AS65001 ASexternal2 NH2 It doesn't seem that based on NH there is a good way to disambiguate the components of this multipath. A good question is exactly what R5 should advertise to R6 such that the AS path is correct. It seems that the tuple adds an ability to disambiguate this case. My understanding of add-path is that the advertisement would be: R5 -> R6: prefix X path-id 1 AS65003 AS65001 ASexternal1 NH1 prefix X path-id 2 AS65003 AS65001 ASexternal2 NH2 prefix X path-id 3 AS65003 AS65002 ASexternal1 NH1 prefix X path-id 4 AS65003 AS65001 ASexternal2 NH2 Maybe the multiple-next-hops and add-path advocates can kick this example around for a while. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr