RE: [Idr] BGP Protocol Experience Draft (-04)
"Susan Hares" <shares@nexthop.com> Fri, 21 May 2004 22:12 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08040 for <idr-archive@ietf.org>; Fri, 21 May 2004 18:12:40 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRIFu-00031Q-Jr for idr-archive@ietf.org; Fri, 21 May 2004 18:12:42 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRIEw-0002w1-00 for idr-archive@ietf.org; Fri, 21 May 2004 18:11:44 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRIE6-0002qz-00; Fri, 21 May 2004 18:10:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI8T-0003fr-PH; Fri, 21 May 2004 18:05:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRI5O-0002Wj-N8 for idr@optimus.ietf.org; Fri, 21 May 2004 18:01:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06839 for <idr@ietf.org>; Fri, 21 May 2004 18:01:46 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRI5L-00026A-QN for idr@ietf.org; Fri, 21 May 2004 18:01:47 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRI4X-00021p-00 for idr@ietf.org; Fri, 21 May 2004 18:00:59 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BRI3m-0001uK-00 for idr@ietf.org; Fri, 21 May 2004 18:00:10 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3BE392D4955 for <idr@ietf.org>; Fri, 21 May 2004 17:59:41 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15621-01-68 for <idr@ietf.org>; Fri, 21 May 2004 17:59:28 -0400 (EDT)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 33A9D2D4873 for <idr@ietf.org>; Fri, 21 May 2004 17:59:26 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Idr] BGP Protocol Experience Draft (-04)
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E0181BDFD@aa-exchange1.corp.nexthop.com>
Thread-Topic: [Idr] BGP Protocol Experience Draft (-04)
Thread-Index: AcQ893qztl3ympD3Q/OmL8bIAnmfuABekJLg
From: Susan Hares <shares@nexthop.com>
To: idr <idr@ietf.org>
Cc: Keyur Patel <keyupate@cisco.com>, Danny McPherson <danny@tcb.net>
X-Virus-Scanned: by amavisd-new at nexthop.com
Content-Transfer-Encoding: quoted-printable
Sender: idr-admin@ietf.org
Errors-To: idr-admin@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Fri, 21 May 2004 17:59:25 -0400
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
idr working group: We will start a 1 week Last Call on the BGP protocol Experience Draft revision that Danny explains below. Please send any comments on the draft-ietf-idr-bgp4-experience-protocol-04.txt This Last call will end 5/27/04. Sue -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Tuesday, May 18, 2004 12:18 PM To: idr Cc: Keyur Patel Subject: [Idr] BGP Protocol Experience Draft (-04) I just posted an update version of the BGP Protocol Experience draft. Not much changed, here's a diff from the -03 revision, the new version (-04) should be available in the Internet-Drafts repository RSN. Not sure if it needs to relive WG LC or not.. -danny < Expires: March 2004 September 2003 --- > Expires: November 2004 May 2004 10c10 < <draft-ietf-idr-bgp4-experience-protocol-03.txt> --- > <draft-ietf-idr-bgp4-experience-protocol-04.txt> 45c45 < Copyright (C) The Internet Society (2003). All Rights Reserved. --- > Copyright (C) The Internet Society (2004). All Rights Reserved. 54c54 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 110c110 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 120c120 < 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 5 --- > 4. Implementation Information . . . . . . . . . . . . . . . . . . 5 129c129 < 8. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 --- > 8. Local Preference . . . . . . . . . . . . . . . . . . . . . . . 9 135c135 < 13.1. Consideration of TCP Characteristics . . . . . . . . . . . 13 --- > 13.1. Consideration of TCP Characteristics . . . . . . . . . . . 14 140c140 < 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 --- > 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 16 142c142 < 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 --- > 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 17 146c146 < A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 17 --- > A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 18 166c166 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 222c222 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 243c243 < 4. Implementations --- > 4. Implementation Information 278c278 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 287c287 < Confederations for BGP, and perhaps some mix of the two. BGP Route --- > Confederations for BGP, and often some mix of the two. BGP Route 305c305 < 120,000 aggregate entries, representing several times that number of --- > 134,000 aggregate entries, representing several times that number of 307c307 < provider core routers exceeds 2.5 million. Native AS_PATH lengths --- > provider core routers exceeds 2.5 million. Native AS path lengths 309c309 < more ASs exist. --- > more autonomous systems exist. 334c334 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 341,342c341,342 < is used as a metric by EBGP peers while BGP Local Preference is used < by IBGP peers. --- > is used as a metric by EBGP peers (i.e., inter-domain) while Local > Preference (LOCAL_PREF) is used by IBGP peers (i.e., intra-domain). 358c358 < different ASs as well. --- > different autonomous systems as well. 366,371c366,371 < between multiple paths learned from a single AS, it can result in < potentially bad decisions when comparing MEDs between different < automomous systems. This is most typically the case when the < autonomous systems use different mechanisms to derive IGP metrics, < BGP MEDs, or perhaps even use different IGP procotols with vastly < contrasting metric spaces. --- > between multiple paths learned from a single adjacent AS, it can > result in potentially bad decisions when comparing MEDs between > different automomous systems. This is most typically the case when > the autonomous systems use different mechanisms to derive IGP > metrics, BGP MEDs, or perhaps even use different IGP procotols with > vastly contrasting metric spaces. 390c390 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 430a431,434 > Seemingly more intuitive references that fall outside the vegetable > kingdom refer to cold potatoe routing as "best exit routing", and hot > potatoe routing as "closest exit routing", though vegetable. > 437,440d440 < be passed to its IBGP peers. Although advertising MEDs to IBGP peers < is not a required behavior, it is a common default. MEDs received < from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP < peers. 446c446 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 448a449,453 > be passed to its IBGP peers. Although advertising MEDs to IBGP peers > is not a required behavior, it is a common default. MEDs received > from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP > peers. > 459,462c464,467 < An implementation MUST provide a mechanism that allows for MED to be < removed. Previously, implementations did not consider a missing MED < value to be the same as a MED of zero. No MED value should now be < equal to a value of zero. --- > [BGP4] requires that an implementation must provide a mechanism that > allows for MED to be removed. Previously, implementations did not > consider a missing MED value to be the same as a MED of zero. [BGP4] > now requires that no MED value be equal to a value of zero. 464c469 < Note that many implementations provide an mechanism to explicitly --- > Note that many implementations provide a mechanism to explicitly 479c484 < non-deterministic behavior, and as such, is often undesirable. --- > non-deterministic behavior, and as such, may often be undesirable. 483c488 < 8. LOCAL_PREF --- > 8. Local Preference 492,496d496 < default value of LOCAL-PREF to be assumed if none was provided. < Defaults of 0 or the maximum value each have range limitations, so a < common default would aid in the interoperation of multi-vendor < routers in the same AS (since LOCAL_PREF is a local administration < knob, there is no interoperability drawback across AS boundaries). 502c502 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 505,507c505,514 < The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute < MUST NOT be sent to EBGP Peers. Although no default value for < LOCAL_PREF is defined, the common default value is 100. --- > default value of LOCAL_PREF to be assumed if none was provided. > Defaults of 0 or the maximum value each have range limitations, so a > common default would aid in the interoperation of multi-vendor > routers in the same AS (since LOCAL_PREF is a local administration > attribute, there is no interoperability drawback across AS > boundaries). > > [BGP4] requires that LOCAL_PREF be sent to IBGP Peers and must not be > sent to EBGP Peers. Although no default value for LOCAL_PREF is > defined, the common default value is 100. 526c533 < possibility of carrying an optional vector corresponding to the AS- --- > possibility of carrying an optional vector corresponding to the AS_ 528,534c535,542 < given route. Cooperating ASs may then chose traffic based upon < comparison of "interesting" portions of this vector according to < routing policy. < < While protecting a given ASs routing policy is of paramount concern, < avoiding extensive hand configuration of routing policies needs to be < examined more carefully in future BGP-like protocols. --- > given route. Cooperating autonomous systems may then chose traffic > based upon comparison of "interesting" portions of this vector > according to routing policy. > > While protecting a given autonoumous systems routing policy is of > paramount concern, avoiding extensive hand configuration of routing > policies needs to be examined more carefully in future BGP-like > protocols. 545,552d552 < information to all other transit and border routers within that AS. < This is typically done by establishing internal BGP connections to < all transit and border routers in the local AS. < < Note that the number of BGP peers that can be fully meshed depends on < a number of factors, to include number of prefixes in the routing < system, stability of the system, and perhaps most importantly, < implementation ifficiency. As a result, although it's difficult to 558c558 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 561,562c561,570 < define "a large number of peers", there is always some practical < limit. --- > information to all other transit and border routers within that AS. > This is typically done by establishing internal BGP connections to > all transit and border routers in the local AS. > > Note that the number of BGP peers that can be fully meshed depends on > a number of factors, to include number of prefixes in the routing > system, number of unique path, stability of the system, and perhaps > most importantly, implementation efficiency. As a result, although > it's difficult to define "a large number of peers", there is always > some practical limit. 582,583c590,591 < Internet. As the net has grown, the number of route changes per < second has increased. --- > Internet. As the Internet has grown, the frequency of route changes > per second has increased. 600c608,616 < manditory in RFC 2439. A potential result of failure to consider --- > mandatory in RFC 2439. A potential result of failure to consider > > > > McPherson, Patel Section 10. [Page 11] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 609,620c625,628 < < < < McPherson, Patel Section 10. [Page 11] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < < changes to be announced are inefficiently packed. As previously < discussed, announcing routing changes sharing common attributes in a < single BGP UPDATE message helps save considerable bandwidth and lower < processing overhead. --- > changes to be announced are inefficiently packed. As discussed in a > later section, announcing routing changes sharing common attributes > in a single BGP UPDATE message helps save considerable bandwidth and > lower processing overhead. 656a665,672 > > > > McPherson, Patel Section 12. [Page 12] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 665,672d680 < < < < McPherson, Patel Section 12. [Page 12] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < 712a721,728 > > > > McPherson, Patel Section 13. [Page 13] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 721,728d736 < < < < McPherson, Patel Section 13.1. [Page 13] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < 738,741c746,749 < buffer can grow until memory is exhausted. A BGP implementation must < send changes to all peers for which the TCP connection is not blocked < and must remember to send those changes to the remaining peers when < the connection becomes unblocked. --- > buffer can grow until memory is exhausted. A BGP implementation is > required to send changes to all peers for which the TCP connection is > not blocked and is required to remember to send those changes to the > remaining peers when the connection becomes unblocked. 769,773d776 < Implementers may find it useful to order path attributes according to < Type Code so that sets of attributes with identical semantics can be < more quickly identified. < < 776a780,782 > McPherson, Patel Section 14. [Page 14] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 778a785,787 > Implementers may find it useful to order path attributes according to > Type Code so that sets of attributes with identical semantics can be > more quickly identified. 780,782d788 < McPherson, Patel Section 14. [Page 14] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 802c808,810 < to BGP-4 should provide the version support on a per-peer basis. --- > to BGP-4 should provide the version support on a per-peer basis. At > the time of this writing all BGP speakers on the Internet are thought > to be running BGP version 4. 822a831,840 > > > > > > McPherson, Patel Section 17. [Page 15] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 833,840d850 < < < < McPherson, Patel Section 17.1. [Page 15] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < 844a855,867 > It was naively assumed by many for some time that in order to inject > a data segement or reset a TCP transport connection between two BGP > peers an attacker must correctly guess the exact TCP sequence number > (of course, in addition to source and destination ports and IP > addresses). However, it has recently been observed and openly > discussed that the malicous data only needs to fall within the TCP > receive window, which may be quite large, thereby significantly > lowering the complexity of such an attack. > > As such, it is recommended that the MD5 TCP Signature Option be > employed to protect BGP from session resets and malicious data > injection. > 867a891,896 > > McPherson, Patel Section 17.2. [Page 16] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 888,896d916 < < < < < McPherson, Patel Section 17.3. [Page 16] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < 924a945,952 > > > > McPherson, Patel Section 17.5. [Page 17] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 946,952d973 < < < McPherson, Patel Section 17.6. [Page 17] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < 979a1001,1008 > > > > McPherson, Patel Section 17.6. [Page 18] > ^L > INTERNET-DRAFT Expires: November 2004 May 2004 > > 1004,1008d1032 < McPherson, Patel Section 17.6. [Page 18] < ^L < INTERNET-DRAFT Expires: March 2004 September 2003 < < 1036,1059d1059 < < < < < < < < < < < < < < < < < < < < < < < < 1062c1062 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 1118c1118 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 1139c1139,1140 < [BGP4-ANALYSIS] Work in Progress. --- > [BGP4-ANALYSIS] "BGP-4 Protocol Analysis", Internet-Draft, Work in > Progress. 1141c1142,1143 < [BGP4-IMPL] Work in Progress. --- > [BGP4-IMPL] "BGP 4 Implementation Report ", Internet-Draft, Work > in Progress. 1146c1148 < [SBGP] --- > [SBGP] "Secure BGP", Internet-Draft, Work in Progress. 1148c1150 < [soBGP] --- > [soBGP] "Secure Origin BGP", Internet-Draft, Work in Progress. 1170,1171d1171 < < 1174c1174 < INTERNET-DRAFT Expires: March 2004 September 2003 --- > INTERNET-DRAFT Expires: November 2004 May 2004 1179c1179 < Copyright (C) The Internet Society (2003). All Rights Reserved. --- > Copyright (C) The Internet Society (2004). All Rights Reserved. _______________________________________________ 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] BGP Protocol Experience Draft (-04) Danny McPherson
- RE: [Idr] BGP Protocol Experience Draft (-04) Susan Hares