From idr-bounces@ietf.org Sun Jun 03 22:38:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2SD-00038P-Kw; Sun, 03 Jun 2007 22:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2SC-00038K-RR for idr@ietf.org; Sun, 03 Jun 2007 22:37:56 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv2SA-0007uF-4Q for idr@ietf.org; Sun, 03 Jun 2007 22:37:56 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 7531D53E1B5; Sun, 3 Jun 2007 22:37:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id PEIAlEv9BgVE; Sun, 3 Jun 2007 22:37:47 -0400 (EDT) Received: from [172.16.13.202] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 2600D53E0FC; Sun, 3 Jun 2007 22:37:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <925B3B5B-CF7D-4EED-8397-3A50FBAD9B23@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Date: Sun, 3 Jun 2007 22:37:21 -0400 To: idr@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: John Scudder Subject: [Idr] draft-ietf-idr-rfc3065bis-06.txt editorial change 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, While editing draft-ietf-idr-rfc3065bis-06.txt for publication, the vigilant RFC Editor pointed out several nits with the draft. Most can be resolved as minor editorial changes, however, one of them is slightly more than that. Section 4.1 of the draft ("AS_PATH Modification Rules") is essentially a cut-n-paste of section 5.1.2 of the base spec, with necessary changes for confederations. Unfortunately, we did not revise the draft to match when the base spec was revised. To correct this, we propose to re-do section 4.1. There are no changes of any substance compared to earlier versions, i.e. the intent is still to say "do what the base spec does, only do it with confed-type segments", but the text is brought into line with RFC 4271. The change is extensive enough that we thought it worthwhile to poll the WG again. Chairs, please consider this a request for a WGLC, only on this revised text. Thanks, --John (with Danny and Paul) Revised section 4.1: 4.1. AS_PATH Modification Rules AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or AS_CONFED_SEQUENCES. When a BGP speaker propagates a route it learned from another BGP speaker's UPDATE message, it modifies the route's AS_PATH attribute based on the location of the BGP speaker to which the route will be sent: a) When a given BGP speaker advertises the route to another BGP speaker located in its own Member-AS, the advertising speaker SHALL NOT modify the AS_PATH attribute associated with the route. b) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is a member of the local confederation, the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_CONFED_SEQUENCE, the local system prepends its own Member-AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is not of type AS_CONFED_SEQUENCE the local system prepends a new path segment of type AS_CONFED_SEQUENCE to the AS_PATH, including its own Member-AS Number in that segment. 3) if the AS_PATH is empty, the local system creates a path segment of type AS_CONFED_SEQUENCE, places its own Member-AS Number into that segment, and places that segment into the AS_PATH. c) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is not a member of the local confederation, the advertising speaker SHALL update the AS_PATH attribute as follows: 1) if any path segments of the AS_PATH are of the type AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST be removed from the AS_PATH attribute, leaving the sanitized AS_PATH attribute to be operated on by steps 2, 3 or 4. 2) if the first path segment of the remaining AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS Confederation Identifier as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 3) if the first path segment of the remaining AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS Confederation Identifier in that segment. 4) if the remaining AS_PATH is empty, the local system creates a path segment of type AS_SEQUENCE, places its own AS Confederation Identifier into that segment, and places that segment into the AS_PATH. When a BGP speaker originates a route then: a) the originating speaker includes its own AS Confederation Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring autonomous systems that are not members of the local confederation. In this case, the AS Confederation Identifier of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute. a) the originating speaker includes its own Member-AS Number in a path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring Member Autonomous Systems that are members of the local confederation. In this case, the Member-AS Number of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute. c) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to BGP speakers residing within the same Member-AS. (An empty AS_PATH attribute is one whose length field contains the value zero). Whenever the modification of the AS_PATH attribute calls for including or prepending the AS Confederation Identifier or Member-AS Number of the local system, the local system MAY include/prepend more than one instance of that value in the AS_PATH attribute. This is controlled via local configuration. Diff vs. draft-ietf-idr-rfc3065bis-06.txt (ends up including pretty much the whole section): 3,10c3,12 < < When implementing BGP Confederations Section 5.1.2 of [BGP-4] is < replaced with the following text: < < When a BGP speaker propagates a route which it has learned from < another BGP speaker's UPDATE message, it SHALL modify the route's < AS_PATH attribute based on the location of the BGP speaker to which < the route will be sent: --- > AS_PATH is a well-known mandatory attribute. This attribute > identifies the autonomous systems through which routing information > carried in this UPDATE message has passed. The components of this > list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or > AS_CONFED_SEQUENCES. > > When a BGP speaker propagates a route it learned from another BGP > speaker's UPDATE message, it modifies the route's AS_PATH attribute > based on the location of the BGP speaker to which the route will be > sent: 19c21 < the local confederation, the advertising speaker SHALL update --- > the local confederation, the advertising speaker updates 23,25c25,31 < AS_CONFED_SEQUENCE, the local system SHALL prepend its own < Member-AS Number as the last element of the sequence (put < it in the leftmost position). --- > AS_CONFED_SEQUENCE, the local system prepends its own Member-AS > number as the last element of the sequence (put it in the > leftmost position with respect to the position of octets in the > protocol message). If the act of prepending will cause an > overflow in the AS_PATH segment (i.e., more than 255 ASes), it > SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and > prepend its own AS number to this new segment. 28c34 < AS_CONFED_SEQUENCE the local system SHALL prepend a new path --- > AS_CONFED_SEQUENCE the local system prepends a new path 31a38,42 > 3) if the AS_PATH is empty, the local system creates a path > segment of type AS_CONFED_SEQUENCE, places its own Member-AS > Number into that segment, and places that segment into the > AS_PATH. > 40c51 < AS_PATH attribute to be operated on by steps 2 or 3. --- > AS_PATH attribute to be operated on by steps 2, 3 or 4. 43,51c54,65 < AS_SEQUENCE, the local system SHALL prepend its own < AS Confederation Identifier as the last element of the sequence < (put it in the leftmost position). < < 3) if there are no path segments following the removal of the < first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the < first path segment of the remaining AS_PATH is not of type < AS_SEQUENCE the local system SHALL prepend a new path segment < of type AS_SEQUENCE to the AS_PATH, including its own AS --- > AS_SEQUENCE, the local system prepends its own AS Confederation > Identifier as the last element of the sequence (put it in > the leftmost position with respect to the position of > octets in the protocol message). If the act of prepending > will cause an overflow in the AS_PATH segment (i.e., more > than 255 ASes), it SHOULD prepend a new segment of type > AS_SEQUENCE and prepend its own AS number to this new > segment. > > 3) if the first path segment of the remaining AS_PATH is of type > AS_SET, the local system prepends a new path segment of > type AS_SEQUENCE to the AS_PATH, including its own AS 54,63c68,86 < When a BGP speaker originates a route: < < a) the originating speaker SHALL include an empty AS_PATH attribute < in all UPDATE messages sent to BGP speakers residing within the < same Member-AS. (An empty AS_PATH attribute is one whose length < field contains the value zero). < < b) the originating speaker SHALL include its own Member-AS Number in < an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all < UPDATE messages sent to BGP speakers located in neighboring --- > 4) if the remaining AS_PATH is empty, the local system creates > a path segment of type AS_SEQUENCE, places its own AS > Confederation Identifier into that segment, and places > that segment into the AS_PATH. > > When a BGP speaker originates a route then: > > a) the originating speaker includes its own AS Confederation > Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH > attribute of all UPDATE messages sent to BGP speakers located in > neighboring autonomous systems that are not members of the local > confederation. In this case, the AS Confederation Identifier of > the originating speaker's autonomous system will be the only entry > the path segment, and this path segment will be the only segment > in the AS_PATH attribute. > > a) the originating speaker includes its own Member-AS Number in a > path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute > of all UPDATE messages sent to BGP speakers located in neighboring 65,66c88,102 < confederation (i.e., the originating speaker's Member-AS Number < will be the only entry in the AS_PATH attribute). --- > confederation. In this case, the Member-AS Number of the > originating speaker's autonomous system will be the only entry the > path segment, and this path segment will be the only segment in > the AS_PATH attribute. > > c) the originating speaker includes an empty AS_PATH attribute in > all UPDATE messages sent to BGP speakers residing within the same > Member-AS. (An empty AS_PATH attribute is one whose length field > contains the value zero). > > Whenever the modification of the AS_PATH attribute calls for > including or prepending the AS Confederation Identifier or > Member-AS Number of the local system, the local system MAY > include/prepend more than one instance of that value in the > AS_PATH attribute. This is controlled via local configuration. 68,74d103 < c) the originating speaker SHALL include its own AS Confederation < Identifier in an AS_SEQUENCE segment of the AS_PATH attribute of < all UPDATE messages sent to BGP speakers located in neighboring < autonomous systems that are not members of the local < confederation. (In this case, the originating speaker's AS < Confederation Identifier will be the only entry in the AS_PATH < attribute). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jun 03 23:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv3Jf-00080v-Ar; Sun, 03 Jun 2007 23:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv3Je-00080q-9Q for idr@ietf.org; Sun, 03 Jun 2007 23:33:10 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv3Jc-0006nJ-Ik for idr@ietf.org; Sun, 03 Jun 2007 23:33:10 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 03 Jun 2007 20:33:08 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l543X7J48305 for ; Sun, 3 Jun 2007 20:33:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200706040333.l543X7J48305@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83631.1180927987.1@juniper.net> Date: Sun, 03 Jun 2007 20:33:07 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Subject: [Idr] Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, This is to start the IDR WG Last Call on draft-ietf-idr-rfc3065bis-06.txt. Please note that the scope of this Last Call is limited to only the revised text. The Last Call ends on June 17. Yakov. ------- Forwarded Message Date: Sun, 03 Jun 2007 22:37:21 -0400 From: "John G. Scudder" To: idr@ietf.org cc: John Scudder Subject: [Idr] draft-ietf-idr-rfc3065bis-06.txt editorial change Folks, While editing draft-ietf-idr-rfc3065bis-06.txt for publication, the vigilant RFC Editor pointed out several nits with the draft. Most can be resolved as minor editorial changes, however, one of them is slightly more than that. Section 4.1 of the draft ("AS_PATH Modification Rules") is essentially a cut-n-paste of section 5.1.2 of the base spec, with necessary changes for confederations. Unfortunately, we did not revise the draft to match when the base spec was revised. To correct this, we propose to re-do section 4.1. There are no changes of any substance compared to earlier versions, i.e. the intent is still to say "do what the base spec does, only do it with confed-type segments", but the text is brought into line with RFC 4271. The change is extensive enough that we thought it worthwhile to poll the WG again. Chairs, please consider this a request for a WGLC, only on this revised text. Thanks, - --John (with Danny and Paul) Revised section 4.1: 4.1. AS_PATH Modification Rules AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or AS_CONFED_SEQUENCES. When a BGP speaker propagates a route it learned from another BGP speaker's UPDATE message, it modifies the route's AS_PATH attribute based on the location of the BGP speaker to which the route will be sent: a) When a given BGP speaker advertises the route to another BGP speaker located in its own Member-AS, the advertising speaker SHALL NOT modify the AS_PATH attribute associated with the route. b) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is a member of the local confederation, the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_CONFED_SEQUENCE, the local system prepends its own Member-AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is not of type AS_CONFED_SEQUENCE the local system prepends a new path segment of type AS_CONFED_SEQUENCE to the AS_PATH, including its own Member-AS Number in that segment. 3) if the AS_PATH is empty, the local system creates a path segment of type AS_CONFED_SEQUENCE, places its own Member-AS Number into that segment, and places that segment into the AS_PATH. c) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is not a member of the local confederation, the advertising speaker SHALL update the AS_PATH attribute as follows: 1) if any path segments of the AS_PATH are of the type AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST be removed from the AS_PATH attribute, leaving the sanitized AS_PATH attribute to be operated on by steps 2, 3 or 4. 2) if the first path segment of the remaining AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS Confederation Identifier as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 3) if the first path segment of the remaining AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS Confederation Identifier in that segment. 4) if the remaining AS_PATH is empty, the local system creates a path segment of type AS_SEQUENCE, places its own AS Confederation Identifier into that segment, and places that segment into the AS_PATH. When a BGP speaker originates a route then: a) the originating speaker includes its own AS Confederation Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring autonomous systems that are not members of the local confederation. In this case, the AS Confederation Identifier of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute. a) the originating speaker includes its own Member-AS Number in a path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring Member Autonomous Systems that are members of the local confederation. In this case, the Member-AS Number of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute. c) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to BGP speakers residing within the same Member-AS. (An empty AS_PATH attribute is one whose length field contains the value zero). Whenever the modification of the AS_PATH attribute calls for including or prepending the AS Confederation Identifier or Member-AS Number of the local system, the local system MAY include/prepend more than one instance of that value in the AS_PATH attribute. This is controlled via local configuration. Diff vs. draft-ietf-idr-rfc3065bis-06.txt (ends up including pretty much the whole section): 3,10c3,12 < < When implementing BGP Confederations Section 5.1.2 of [BGP-4] is < replaced with the following text: < < When a BGP speaker propagates a route which it has learned from < another BGP speaker's UPDATE message, it SHALL modify the route's < AS_PATH attribute based on the location of the BGP speaker to which < the route will be sent: - --- > AS_PATH is a well-known mandatory attribute. This attribute > identifies the autonomous systems through which routing information > carried in this UPDATE message has passed. The components of this > list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or > AS_CONFED_SEQUENCES. > > When a BGP speaker propagates a route it learned from another BGP > speaker's UPDATE message, it modifies the route's AS_PATH attribute > based on the location of the BGP speaker to which the route will be > sent: 19c21 < the local confederation, the advertising speaker SHALL update - --- > the local confederation, the advertising speaker updates 23,25c25,31 < AS_CONFED_SEQUENCE, the local system SHALL prepend its own < Member-AS Number as the last element of the sequence (put < it in the leftmost position). - --- > AS_CONFED_SEQUENCE, the local system prepends its own Member-AS > number as the last element of the sequence (put it in the > leftmost position with respect to the position of octets in the > protocol message). If the act of prepending will cause an > overflow in the AS_PATH segment (i.e., more than 255 ASes), it > SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and > prepend its own AS number to this new segment. 28c34 < AS_CONFED_SEQUENCE the local system SHALL prepend a new path - --- > AS_CONFED_SEQUENCE the local system prepends a new path 31a38,42 > 3) if the AS_PATH is empty, the local system creates a path > segment of type AS_CONFED_SEQUENCE, places its own Member-AS > Number into that segment, and places that segment into the > AS_PATH. > 40c51 < AS_PATH attribute to be operated on by steps 2 or 3. - --- > AS_PATH attribute to be operated on by steps 2, 3 or 4. 43,51c54,65 < AS_SEQUENCE, the local system SHALL prepend its own < AS Confederation Identifier as the last element of the sequence < (put it in the leftmost position). < < 3) if there are no path segments following the removal of the < first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the < first path segment of the remaining AS_PATH is not of type < AS_SEQUENCE the local system SHALL prepend a new path segment < of type AS_SEQUENCE to the AS_PATH, including its own AS - --- > AS_SEQUENCE, the local system prepends its own AS Confederation > Identifier as the last element of the sequence (put it in > the leftmost position with respect to the position of > octets in the protocol message). If the act of prepending > will cause an overflow in the AS_PATH segment (i.e., more > than 255 ASes), it SHOULD prepend a new segment of type > AS_SEQUENCE and prepend its own AS number to this new > segment. > > 3) if the first path segment of the remaining AS_PATH is of type > AS_SET, the local system prepends a new path segment of > type AS_SEQUENCE to the AS_PATH, including its own AS 54,63c68,86 < When a BGP speaker originates a route: < < a) the originating speaker SHALL include an empty AS_PATH attribute < in all UPDATE messages sent to BGP speakers residing within the < same Member-AS. (An empty AS_PATH attribute is one whose length < field contains the value zero). < < b) the originating speaker SHALL include its own Member-AS Number in < an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all < UPDATE messages sent to BGP speakers located in neighboring - --- > 4) if the remaining AS_PATH is empty, the local system creates > a path segment of type AS_SEQUENCE, places its own AS > Confederation Identifier into that segment, and places > that segment into the AS_PATH. > > When a BGP speaker originates a route then: > > a) the originating speaker includes its own AS Confederation > Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH > attribute of all UPDATE messages sent to BGP speakers located in > neighboring autonomous systems that are not members of the local > confederation. In this case, the AS Confederation Identifier of > the originating speaker's autonomous system will be the only entry > the path segment, and this path segment will be the only segment > in the AS_PATH attribute. > > a) the originating speaker includes its own Member-AS Number in a > path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute > of all UPDATE messages sent to BGP speakers located in neighboring 65,66c88,102 < confederation (i.e., the originating speaker's Member-AS Number < will be the only entry in the AS_PATH attribute). - --- > confederation. In this case, the Member-AS Number of the > originating speaker's autonomous system will be the only entry the > path segment, and this path segment will be the only segment in > the AS_PATH attribute. > > c) the originating speaker includes an empty AS_PATH attribute in > all UPDATE messages sent to BGP speakers residing within the same > Member-AS. (An empty AS_PATH attribute is one whose length field > contains the value zero). > > Whenever the modification of the AS_PATH attribute calls for > including or prepending the AS Confederation Identifier or > Member-AS Number of the local system, the local system MAY > include/prepend more than one instance of that value in the > AS_PATH attribute. This is controlled via local configuration. 68,74d103 < c) the originating speaker SHALL include its own AS Confederation < Identifier in an AS_SEQUENCE segment of the AS_PATH attribute of < all UPDATE messages sent to BGP speakers located in neighboring < autonomous systems that are not members of the local < confederation. (In this case, the originating speaker's AS < Confederation Identifier will be the only entry in the AS_PATH < attribute). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 07 17:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwP7V-00058I-A7; Thu, 07 Jun 2007 17:02:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwP7T-00058C-Vi for idr@ietf.org; Thu, 07 Jun 2007 17:02:11 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwP7S-0000j7-NB for idr@ietf.org; Thu, 07 Jun 2007 17:02:11 -0400 Received: by wa-out-1112.google.com with SMTP id j5so905612wah for ; Thu, 07 Jun 2007 14:02:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=LPYg/wc9jfON494zT7XMbSUp2MawgDDimNz1ZOoRDeUa3GJj8xlDzuXPInSEH4CR29b2b4BSGi0zKep+rM2zVfQhAWRzT9bcb4bxGfez1NBOD7HPCSQv7Gi3jzOh+MLUnguZClJqmXXRe5mgMJW6rIoCOykMi0yX1ujHWaLRgtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=D6/GRoZr/FG1pCuO8H2Ac34KxSFRG4Oj4I67E05fObdedqW5avGft7d2n99qBjXBAu0OzA2clyskV9+L9b41dftsM831n1wIK6G2BnywkKB25GioFmBnDntVXZPm4yA7QS0nJUNS0BRYnkIY/kRHmHrpu6/BQkRa2BADfagrGVE= Received: by 10.115.107.1 with SMTP id j1mr1897329wam.1181250129938; Thu, 07 Jun 2007 14:02:09 -0700 (PDT) Received: by 10.114.24.20 with HTTP; Thu, 7 Jun 2007 14:02:09 -0700 (PDT) Message-ID: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> Date: Thu, 7 Jun 2007 14:02:09 -0700 From: "Vishwas Manral" To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: tli@cisco.com Subject: [Idr] draft-ietf-idr-as-pathlimit-03.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 Tony, I had a small doubt regarding the use of AS_PATHLIMIT attribute in case the routes are getting aggregated. If the AS_PATHLIMIT is different for different routes, what would be the AS_PATHLIMIT for the aggregated route? I think it should be the minimum of the component routes. Thanks, Vishwas _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 07 17:48:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPpl-0004GM-3T; Thu, 07 Jun 2007 17:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPpk-0004E4-92 for idr@ietf.org; Thu, 07 Jun 2007 17:47:56 -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 1HwPpi-0002rp-Vq for idr@ietf.org; Thu, 07 Jun 2007 17:47:56 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2007 14:47:54 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="377927486:sNHT46481338" 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/8.12.11) with ESMTP id l57Llsci011937; Thu, 7 Jun 2007 14:47:54 -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 l57LlotX013981; Thu, 7 Jun 2007 21:47:54 GMT 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.1830); Thu, 7 Jun 2007 14:47:50 -0700 Received: from [192.168.0.100] ([10.21.70.250]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 14:47:50 -0700 In-Reply-To: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 7 Jun 2007 14:47:49 -0700 To: Vishwas Manral X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Jun 2007 21:47:50.0251 (UTC) FILETIME=[7E74D3B0:01C7A94D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1000; t=1181252874; x=1182116874; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20draft-ietf-idr-as-pathlimit-03.txt |Sender:=20; bh=utVTrDrXcjxqjAca+oeLuSUVjXIb4LN7vlaZEhpj9E4=; b=lZT1Le0pPaYLO9fFuZu4iMGD1/35VmmlYrqNsmbikJX2KoeMBu56xB9VGV7M7ckbg/GZTF7f bdbN+mL6+pYFU+VcHgMjsGLP+Pw1vSA74otg3S9i3ZEPlUIabhrW+A4X; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: idr@ietf.org Subject: [Idr] Re: draft-ietf-idr-as-pathlimit-03.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 On Jun 7, 2007, at 2:02 PM, Vishwas Manral wrote: > I had a small doubt regarding the use of AS_PATHLIMIT attribute in > case the routes are getting aggregated. If the AS_PATHLIMIT is > different for different routes, what would be the AS_PATHLIMIT for the > aggregated route? > > I think it should be the minimum of the component routes. Hi Vishwas, Thank you for your question. As you probably surmised, we did not specify that behavior. This is pretty much intentional, leaving it up to the implementation to decide what policy it will select by default. The propagation of an aggregate may have no relationship to the desired propagation of the component routes, so manual intervention is probably the best alternative. For typical aggregates, global flooding is unlikely to be an issue. The problem that we have is quite the opposite... global flooding of more specifics. Trading a number of specifics for one aggregate is a net win. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 07 19:34:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRV5-0008Mb-3v; Thu, 07 Jun 2007 19:34:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRV3-0008MV-ES for idr@ietf.org; Thu, 07 Jun 2007 19:34:41 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwRV3-0004Nf-1b for idr@ietf.org; Thu, 07 Jun 2007 19:34:41 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KMa0R8rj3NCLkp1NR4pnEvYxqdVwUb2GtM0AC84ChdalGw8Vf2yopHUmkXBini8W; 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.83.43] (helo=earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HwRV1-0000Uo-Lk; Thu, 07 Jun 2007 19:34:39 -0400 Message-ID: <4668944E.3E965824@earthlink.net> Date: Thu, 07 Jun 2007 16:27:10 -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: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt and Confeds References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7993fad840d21d54915f6429df065772e6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.83.43 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Group, et al, I disagree with the min for propogation. I can see that due to the fact that the attribute is transitive, then it should be passed no matter what. So, appling the min would effectively decrease the propogation to a non-transitive type attr based on the min value. We are trying to make sure that the attr is passed even if it is not understood. Thus, we SHOULD be able to reach the dst of PATHLIMITs based from our source. If we aggregate to the min, with periodicly changing aggregates, should we sometimes be able to reach a dst or should it be always? I fault for a consistent propogation distance of max with ALWAYS. Secondly, COULD a value ??0?? be chosen that defers its value to another value if present due to expected or possible aggregation, and use the TTL of the IP hdr if not aggregated? MY assumption is that the TTL initial value COULD be set to a smaller than expected value. However, I have a larger concern with the attribute itself. Should the attribute also be decremented when traversing Confederations? Aren't two ASs essentially two sub/logical/virtual ASs and thus propogation of routing info be controllable at the entrance of a Confederation? Would you allow it to cross ONLY 3 ASs and keep going after 100 Confederations because only 2 ASs were crossed? Would this then be able to stop routing loops within the AS if it repeatedly recrosses the same Confederations? Or should two counting fields be allocated for AS_PATHLIMIT, to count the number of Confederations traversed and to stop routing loops within a AS? So, if we set the value to three, do we stop when the sum of either is reached OR 3 of either ASs or Confiderations are traversed in sucession? If it was the later, loop mitigation would then be added as a secondary benefit, IMO. Mitchell Erblich ------------------ Tony Li wrote: > > On Jun 7, 2007, at 2:02 PM, Vishwas Manral wrote: > > > I had a small doubt regarding the use of AS_PATHLIMIT attribute in > > case the routes are getting aggregated. If the AS_PATHLIMIT is > > different for different routes, what would be the AS_PATHLIMIT for the > > aggregated route? > > > > I think it should be the minimum of the component routes. > > Hi Vishwas, > > Thank you for your question. > > As you probably surmised, we did not specify that behavior. This is > pretty much intentional, leaving it up to the implementation to > decide what policy it will select by default. > > The propagation of an aggregate may have no relationship to the > desired propagation of the component routes, so manual intervention > is probably the best alternative. For typical aggregates, global > flooding is unlikely to be an issue. The problem that we have is > quite the opposite... global flooding of more specifics. Trading a > number of specifics for one aggregate is a net win. > > Tony > > _______________________________________________ > 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 Jun 10 16:35:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxU6S-0004gu-VD; Sun, 10 Jun 2007 16:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxU6R-0004gk-6P for idr@ietf.org; Sun, 10 Jun 2007 16:33:35 -0400 Received: from nat-eqx.force10networks.com ([69.25.56.27] helo=mx.force10networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxU6P-0005Y6-NM for idr@ietf.org; Sun, 10 Jun 2007 16:33:35 -0400 Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.54]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 10 Jun 2007 13:34:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Jun 2007 13:34:09 -0700 Message-ID: <44ED058B21DF294ABE394CABE5C1B5213FCE66@EXCH-CLUSTER-03.force10networks.com> In-Reply-To: <4668944E.3E965824@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP4 MIBv2 Question Thread-Index: AcepXKL+ccRAOdzyR2Gb0+wkFyxZjACQYzeQ References: <77ead0ec0706071402p48baaa24yef6f17cb1d2e8cd6@mail.gmail.com> <4668944E.3E965824@earthlink.net> From: "Kalpesh Zinjuwadia" To: X-OriginalArrivalTime: 10 Jun 2007 20:34:09.0764 (UTC) FILETIME=[B2E14A40:01C7AB9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: [Idr] BGP4 MIBv2 Question 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: , Content-Type: multipart/mixed; boundary="===============0108675167==" Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0108675167== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AB9E.B2BE3C67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AB9E.B2BE3C67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I had a question regarding the "meshedClient" value of bgpM2PeerReflectorClient in BgpM2PeerReflectorClientEntry entry. How does a route-reflector know whether the RR client is in full-mesh with other clients? Please let me know if I'm missing something. =20 I've pasted the description of this field below. =20 DESCRIPTION "This value indicates whether the given peer is a reflector client of this router, or not. A value of nonClient indicates that this peer is not a reflector client. A value of client indicates that this peer is a reflector client that is not fully meshed with other reflector clients. A value of meshedClient indicates that the peer is a reflector client and is fully meshed with all other reflector clients. =20 This value must be nonClient (0) for BGP external peers." =20 Thanks, Kalpesh ------_=_NextPart_001_01C7AB9E.B2BE3C67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I had a question regarding the = “meshedClient” value of bgpM2PeerReflectorClient in BgpM2PeerReflectorClientEntry entry. How = does a route-reflector know whether the RR client is in full-mesh with other = clients? Please let me know if I’m missing = something.

 

I’ve pasted the description of this field = below.

 

DESCRIPTION
       &nbs= p;    "This value indicates whether the given peer = is a
       &nbs=
p;     reflector client of this router, or =
not.  A value of
       &nbs=
p;     nonClient indicates that this peer is not a =
reflector
       &nbs=
p;     client.  A value of client indicates =
that this peer is a
       &nbs=
p;     reflector client that is not fully meshed =
with other
       &nbs=
p;     reflector clients.  A value of meshedClient =
indicates
     =
;        that the peer is a reflector =
client and is fully =
meshed
     =
;        with all other reflector =
clients.
 
       &nbs=
p;     This value must be nonClient (0) for BGP =
external peers."

 

Thanks,

Kalpesh

------_=_NextPart_001_01C7AB9E.B2BE3C67-- --===============0108675167== 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 --===============0108675167==-- From idr-bounces@ietf.org Sun Jun 10 18:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxVXK-00050L-Ii; Sun, 10 Jun 2007 18:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxVXJ-00050G-6S for idr@ietf.org; Sun, 10 Jun 2007 18:05:25 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxVXI-0006pB-0U for idr@ietf.org; Sun, 10 Jun 2007 18:05:25 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 58C8B4E4A9; Sun, 10 Jun 2007 18:05:23 -0400 (EDT) Date: Sun, 10 Jun 2007 18:05:23 -0400 From: Jeffrey Haas To: Kalpesh Zinjuwadia Subject: Re: [Idr] BGP4 MIBv2 Question Message-ID: <20070610220523.GA5157@scc.mi.org> References: <4668944E.3E965824@earthlink.net> <44ED058B21DF294ABE394CABE5C1B5213FCE66@EXCH-CLUSTER-03.force10networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44ED058B21DF294ABE394CABE5C1B5213FCE66@EXCH-CLUSTER-03.force10networks.com> User-Agent: Mutt/1.5.9i 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 Kalpesh, The same way you know if something is a route-reflector: By configuration. -- Jeff On Sun, Jun 10, 2007 at 01:34:09PM -0700, Kalpesh Zinjuwadia wrote: > Hi all, > > > > I had a question regarding the "meshedClient" value of > bgpM2PeerReflectorClient in BgpM2PeerReflectorClientEntry entry. How > does a route-reflector know whether the RR client is in full-mesh with > other clients? Please let me know if I'm missing something. > -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 12 11:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8Jh-0001TW-TL; Tue, 12 Jun 2007 11:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8Jg-0001TG-2g for idr@ietf.org; Tue, 12 Jun 2007 11:29:56 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8Jd-00086r-1N for idr@ietf.org; Tue, 12 Jun 2007 11:29:56 -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 1Hy8Jb-0005BY-8t for idr@ietf.org; Tue, 12 Jun 2007 17:29:51 +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: Tue, 12 Jun 2007 17:29:50 +0200 Message-ID: <7000E71D8C525042A815432358B2F124B1CCD6@paul.adoffice.local.de.easynet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Thread-Index: AcetBoRVv8ZcIul3S7SF2kqfg89a8A== From: "Ilya Varlashkin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Idr] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.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 Hello all, I realise that now it's too late for significant changes in draft-ietf-idr-rfc3065bis-06.txt, so I send this as standalone message. Currently major implementations disregard length of AS_CONFED_SEQUENCE, and such behaviour documented in step 3 of section 5.3 in draft-ietf-idr-rfc3065bis-06. While MED or community+localpref can be used to alter route preferences where only in-confederation path different, I believe it will be advantageous to consider length of AS_CONFED_SEQUENCE too as this can provide more clear and simple way of choosing optimum route if path length within confederation varies. Possible order for using AS_CONFED_SEQUENCE as tie-breaker could be after MED and before IGP cost, i.e. somewhere between 'c' and 'e' in section 9.1.2.2 of RFC4271). To avoid inconsistency with existing implementation such change in best-path selection could be done via a configuration option with default behaviour being as described in RFC4271 and draft-ietf-idr-rfc3065bis-06. Besides implementation work, are there other reasons not to use AS_CONFED_SEQUENCE length as tie-breaker? Cheers, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 12 16:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD07-0005fR-N7; Tue, 12 Jun 2007 16:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyD06-0005a8-Lo for idr@ietf.org; Tue, 12 Jun 2007 16:30:02 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyD05-0007nP-E0 for idr@ietf.org; Tue, 12 Jun 2007 16:30:02 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 910CD4E4A6; Tue, 12 Jun 2007 16:30:00 -0400 (EDT) Date: Tue, 12 Jun 2007 16:30:00 -0400 From: Jeffrey Haas To: Ilya Varlashkin Subject: Re: [Idr] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Message-ID: <20070612203000.GA1585@scc.mi.org> References: <7000E71D8C525042A815432358B2F124B1CCD6@paul.adoffice.local.de.easynet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7000E71D8C525042A815432358B2F124B1CCD6@paul.adoffice.local.de.easynet.net> User-Agent: Mutt/1.5.9i 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 Ilya, On Tue, Jun 12, 2007 at 05:29:50PM +0200, Ilya Varlashkin wrote: > Besides implementation work, are there other reasons not to use > AS_CONFED_SEQUENCE length as tie-breaker? As long as the tie-breaking is consistent within the AS, it'll work fine. Perhaps a more interesting alternative to AS_PATH length including confederation segments is to use confederation segment length only when non-confederation lengths are comparable. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 12 17:04:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDX5-0003j1-Ie; Tue, 12 Jun 2007 17:04:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDX4-0003io-Ji for idr@ietf.org; Tue, 12 Jun 2007 17:04:06 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDWx-0002cb-5X for idr@ietf.org; Tue, 12 Jun 2007 17:04:06 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 771794E4A7; Tue, 12 Jun 2007 17:03:56 -0400 (EDT) Date: Tue, 12 Jun 2007 17:03:56 -0400 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: [Idr] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Message-ID: <20070612210356.GA27759@scc.mi.org> References: <7000E71D8C525042A815432358B2F124B1CCD6@paul.adoffice.local.de.easynet.net> <20070612203000.GA1585@scc.mi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070612203000.GA1585@scc.mi.org> User-Agent: Mutt/1.5.9i 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 Responding to myself: On Tue, Jun 12, 2007 at 04:30:00PM -0400, Jeffrey Haas wrote: > Ilya, > > On Tue, Jun 12, 2007 at 05:29:50PM +0200, Ilya Varlashkin wrote: > > Besides implementation work, are there other reasons not to use > > AS_CONFED_SEQUENCE length as tie-breaker? > > As long as the tie-breaking is consistent within the AS, it'll work > fine. Perhaps a more interesting alternative to AS_PATH length > including confederation segments is to use confederation segment length > only when non-confederation lengths are comparable. Doing this is usually pretty comparable to your IGP metric and may be useful only when you have disjoint IGP domains. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 12 18:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEZ8-0007Y9-8P; Tue, 12 Jun 2007 18:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEZ7-0007Y4-Cr for idr@ietf.org; Tue, 12 Jun 2007 18:10:17 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEZ6-0001PU-3i for idr@ietf.org; Tue, 12 Jun 2007 18:10:17 -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 1HyEZ5-00007u-5u; Wed, 13 Jun 2007 00:10:15 +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] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Date: Wed, 13 Jun 2007 00:10:13 +0200 Message-ID: <7000E71D8C525042A815432358B2F124B1CCDC@paul.adoffice.local.de.easynet.net> In-Reply-To: <20070612203000.GA1585@scc.mi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Thread-Index: AcetMHq9QhluNhvrSBWSjzs252KelQADKxwg References: <7000E71D8C525042A815432358B2F124B1CCD6@paul.adoffice.local.de.easynet.net> <20070612203000.GA1585@scc.mi.org> From: "Ilya Varlashkin" To: "Jeffrey Haas" 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 Jeff,=20 > -----Original Message----- > On Tue, Jun 12, 2007 at 05:29:50PM +0200, Ilya Varlashkin wrote: > > Besides implementation work, are there other reasons not to use=20 > > AS_CONFED_SEQUENCE length as tie-breaker? >=20 > As long as the tie-breaking is consistent within the AS,=20 > it'll work fine. Perhaps a more interesting alternative to=20 I've encountered practical multi-vendor network scenario where proposed path-selection modification would be benifical. Posting to IETF instead of directly to a single vendor so that feature is consistent between different implementations. Hopefully there are more people on the list who will find this proposal useful. > AS_PATH length including confederation segments is to use=20 > confederation segment length only when non-confederation=20 > lengths are comparable. >=20 Indeed. And that's why I mentioned doing this comparisson after MED and before IGP cost, i.e. at that point non-confed AS-PATH ensured to be equal. Whether it's done before eBGP/iBGP tie-breaking doesn't seem to be essential. Cheers, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 12 18:13:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEcN-0000LS-Ei; Tue, 12 Jun 2007 18:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEcM-0000LN-1u for idr@ietf.org; Tue, 12 Jun 2007 18:13:38 -0400 Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEcK-0002U5-PN for idr@ietf.org; Tue, 12 Jun 2007 18:13:38 -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 1HyEcK-0000Cq-6I; Wed, 13 Jun 2007 00:13:36 +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] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Date: Wed, 13 Jun 2007 00:13:35 +0200 Message-ID: <7000E71D8C525042A815432358B2F124B1CCDD@paul.adoffice.local.de.easynet.net> In-Reply-To: <20070612210356.GA27759@scc.mi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] BGP best-path selection in confederations (draft-ietf-idr-rfc3065bis-06.txt) Thread-Index: AcetNTOLeO6uSIPZQzK8k4NSyOQMEAACU++w References: <7000E71D8C525042A815432358B2F124B1CCD6@paul.adoffice.local.de.easynet.net> <20070612203000.GA1585@scc.mi.org> <20070612210356.GA27759@scc.mi.org> From: "Ilya Varlashkin" To: "Jeffrey Haas" 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 > -----Original Message----- > > As long as the tie-breaking is consistent within the AS, it'll work=20 > > fine. Perhaps a more interesting alternative to AS_PATH length=20 > > including confederation segments is to use confederation segment=20 > > length only when non-confederation lengths are comparable. >=20 > Doing this is usually pretty comparable to your IGP metric=20 > and may be useful only when you have disjoint IGP domains. >=20 That's exactly the case - each member AS runs its own IGP and I'm not aware of any implementation that currently can _add_ IGP cost to MED, only overriding MED with IGP cost, which may create incomparable MED's. /iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 01:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyhTb-0004la-8O; Thu, 14 Jun 2007 01:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyhTY-0004bt-Nb for idr@ietf.org; Thu, 14 Jun 2007 01:02:28 -0400 Received: from [202.96.99.56] (helo=mailgate.zjgsu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyhTW-0000gq-V4 for idr@ietf.org; Thu, 14 Jun 2007 01:02:28 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 50203.1893313773; Tue, 12 Jun 2007 12:50:42 +0800 (CST) Received: from jiafenggen (nat.zjgsu.edu.cn [202.96.99.60]) by mail.zjgsu.edu.cn (Postfix) with SMTP id 888D81140496 for ; Thu, 14 Jun 2007 12:58:32 +0800 (CST) Date: Thu, 14 Jun 2007 13:01:47 +0800 From: "Fenggen Jia" To: "idr" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20070614045832.888D81140496@mail.zjgsu.edu.cn> X-Spam-Score: 4.1 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Idr] why has 4096 bytes limit on BGP messages size? 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,all, I am wondering why BGP has 4096 bytes limit on all its messages,should we leave it to the implementator to decide,thanks! Yours,Fenggen _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 02:25:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyilK-0005lP-NG; Thu, 14 Jun 2007 02:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyilJ-0005lJ-TF for idr@ietf.org; Thu, 14 Jun 2007 02:24:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyilI-0004Be-JS for idr@ietf.org; Thu, 14 Jun 2007 02:24:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2007 23:24:52 -0700 X-IronPort-AV: i="4.16,419,1175497200"; d="scan'208"; a="164898499:sNHT63853533" 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/8.12.11) with ESMTP id l5E6Oqo7006780; Wed, 13 Jun 2007 23:24:52 -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 l5E6OpaI005006; Thu, 14 Jun 2007 06:24:51 GMT 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.1830); Wed, 13 Jun 2007 23:24:51 -0700 Received: from [192.168.0.100] ([10.21.118.39]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 23:24:51 -0700 In-Reply-To: <20070614045832.888D81140496@mail.zjgsu.edu.cn> References: <20070614045832.888D81140496@mail.zjgsu.edu.cn> Mime-Version: 1.0 (Apple Message framework v752.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? Date: Wed, 13 Jun 2007 23:24:50 -0700 To: Fenggen Jia X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 06:24:51.0395 (UTC) FILETIME=[B6FA4130:01C7AE4C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=367; t=1181802292; x=1182666292; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20why=20has=204096=20bytes=20limit=20on=20BGP=2 0messages=20size? |Sender:=20; bh=R5XrVDkf9T1ByV7zBe8UNz2sevPbnJijfd//On6lzTA=; b=Ctp8GJRTyOT+OVzcrslBUyr6wcxOqrjQ0RYmVqM2x6EEidrelesPR8O/7jPgONnS4S7ghHjP 95h3I0LQc7EC6N+8VcdbP/iCeiRh7fMuKe8JFcdeDXksgGKQ5LfNskFfAkGEDTZKs7m8V5YnNv JY4s8CWcNH1kNMZRuUA1sDcYs=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: idr 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 Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote: > hi,all, > I am wondering why BGP has 4096 bytes limit on all its > messages,should we leave it to the implementator to decide,thanks! Well, the problem with that is that a sender could then create an arbitrarily long message, which could be arbitrarily problematic for a receiver. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 06:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyn2b-0002ZN-33; Thu, 14 Jun 2007 06:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyn2a-0002ZE-1A for idr@ietf.org; Thu, 14 Jun 2007 06:59:00 -0400 Received: from [202.96.99.56] (helo=mailgate.zjgsu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyn2V-0007tm-Th for idr@ietf.org; Thu, 14 Jun 2007 06:58:59 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 50203.2516453744; Tue, 12 Jun 2007 18:47:01 +0800 (CST) Received: from jiafenggen (nat.zjgsu.edu.cn [202.96.99.60]) by mail.zjgsu.edu.cn (Postfix) with SMTP id 9C6C11140496; Thu, 14 Jun 2007 18:54:51 +0800 (CST) Date: Thu, 14 Jun 2007 18:58:06 +0800 From: "Fenggen Jia" To: "idr" Subject: Re: Re: [Idr] why has 4096 bytes limit on BGP messages size? X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> X-Spam-Score: 4.1 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tli 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 Then why not other limit,how is 4096 bytes derived, thanks.BTW,whether it's a good pratice in protocol devise to limit message sizes?I see in ripV1 that the maximum PDU length is 576bytes its reason is to avoid IP fragmentation,but in ripng the PDU length is determined only by the link MTU,and in snmp i also doesn't see the message size limit. Yours,Fenggen > >On Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote: > >> hi,all, >> I am wondering why BGP has 4096 bytes limit on all its >> messages,should we leave it to the implementator to decide,thanks! > > >Well, the problem with that is that a sender could then create an >arbitrarily long message, which could be arbitrarily problematic for >a receiver. > >Tony > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 09:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hypll-0003FB-Jk; Thu, 14 Jun 2007 09:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyplk-0003F6-Nl for idr@ietf.org; Thu, 14 Jun 2007 09:53:48 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyplj-0003sH-H4 for idr@ietf.org; Thu, 14 Jun 2007 09:53:48 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 0E2C14E4A2; Thu, 14 Jun 2007 09:53:40 -0400 (EDT) Date: Thu, 14 Jun 2007 09:53:40 -0400 From: Jeffrey Haas To: Fenggen Jia Subject: Re: Re: [Idr] why has 4096 bytes limit on BGP messages size? Message-ID: <20070614135339.GA10519@scc.mi.org> References: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr 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, Jun 14, 2007 at 06:58:06PM +0800, Fenggen Jia wrote: > Then why not other limit,how is 4096 bytes derived, thanks. It wouldn't shock me if it had to do with the MTU of a FDDI link but that's complete speculation. Aside from the 4k limit, here's some things to keep in mind when writing protocols. Mostly IMO: - Messages encoded in some sort of TLV format probably need a full PDU kept in memory at the same time. This is because a sane implementation will validate the PDU contents against TLV constraints (either implied by the TLV or by the protocol) before doing *anything* to it. - Having a fixed sized buffer means you can allocate it *once* and be done with it. - You're going to have one of these buffers for each of your peering sessions. You don't want it to be large. - You want the PDU to be "big enough" to be able to transport your information usefully. If you're regularly exceeding a 4K message in BGP, you're probably not passing around Internet reachability. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 11:50:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyraq-0001dZ-4C; Thu, 14 Jun 2007 11:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyrao-0001cC-NH for idr@ietf.org; Thu, 14 Jun 2007 11:50:38 -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 1Hyran-0002lJ-CE for idr@ietf.org; Thu, 14 Jun 2007 11:50:38 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2007 08:50:37 -0700 X-IronPort-AV: i="4.16,421,1175497200"; d="scan'208"; a="379546835:sNHT45852332" 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/8.12.11) with ESMTP id l5EFoa3p019938; Thu, 14 Jun 2007 08:50:36 -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 l5EFoVaI009556; Thu, 14 Jun 2007 15:50:31 GMT 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, 14 Jun 2007 08:50:31 -0700 Received: from [10.21.70.203] ([10.21.70.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 08:50:31 -0700 Message-ID: <467163D3.7000101@cisco.com> Date: Thu, 14 Jun 2007 08:50:43 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fenggen Jia Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? References: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> In-Reply-To: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2007 15:50:31.0297 (UTC) FILETIME=[BCBC4F10:01C7AE9B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1328; t=1181836236; x=1182700236; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20why=20has=204096=20bytes=20limit=20on=20BGP=2 0messages=20size? |Sender:=20; bh=IYnM5RCejw6lTaBjRKAcYWs5WbpS6Iq4ew8yHfFEWdE=; b=GgO5xBJ8ZFeFZQmIZzCb3Q3nCgSSAZpT4ICtecH4kpjxtzopCVeuoco98hu1kBo3IMAOvI2l RORztfpzbnlSDexDpn7vrNJVgcLempxQfFb/lwdL8836w4Z6opzeGWps; Authentication-Results: sj-dkim-3; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tli , idr 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 Fenggen Jia wrote: > Then why not other limit,how is 4096 bytes derived, thanks.BTW,whether it's a good pratice in protocol devise to limit message sizes? Do not know the precise reason for the number. I suspect that it's chosen as it's large enough. It turns out to be a good number - it has certainly withstood the test of time. If there is ever a legitimate need to increase the limit in the future, that can be done easily with the capability advertisement from the protocol perspective. -- Enke > I see in ripV1 that the maximum PDU length is 576bytes its reason is to avoid IP fragmentation,but in ripng the PDU length is determined only by the link MTU,and in snmp i also doesn't see the message size limit. > Yours,Fenggen > >> On Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote: >> >> >>> hi,all, >>> I am wondering why BGP has 4096 bytes limit on all its >>> messages,should we leave it to the implementator to decide,thanks! >>> >> Well, the problem with that is that a sender could then create an >> arbitrarily long message, which could be arbitrarily problematic for >> a receiver. >> >> Tony >> >> > > > > > _______________________________________________ > 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 Jun 14 12:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyrk4-0004wG-FX; Thu, 14 Jun 2007 12:00:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyrjv-0004tm-8N for idr@ietf.org; Thu, 14 Jun 2007 12:00:03 -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 1Hyrjt-0004lo-L5 for idr@ietf.org; Thu, 14 Jun 2007 12:00:03 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5EFxlfP028454; Thu, 14 Jun 2007 18:59:47 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5EFxlGj028451; Thu, 14 Jun 2007 18:59:47 +0300 Date: Thu, 14 Jun 2007 18:59:47 +0300 (EEST) From: Pekka Savola To: Tony Li Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-Reply-To: Message-ID: References: <20070614045832.888D81140496@mail.zjgsu.edu.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3413/Wed Jun 13 17:37:22 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: idr 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, 13 Jun 2007, Tony Li wrote: > On Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote: >> hi,all, >> I am wondering why BGP has 4096 bytes limit on all its >> messages,should we leave it to the implementator to decide,thanks! > > > Well, the problem with that is that a sender could then create an arbitrarily > long message, which could be arbitrarily problematic for a receiver. While this is an interesting historical perspective, I'm not sure how relevant it is anymore. How does BGP differ from other TCP applications (almost none of which specify the maximum byte limit in the application)? Are routers so low-end that they cannot allocate more than 4K memory per message, or that they cannot determine the amount of memory to allocate depending on the message length? :-) (The header fields already tell the length of the message, so allocating 4K buffer for each BGP message (when most messages are much smaller than 4K) is probably a waste in many cases.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 14:28:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu33-0008J4-K0; Thu, 14 Jun 2007 14:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu32-0008In-MR for idr@ietf.org; Thu, 14 Jun 2007 14:27:56 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyu30-00040P-BW for idr@ietf.org; Thu, 14 Jun 2007 14:27:56 -0400 Received: by wa-out-1112.google.com with SMTP id j5so908008wah for ; Thu, 14 Jun 2007 11:27:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gm6dxBea/tClT3XyXW3Yia0kfvqOg53v3mhIBVgsnfBvBP/U+A3qjFbK9L5ajIvWYTVN8CsUCgFA7mt/LX8MTnJ4EleyB6+JLKdcZPDK61NqpB4OXxLhEnNLX7Py5e3wWqWgBa+DjsynFIaxWXljS+RJ28Y8jJClQURIPNTwfog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m+jXOT6CoBzmraxB9KJf/E2ghef+SwZv0V0TpgSTp8aLG78UBWR4bw+GIvp1ZxtEWNG/yw2NeC2Nrd0XwJSV4+w09t1xiWnSwRDm09y9l1m9gQQtJeuA/MBShskV2lzTWHn8tBmCT7DMYcdG1efHpWIixes37pQyA9BCGbT41tA= Received: by 10.114.106.1 with SMTP id e1mr2121249wac.1181845673287; Thu, 14 Jun 2007 11:27:53 -0700 (PDT) Received: by 10.114.154.5 with HTTP; Thu, 14 Jun 2007 11:27:53 -0700 (PDT) Message-ID: <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> Date: Thu, 14 Jun 2007 11:27:53 -0700 From: "Vishwas Manral" To: "Jeffrey Haas" Subject: Re: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-Reply-To: <20070614135339.GA10519@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: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> <20070614135339.GA10519@scc.mi.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: idr 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 Jeff, I had a few doubts. > - Messages encoded in some sort of TLV format probably need a full PDU > kept in memory at the same time. This is because a sane > implementation will validate the PDU contents against TLV constraints > (either implied by the TLV or by the protocol) before doing *anything* > to it. Are you saying keeping/ allocating a PDU bigger than 4k bytes is a problem? > - Having a fixed sized buffer means you can allocate it *once* and be > done with it. If I remember correctly what glibc does, it does not make a brk system call everytime, it itself keeps a pool of memory, and does not give it back to the OS. I think allocating a few buffers of different sizes for such a design would help. > - You're going to have one of these buffers for each of your peering > sessions. You don't want it to be large. Its again a memory management issue of an implementation right. We could allocate a central pool and extract memory from there. Thanks, Vishwas On 6/14/07, Jeffrey Haas wrote: > On Thu, Jun 14, 2007 at 06:58:06PM +0800, Fenggen Jia wrote: > > Then why not other limit,how is 4096 bytes derived, thanks. > > It wouldn't shock me if it had to do with the MTU of a FDDI link but > that's complete speculation. > > Aside from the 4k limit, here's some things to keep in mind when writing > protocols. Mostly IMO: > - Messages encoded in some sort of TLV format probably need a full PDU > kept in memory at the same time. This is because a sane > implementation will validate the PDU contents against TLV constraints > (either implied by the TLV or by the protocol) before doing *anything* > to it. > - Having a fixed sized buffer means you can allocate it *once* and be > done with it. > - You're going to have one of these buffers for each of your peering > sessions. You don't want it to be large. > - You want the PDU to be "big enough" to be able to transport your > information usefully. If you're regularly exceeding a 4K message in > BGP, you're probably not passing around Internet reachability. > > -- 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 Thu Jun 14 18:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxlB-00011y-4d; Thu, 14 Jun 2007 18:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxlA-00011t-HK for idr@ietf.org; Thu, 14 Jun 2007 18:25:44 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyxl8-0001nI-3z for idr@ietf.org; Thu, 14 Jun 2007 18:25:44 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=K4U7gWWeO0v1CnRYNpjX2TPlLh/iwGSnp3ds/SACdLdK79revNpeV6KxuagxVy6g; 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.92.78] (helo=earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hyxl6-0006I2-Qi; Thu, 14 Jun 2007 18:25:41 -0400 Message-ID: <4671C047.FFB88AAA@earthlink.net> Date: Thu, 14 Jun 2007 15:25:11 -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: Vishwas Manral Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? References: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> <20070614135339.GA10519@scc.mi.org> <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec793e84ad32fffc3f1b494aed9a4b1fc330350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.92.78 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: idr 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 Group, If one decided to pre-allocate fix buffer sizes, then.. What is wrong with a pre-allocating a buffer size of say 128bytes and assume that it will cover 90+% of your needs and on the other 10% of the time, allocate a buffer larger on demand?? I believe this is legacy.. However, if one likes to look at memory allocators then the "Slab Allocator" would be one I would suggest to look at first. Mitchell Erblich ---------------- Vishwas Manral wrote: > > Hi Jeff, > > I had a few doubts. > > > - Messages encoded in some sort of TLV format probably need a full PDU > > kept in memory at the same time. This is because a sane > > implementation will validate the PDU contents against TLV constraints > > (either implied by the TLV or by the protocol) before doing *anything* > > to it. > Are you saying keeping/ allocating a PDU bigger than 4k bytes is a problem? > > > - Having a fixed sized buffer means you can allocate it *once* and be > > done with it. > If I remember correctly what glibc does, it does not make a brk system > call everytime, it itself keeps a pool of memory, and does not give it > back to the OS. I think allocating a few buffers of different sizes > for such a design would help. > > > - You're going to have one of these buffers for each of your peering > > sessions. You don't want it to be large. > Its again a memory management issue of an implementation right. We > could allocate a central pool and extract memory from there. > > Thanks, > Vishwas > > On 6/14/07, Jeffrey Haas wrote: > > On Thu, Jun 14, 2007 at 06:58:06PM +0800, Fenggen Jia wrote: > > > Then why not other limit,how is 4096 bytes derived, thanks. > > > > It wouldn't shock me if it had to do with the MTU of a FDDI link but > > that's complete speculation. > > > > Aside from the 4k limit, here's some things to keep in mind when writing > > protocols. Mostly IMO: > > - Messages encoded in some sort of TLV format probably need a full PDU > > kept in memory at the same time. This is because a sane > > implementation will validate the PDU contents against TLV constraints > > (either implied by the TLV or by the protocol) before doing *anything* > > to it. > > - Having a fixed sized buffer means you can allocate it *once* and be > > done with it. > > - You're going to have one of these buffers for each of your peering > > sessions. You don't want it to be large. > > - You want the PDU to be "big enough" to be able to transport your > > information usefully. If you're regularly exceeding a 4K message in > > BGP, you're probably not passing around Internet reachability. > > > > -- 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 18:37:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxwD-00075r-Ai; Thu, 14 Jun 2007 18:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxwC-00075m-3g for idr@ietf.org; Thu, 14 Jun 2007 18:37:08 -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 1HyxwA-0003tA-QM for idr@ietf.org; Thu, 14 Jun 2007 18:37:08 -0400 Received: from [192.168.1.7] (VDSL-151-118-149-96.DNVR.QWEST.NET [151.118.149.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 690E76434E; Thu, 14 Jun 2007 15:37:07 -0600 (MDT) In-Reply-To: <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> References: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> <20070614135339.GA10519@scc.mi.org> <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D5A1AAC-03A5-468B-8D56-9FE5818BF5A0@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? Date: Thu, 14 Jun 2007 16:36:52 -0600 To: idr X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 RFC 1105 the maximum message size was 1024 octets. I suspect because RFC 1163 added the capability to support multiple prefixes (i.e., compression/update packing) they bumped the size to 4096. Note that RFC 1163's Appendix 2 states the UPDATE format was changed to support multiple "path attributes", when I think they actually meant multiple "prefixes". As for why it was constrained in the first place, RFC 1164 talks to this a bit in section 6.3. In particular, I suspect the size was constrained initially because of this: Due to the stream nature of TCP, all the data for received messages does not necessarily arrive at the same time [...] This can make it difficult to process the data as messages, especially on systems such as BSD Unix where it is not possible to determine how much data has been received but not yet processed. One might hypothesize that the selection of the original value of 1024 had something to the 4.2 BSD-derived systems TCP segment size common settings of 1024. RFC 1267 incorporated some of the RFC 1164 text directly, in section 5.2. Of course, I'm just a youngster compared to some of the old folk here, especially Yakov, so I'll happily defer ;-) -danny --- RFC 1267 5.2 Processing Messages on a Stream Protocol BGP uses TCP as a transport mechanism. Due to the stream nature of TCP, all the data for received messages does not necessarily arrive at the same time. This can make it difficult to process the data as messages, especially on systems such as BSD Unix where it is not possible to determine how much data has been received but not yet processed. One method that can be used in this situation is to first try to read just the message header. For the KEEPALIVE message type, this is a complete message; for other message types, the header should first be verified, in particular the total length. If all checks are successful, the specified length, minus the size of the message header is the amount of data left to read. An implementation that would "hang" the routing information process while trying to read from a peer could set up a message buffer (4096 bytes) per peer and fill it with data as available until a complete message has been received. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 18:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyxzl-000164-Q8; Thu, 14 Jun 2007 18:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyxzk-00015z-Sk for idr@ietf.org; Thu, 14 Jun 2007 18:40:48 -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 1Hyxzi-0004cu-Jc for idr@ietf.org; Thu, 14 Jun 2007 18:40:48 -0400 Received: from [192.168.1.7] (VDSL-151-118-149-96.DNVR.QWEST.NET [151.118.149.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 6797764388; Thu, 14 Jun 2007 15:40:46 -0600 (MDT) In-Reply-To: References: <20070614045832.888D81140496@mail.zjgsu.edu.cn> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75E42991-5683-422A-89AD-733A11CEF6EE@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? Date: Thu, 14 Jun 2007 16:40:31 -0600 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: idr List Routing 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 Jun 14, 2007, at 9:59 AM, Pekka Savola wrote: > > (The header fields already tell the length of the message, so > allocating 4K buffer for each BGP message (when most messages are > much smaller than 4K) is probably a waste in many cases.) Pekka, Do you have some references to data supporting your comment here regarding most messages being smaller than 4K? -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 14 19:00:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyyIY-0006hJ-L3; Thu, 14 Jun 2007 19:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyyIX-0006h6-ED for idr@ietf.org; Thu, 14 Jun 2007 19:00:13 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyyIU-00015N-FV for idr@ietf.org; Thu, 14 Jun 2007 19:00:13 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dj4jndvhe2iiBsnFeYqwTPtkGAk/rOet0L2O0fuOxkYtxVTyIXS+FdY6Kgzkmb9E; 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.92.78] (helo=earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HyyIT-0008Ep-KT; Thu, 14 Jun 2007 19:00:09 -0400 Message-ID: <4671C82D.2DEE5F08@earthlink.net> Date: Thu, 14 Jun 2007 15:58:53 -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: Danny McPherson Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? References: <20070614105451.9C6C11140496@mail.zjgsu.edu.cn> <20070614135339.GA10519@scc.mi.org> <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> <0D5A1AAC-03A5-468B-8D56-9FE5818BF5A0@tcb.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79575ba6a1e7d36a8b69bf89a22e0b43d6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.92.78 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: idr 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 Danny McPherson, eta al, Let me take a stab at this, but do your own investigation.. IMO, one item is due to the use of TCP by BGP. After one RTO timeout, most implimentations use a slow-start after idle. To preserve TCP's fast transmit and power of two mem allocation the stardard link's MTU is 1.5K, times four with a reduction to the closest power of two, thus 4K. Oh, and the recieve window size is normally 4 x MTU which is then capped at 6K for slow-start. Mitchell Erblich ---------------- Danny McPherson wrote: > > In RFC 1105 the maximum message size was 1024 octets. I suspect > because RFC 1163 added the capability to support multiple prefixes > (i.e., compression/update packing) they bumped the size to 4096. Note > that RFC 1163's Appendix 2 states the UPDATE format was changed > to support multiple "path attributes", when I think they actually meant > multiple "prefixes". > > As for why it was constrained in the first place, RFC 1164 talks to this > a bit in section 6.3. In particular, I suspect the size was constrained > initially because of this: > > Due to the stream nature of TCP, all the data for received messages > does not necessarily arrive at the same time > [...] > This can make it difficult to process the data as messages, > especially on systems such as BSD Unix where it is not possible to > determine how much data has been received but not yet processed. > > One might hypothesize that the selection of the original value of 1024 > had something to the 4.2 BSD-derived systems TCP segment size > common settings of 1024. > > RFC 1267 incorporated some of the RFC 1164 text directly, in section > 5.2. > > Of course, I'm just a youngster compared to some of the old folk here, > especially Yakov, so I'll happily defer ;-) > > -danny > > --- > RFC 1267 > > 5.2 Processing Messages on a Stream Protocol > > BGP uses TCP as a transport mechanism. Due to the stream nature of > TCP, all the data for received messages does not necessarily arrive > at the same time. This can make it difficult to process the data as > messages, especially on systems such as BSD Unix where it is not > possible to determine how much data has been received but not yet > processed. > > One method that can be used in this situation is to first try to > read > just the message header. For the KEEPALIVE message type, this is a > complete message; for other message types, the header should > first be > verified, in particular the total length. If all checks are > successful, the specified length, minus the size of the message > header is the amount of data left to read. An implementation that > would "hang" the routing information process while trying to read > from a peer could set up a message buffer (4096 bytes) per peer and > fill it with data as available until a complete message has been > received. > > _______________________________________________ > 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 Jun 15 01:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz47d-0006ph-BC; Fri, 15 Jun 2007 01:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz47b-0006pW-1H for idr@ietf.org; Fri, 15 Jun 2007 01:13:19 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz47a-0004UP-Gh for idr@ietf.org; Fri, 15 Jun 2007 01:13:19 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5F5E1bw001879; Fri, 15 Jun 2007 01:14:01 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706150514.l5F5E1bw001879@sailbum.orleans.occnc.com> To: Pekka Savola From: Curtis Villamizar Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-reply-to: Your message of "Thu, 14 Jun 2007 18:59:47 +0300." Date: Fri, 15 Jun 2007 01:14:01 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Tony Li , idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message Pekka Savola writes: > > On Wed, 13 Jun 2007, Tony Li wrote: > > On Jun 13, 2007, at 10:01 PM, Fenggen Jia wrote: > >> hi,all, > >> I am wondering why BGP has 4096 bytes limit on all its > >> messages,should we leave it to the implementator to decide,thanks! > > > > > > Well, the problem with that is that a sender could then create an arbitrarily > > long message, which could be arbitrarily problematic for a receiver. > > While this is an interesting historical perspective, I'm not sure how > relevant it is anymore. How does BGP differ from other TCP > applications (almost none of which specify the maximum byte limit in > the application)? Are routers so low-end that they cannot allocate > more than 4K memory per message, or that they cannot determine the > amount of memory to allocate depending on the message length? :-) > > (The header fields already tell the length of the message, so > allocating 4K buffer for each BGP message (when most messages are much > smaller than 4K) is probably a waste in many cases.) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Just from an efficiency standpoint it makes sense to read much more than 4KB from the BGP socket. If the router is busy, having a 16KB or larger read buffer lets TCP do its thing more efficiently. You then typically get N BGP updates plus some fraction of an update which has to be shuffled in the buffer and another large read issued. If the most you have to shuffle is 4KB that might be a good thing. Less system calls is generally better favoring big reads though it depends on the OS. This tends to matter when a big routing transient happens. Older very memory challenged implementations may have allocated 4KB and did a small read to get the header and then another read to get the rest of the update but that can be fairly inefficient. Back when BGP was invented some routers had 4MB or less and a 68020 or worse (a PC-RT). 4KB is big enough that the overhead of parsing the header and the attributes more than once when a large number of prefixes have the same attributes is not a big penalty. That is something that anyone doing an implementation could verify or dispute after doing a program execution profile. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 15 01:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4Ed-0007Wt-Ij; Fri, 15 Jun 2007 01:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4Eb-0007WC-4H for idr@ietf.org; Fri, 15 Jun 2007 01:20:33 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4EZ-000627-MY for idr@ietf.org; Fri, 15 Jun 2007 01:20:33 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5F5LAM9001940; Fri, 15 Jun 2007 01:21:10 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706150521.l5F5LAM9001940@sailbum.orleans.occnc.com> To: "Vishwas Manral" From: Curtis Villamizar Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-reply-to: Your message of "Thu, 14 Jun 2007 11:27:53 PDT." <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> Date: Fri, 15 Jun 2007 01:20:50 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr 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 <77ead0ec0706141127i61017d2av74151c7dd4004044@mail.gmail.com> "Vishwas Manral" writes: > > Its again a memory management issue of an implementation right. We > could allocate a central pool and extract memory from there. > > Thanks, > Vishwas Yes and no. Dynamic allocation is a wonderful thing but you have to allocate memory and post a read on every BGP session simultaneously. There is no way to know which one will have updates to send next. You should post a big enough read that TCP and your BGP implementation can operate efficiently if you instantaneously go from quiescent to a torrent of BGP updates. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 15 01:35:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4TN-0005A1-Nd; Fri, 15 Jun 2007 01:35:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4TL-0004zW-UD for idr@ietf.org; Fri, 15 Jun 2007 01:35:47 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4TL-0000Qh-CC for idr@ietf.org; Fri, 15 Jun 2007 01:35:47 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5F5ac3M002110; Fri, 15 Jun 2007 01:36:38 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706150536.l5F5ac3M002110@sailbum.orleans.occnc.com> To: Danny McPherson From: Curtis Villamizar Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-reply-to: Your message of "Thu, 14 Jun 2007 16:36:52 MDT." <0D5A1AAC-03A5-468B-8D56-9FE5818BF5A0@tcb.net> Date: Fri, 15 Jun 2007 01:36:37 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: idr 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 <0D5A1AAC-03A5-468B-8D56-9FE5818BF5A0@tcb.net> Danny McPherson writes: > > In RFC 1105 the maximum message size was 1024 octets. I suspect > because RFC 1163 added the capability to support multiple prefixes > (i.e., compression/update packing) they bumped the size to 4096. Note > that RFC 1163's Appendix 2 states the UPDATE format was changed > to support multiple "path attributes", when I think they actually meant > multiple "prefixes". > > As for why it was constrained in the first place, RFC 1164 talks to this > a bit in section 6.3. In particular, I suspect the size was constrained > initially because of this: > > Due to the stream nature of TCP, all the data for received messages > does not necessarily arrive at the same time > [...] > This can make it difficult to process the data as messages, > especially on systems such as BSD Unix where it is not possible to > determine how much data has been received but not yet processed. > > One might hypothesize that the selection of the original value of 1024 > had something to the 4.2 BSD-derived systems TCP segment size > common settings of 1024. > > RFC 1267 incorporated some of the RFC 1164 text directly, in section > 5.2. > > Of course, I'm just a youngster compared to some of the old folk here, > especially Yakov, so I'll happily defer ;-) > > -danny Danny, The code back then in rcp_routed and gated, the research reference implementations (and running code on the NSFNET), was not written by experts in BSD socket programming. The code had problems with partial reads of a BGP update and had even more trouble with a block on the write (just gave up and reset the BGP session). It did sort of work though and implementations have gotten better. Anyway, we still get lots of prefixes into a BGP update so unless there is some motivation to increase the 4KB update size limit why bother? Maybe it would be more efficient to collect up all the prefix changes with a common set of attributes and send the whole thing no matter how big. If so, lets continue the conversation when someone has strong evidence that this is the case. Until then... Regards, Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 15 01:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4fH-0005io-Se; Fri, 15 Jun 2007 01:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4fH-0005gY-CQ for idr@ietf.org; Fri, 15 Jun 2007 01:48:07 -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 1Hz4fG-00048s-8I for idr@ietf.org; Fri, 15 Jun 2007 01:48:07 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5F5m2bf013614; Fri, 15 Jun 2007 08:48:02 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5F5m2U1013611; Fri, 15 Jun 2007 08:48:02 +0300 Date: Fri, 15 Jun 2007 08:48:02 +0300 (EEST) From: Pekka Savola To: Danny McPherson Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-Reply-To: <75E42991-5683-422A-89AD-733A11CEF6EE@tcb.net> Message-ID: References: <20070614045832.888D81140496@mail.zjgsu.edu.cn> <75E42991-5683-422A-89AD-733A11CEF6EE@tcb.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1242171243-1181886482=:12496" X-Virus-Scanned: ClamAV 0.90.3/3422/Fri Jun 15 03:34:17 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: idr List Routing 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1242171243-1181886482=:12496 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 14 Jun 2007, Danny McPherson wrote: > On Jun 14, 2007, at 9:59 AM, Pekka Savola wrote: >> (The header fields already tell the length of the message, so allocating 4K >> buffer for each BGP message (when most messages are much smaller than 4K) >> is probably a waste in many cases.) > > Pekka, > Do you have some references to data supporting your comment here > regarding most messages being smaller than 4K? Yes. I've sometimes taken debugs logs of BGP when a DFZ table flapped and looked at the packets. Here's a plot of BGP Update size versus occurrences (in this about 10-15min trace, 87K BGP updates). BGP Updates are sent by a Juniper T-series router. The smallest is 26B, the largest 4095B. Top 20 sizes (6995 through 1229 occurrences) are all between 58 and 95 bytes. (Not sure if the small attachment gets on the list, but if not, I'll post it somewhere.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1242171243-1181886482=:12496 Content-Type: APPLICATION/pdf; name=bgp-update-sizes.pdf Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=bgp-update-sizes.pdf JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO2dTc4tuW/e572KC4+SgW8kiqSk DANkAU7+GzAcx3DgG8R2DANZfapEUsVH8qTbIwNGo7vFU/odSRQpUR913r// UX7WH+X9x///V79++/vf/tN/4x9/84+/1fLjn3+rP/72NyEtPyox/fjl6Vbk x99ZurPuz3ubMz6vVcbz+X//7e9/1FVC/O+vfv34L396ypg/6o8//c/fns/5 x58//5Yf0spPfbLxz6ewH3/69dt/+FH/45/+12//9U8//uJfWQmeTwlOe7q3 J9dKO+3pVt/Pe6Wd39KW/01HfktbftG581va8r/pyG9py89PxSK/pS3/m478 lrb8TfvOb2nL/6Yjv6UtP82tLU9b/jcd+S3t+al9+Vfa8z/pnX+lLX9V2fkt bfnfdOS3tOdP+lxp672V3vnftPWe5fn9JsRVfo4fU3+2MKCyLejfbeDfsg20 rhq0p1dpK+20p1dpTXT3tqct/5uO/Ja2/Ex157e05X/Tkd/Slr/VrV1PW/43 HfktbfmpbuvwtOV/05Hf0pa/8taWpy3/m478lrb8pe/e8LTlf9OR39Kev/Yv f+1f/tq//HVbE81Pn5a23ltpz29p6z3L8/s9+Cnzxxg/RbSGB38u/O9G8G/Z CEjrHvA8vUpb6aAtbaU9o8fOb2nL/6Yjv6Ut//s48lva8r//i/yWtvxVt3Y9 bfnfdOS3tOUvfVuHpy3/m478ll7565xbW55e+Vfa83va81P/8lP/8lP/8tPu jTq+CcfTln98E46nPf+nT0tb7630zv+mrfcsz+934afMn/RjlJ+90+fEnxf/ ux38W7aDyn2PeZ620t500Ja20kh3b3va8r/pyG9py19pj2GetvxvOvJb2vKX L6zztOUvX1jn6ZV/flHO/IKc+cU48wtxBm9FWXLlfZOe15Irb++7Eyy58r5J z2tJy/tNM/2bZfo3yfRvjtFPfStpfaWf8lbSempl+P0O2+vPRz30c46R/PVz 2H/v8n8jXQ6L5Dp9FIEv7K3Gp8Jl5/5d63Tmd51ex8/21GbZS/mX1+m/swrG ztY2+6adtY8Xa58aax//ger3+VP7sOpLORvwxyqxWFLiYFfaWP/4Zf3TxfrH v78B9Px3DP0X5td/TS0W+4SsEuxKG+sfv6x/ulj/+Pe3oNX2DDnRgqsP/mAt Fvt8osGutLH+8cv6p4v1j/9AC0b7WaIFdPXBH6yFsTrHZt+0s/bxYu1TY+3j 398CFvpJuwVXH/zBWixW2pjBrrSx/vHL+qeL9Y9/fwuE6s8WLWhXH/zBWixW yyjBrrSx/vHL+qeL9Y//QAtm+cm7BVcf/MFaGNufMDTYN+2sfbxY+9RY+/j3 t0Bl/pRoAV998AdrAVu7L7vSMBG+rH+6WP/497eg0/ipuwVXH/zBWuxJj2XS DyUqP/7hr39X7Qb/fDxvzp9TbEfzz/7p//yPv/y/f/3n//i3/++v//Hnk/zL P/vxT//4t//7b37Qf0675T/++bfR+88nlGrc36ilcgh/91RghTbPiPlTIs5p ffyU9Wy2urLKa0dDRwjr2TvbtToWZ8KowU3LSiuiahLCera2Kx87X9wrNGnO 1SJWIK2HY4RgD+kNEGZbpElNdKPdmiXNQr4akj3l9n5TdXZJg4Ol0iz3elq5 hLSe1v5uUJKXa9LY5ZKXRMPYEZKxY9VZnR2rzjPY1rykYWFwD8m++Ynqnm9y 1qSRWCuJeT3tEpI9La9iKxlr0spiT7uVq+xPQ/JvfktqwS5pfuyw9mpdT+sI yZ7K20Kazi5pUrBMlruV9VQlJGNXiDiHs6/0fO9mh/XRiq+ebyoh2VNZm8je vyYpf6yVpGosheTsu3vVONhXmn2z0+yqzfXUPaJNf6qvJS0F/gppKXc9le7t XeVKlZDsKb8tLF6uSbrLlWHl6ipXqIZkT+UtqXm5S3qGm2Cfkd+sgeybJSSv 1bKN4uyS+nbBZ+GxctdVro4Skj1dG/fDy13S08kfa3XuZGwNydm3zlyCXXX+ ynVv7/aUJCR7Km8t2X1wSVy2Dw63jf6Ob3W4bfTuT5c1sI1wJnGJIa5O1ZV7 zZV1+kgw3Cafwetl3SaXxDVskoo46/s2LSR7ShLa+eUS17ZZ9/bR1tPCIdnT 9g7EUp19Ja68WdfVUP/mkLxWa1BlZ5euatgVPTZkluR7Uy0ke1rMI401ae46 1+klzfW0UUj2dO0CS3f2lcxN11OKaWfVufpAz17nOl7bqF5nk/quMzVjZ11P ew3JnpYWo+ovl8zF7an30eyL9T6a3Z+uPlJxdvURjc2qj8/W3tlDcnaNzz3Y NU5+7VXTzmRjZ0jeorq07uwrMcnHLj1zHdYiCim0ETPQL5eY52anldub1yok /+a3XHa7WhKXbVfNrXBFXURcQzK2rzEn9NyX/9LHenjQjZWQnO1rJg/2lcbW 8zO8WEnLNqLHutsGjbFmNmdficu2jRYxitU5gpQatVpRitfZpPHV2Wf6FrUK ydm3R0sLdq4542N9RHZ2hOQtKmt2cnZJM7E+uk1rEYXk7Nu/3IN9+7duu3rU YrXs9rSFFN/81tn1bJJ+enbb0GVXzW1D3a7aso3mdmXS3HZl08s7Fq6nrYfk 7Kudutm52vOxVpKw1UpD8ha9/UvuCyaN7Qvss+YwVigkY8cac4IdS1cfaz74 WOl6aj74SvZ0+WD3sW5J3PZYxxFRlfW0Ukj2lNeJ13B2SX3PCx5vvAuA9ylR SPZ0RRga7CtZWLGeSvFwme2bKSSv1bvFOb29S3ri1I/tVlLUKiRnNWb6Xy5x 2zYpPprzGjee9XtI/s2vrqqPGyZ1PthnZkzsKyW2z8Ras+yp+qzZ7WkJKb45 WvjLJa7bnmV4uWvckDpDsqdSf3iU/8sl5v6xHtct24j4qlGwK64rwb6Sto9V 0+wwtoXkrI1ewb7P2vzYYbVsxkpIzq6RMfS85m7eelb3urnsSnzFM92utKyY we1qSUzbrtRjM1p9JB6bkfeRvtEYDe+jJZlX2dOYveypRxAznq6NaXW7WhLT tqu+XOpZoKyxTm3lQTHW9bLO23ysW1L7xrquXktjY1UZbFtrq2BfqenJMlFi 2RehnttXoSbxXobucmfL5c6WWa2Zpd1H3W3D/Le7bYT/9mUb4b9L4s9/+zTr JzW2h+Tse7AwOdgZ0RawFjMEGzGDsREzGPvFDM7yivmD5ToT20ZPLMun5+kt 7K6NkFyT9MNXj79cYtn+O8gt2OocWh/7m2PG/eUS067zECu3+tMSkn/zWqW7 TS6Jedukb2U8g/p6WiQke9qWD7ptLIl528Zw/y3VvllC8lqtVZz70ZK4bT+a PrqV7t8cktdqHRy5rpZki3xnbTRfa2caFn2wr52fFVlbmnN2xWZ77UzT9xmq lesrjxrlzmUbUe7aZ+BxsQQsAVuAbQfLa80eLPua3XKzr9ld2mv2x85t3LCx btg6lGKsm2sdGmPdkto31jnLbST2lT7WVo/B2pT1Pm2FzH/Xmp2mtpCMnRIR 86+Q9pr9iRWthbz8aNr4/Er2dI3I1fzIpVE2q56b7WkNyb+5LQt1dkl7P+cJ Tdm0o/a0huTf/I7tys6uPQrada5mk7JiwmiBeEz45H56RTwmdGnHhMFy0cRy 0cRalBAst1Su6Znreuo9xtXZvr5pOrukTputnruvp1JCMnZQRIG/Qtpbmpst M7NlJtZWnpvl3Ue+4n3631sUkrdoxTneR0vitvuoWuTK3do7Zkj2lGpECb9c kvK11/Yo3m2t9c0tJK+VxEr7V0ijbTZ2cOxp7SHZU17+25zl5b+6WVvv89qf 3K33/cnmK3y3DZPGvFgBVoBtwO5yyUZVWbHo85RC8m9+covHoi7tWLSRxRvv Vtz71OKNV7Knb4Rh0favkObH+qiqxdgRkj2tJXYHfoU062bNkp5xdLFrulyS s6+epQW7V0uZ5TES+0ofy6KJtVAX2LVPuFnfJ3TW9wmd3fuEzQbQ11pMkxKS 98I7e0no6pWkfrqy0VzWXPZokkPyXtAYoX65JHsua75bzd3YSiF5L6wdjWBf ScrHerzR2b65hOS1olhd/HLJFlTraStuSdPYGZLX6vW6GJ9N+sbn5rVce1BP rWZIxo7Xf30PyiTZe1DNpqYn9xonQ+sxPq8L2Rzj85LkG59tE/C1UvvmEZJ/ 82K9vUsSkpOlmVmPny138/g5vulrr8fPanX2+Nn3zFtbUa/vmbs0vzp3L3fZ le8MvZI95VWu29WSWLZd2fbM69Hrqa3pJPr33dh5eiza+0r69S9XW5ms2KzZ udKS/Jtfj/TYzKS2Y7PmZxNPm9ZT34FrUe5cO85R7pL0K9fGdll7X80OaZbk 31yjV+Iusey9r2B5zsTynIm1CGOzbfcRe8xgYw57zBBjDq8oIcacJck35rDt dkldY51tLi/JnrLGrPnLJeE91tmw97SJrVYjJK/VsgbX1ZJkr3GeTvH14Brr ONaDPtaJrQd9rFtSK3usEztdExuffZdFYnyW99ayxPhs0jc+B1sos74XZLnZ 94Kc3XtBzfcopHmtSkjeojXKuJ5N2vuEm13rss3WkVgemlmeB8uay2XN5XLL 5fI8y+W1T7hZ3yf03L5P6NLeJ3xWlWbBa/3bzGiWFJp8W+j+uyTd69/Nrn2G zfo+g+Vm32fwb9r7DMHyWv8Gy77+tdzN17/+TXv92yTijeYtCsm1seKNqLPF G7vOamO7NHsLwMZ2aWEbazQvYRtL2ntBTW0GkuFvEPSQvFbvjCvBvpLWi7VY JdiIVYyNWMWkL1YJljWzrJmtnNl9nhLsE1Mk9pU+1nY0guVxsVQySyWxtrO/ Wdk+qH46bvGz+KlsxM9qbx34uLGk9sXPGpq1px5vjF2rd4SKsW5J+o11wVrs HWzE3sZG7G3sF3s7y+t8MFj280HLzX4+6N9U68kysAxsySz3j7V9JFlnIk1t H0n8TOSZnlZvex8tSUs/2VYy20pieY7Eil7lrv2czfp+TrCS2b2fs9m1t7lZ 39t01vc2cwvW0+63EGw+it3KmI+0rwu4Uee1k/3NR87KzKzMzIpkVuliLfYO NmJvZzWzX+wdbAO2AVsyK3qy77HDx9ql32DtwCJYi/KM9Rm3mm1YrCI1bGNF JyNs45Vk73sH+8TXiX2lxNaWWO7bj7qtNcTiWB09JHu6VhcRxy5Jvzg2WJvL go25zNiYy0yaV7kF2JJZ7sC2k2UeiWU/t3LWz63im74+6r7PYG+T1RKSPeW1 z+Bju0n7HkXrflpseyPdT7Bjb8TfWAtdvVL79kacVZuPnNWYj1ZujfnIJD3L FYsnnZWIJ1duiXjS2C+eDFZyuSK5XKFcroyrXNvPCTb2cyx37OeY9O3nDBsp 1NaS3U7dNdaSfb5RUawll6TfWtJZWWeLwYqfLTrrZ4su7bPFYJ8xKbGv9LF2 sr7Z+tXZbbKbnt0m/VyjjWWFfq5hku5zjTbtPFRtnTLsPFRjnTL6iJHil0v6 rVOcZcksS2a5ZpbHx9r+hto6Zdj+hsY6Zb47GhrrFJO+dUqwtqYLNtZ0K7fE ms7Yb03nLK8z3GDZz3AtN/sZrn/TPsPd7LqDsVm/g+Gs38FwaX569jPcyvaU QvJvfs9SR5S7znBZDlYtbndWI25fuSXi9iXpF7c7y+ueTLA8ZmJZemKFzjr7 G5fB+v0cZ/1+jkv7fs6zALRaWsw/LY7ViPnn2KvlXyHtmH+zFpsFG7HZyi0R mxm7Y7NgeeRyeeRyWXK5Us9y2daDwcZ60NhYDxq714PP+mWx5Hq2tTO5np/V +vtyievZpLb1HGy38dnZ7uOz5VYfn03qe3wOVislVv1MxHKLn4n4N3E7WLF1 yoy9gpZZX6fEN/HJWuwdrMfelps99nZ2x97Bvu9mfewrJbYBWz7W1lY07amt rWjG0/UmsJ//mtT2+W+wWjOrNbMyMqt8sgzlMpTLUK585VY7URirf58ou4Rk T99Tnx79u6Tx9a+z3cs1tke5xka5xl7l9p7L7R3KZSi3nOXqWksGq76WtNzq a0n/pr2W3Oza69us7/VZbvG9Pv+mvdcXrFBur1BuL8/cXpGzvQJ6FtAzg57l 0rOUBmwDtgLLB8vr7DhY9rNjZ/3s2Nl9dvzMj2vW7P4DFLYj1Tn0/P6ARa+h 5yX1drKm52C3nt/cuvW82KTnYBVYBZYzK/1gdZ3TBas6Mts0sTrP9qoKsAJs A1ZPdq1hN+trWM/ta1iX9hp2sw3KbVBugXL1Khd0paArAV3prau1B/WxNbO+ BxUsnazZZLDbJhe7bdI0xwcrlPtIKPcRz9xHImcfScl6lpL1zJr1LO3UM/es K+5ZV8xZV1JOXXFvwDZgK7C7vbRCvMdzrM62K9zDNtYPx/SwDZM+23BWZ2Z1 ZlYFWLrYPjPrsbezHns7u2Pvza71wmZ9veCsrxdc2uuFj63A1sx67B0snWyF 9tbcXum5vcpne591W2JfKbFNEitzHCwDy8AysPyxdm5FtoZlO7eiWMOuHwyi WMOa9K1hgy02PjtbYnxeuUuMz0uq3/js52VT5GOXtNk6/ezYpX12HGyvme01 szoy2/lkde31BaujZJZHZvde32a7ZrYrsJzZ0i8Wyu1QboNyy1Wu/yiTs75e CLYkVr/1grPSUx8t6WOFNbPl7CORXGeRXGepuc4yzjpLy7qSlnUlJetK9NSV rDXdZisnlgdldq/pNrvufmy2zMz2DuweN+xy1bpW+f641nKZJdnTx6H8Qqb/ 9JZf1swsrfV+sOTrfctdfb1vEu31vrN1jMQuabN1cGLrrBe71gubjfXCyt1j vWDf9K0Xgq1Qbs3l9p7LHXyWS2sPKljyPSj/wTLfgzKptUPPT+TTEttjfWTl xvrIW8AXS8ASsAXYdrItt7e33F6dub1dz/b2tXberK+dnfW1s7Pf2tlZe186 WI1x0tgYJ70F82RH1pWOrCsV0FU9daXrDsZm/Q6Gs34Hw9kyLhbK7VAuQ7nl Klezbahm29DWgT1tQxl0xaCrmnWl/dSVSPLfJX2sUPLfZ7w6/JepJrta0ma5 jmRXTHzalYBdCdgVg13JZVeSy11SYnO57x2pg+WZ2VdKrAJLB0sj63lJ33g1 sp5pfHq2w12SdWeM7XrYkuzpkyDxO2MujZOtFrc7WyNuX7lLxO1Lql/cbuyz ip8fu6TN+kr7V0j7Pc1gu82/zvaYf1fuHvOvf1M9Wcnldsnldsrl9nmVy5JZ lsz6WYxL+yxms+t++2b9frvlVr/f7uy+377ZdR94s34f2Fm/D+zsvg+82VIz W2pmdWa2nX2kM5erE8pVKJfOcnXdSfjYBmwFlk92QLkDyhUot57l0sjl0sjl kuRyW73KXWf0u1w/o/dy/YzepX1Gv9mSbVJLtknRbJPaTpsUqLNAnQXqrFed RXP/iub+Fcr9K/PsX+GsZ+GsZ6lZz9JPPQv4goAvCPiCXL4gTMASsAXY0xeE QFeUdcUz60rk0hX4kYAfMfiRfH5kB3hU1x1Xtk2xJa2n74/DUvU7ri7tO67B lnUOG2zxc1jLXfwc1tl9DrvZtWe+2dgzNzb2zJ0tJ2v7OcHGfo6xsZ/jtVBk 6+ypvUvabJ2c21sKn6ztfQUbe1/Gxt6XSd/eV7DrXv1m/V695/Z79S7te/XB NouBnW0RA/sP+87Eti8GjnLrzOXWpOcniu+5XCkna74fbPi+seH73vp6sAN0 NUBXA3Q1Ll0NLcBCuTSAvco13w82fN9yh++b1MfFNmAbsBXY0zYGQXspt7dP aK9c7SUBVoBtwJ72PAjqTA1YqLNcdS7AFmA7sO1moY/ANjrYxrhso8+sqz5B Vwq6olNX3c4mgo2zCWPjbMJ7rJ2sZtvomm2jt2wbfZ620UUzK5pZ4syOfrEV 2Oy/vU5gT//tLY8bveVxo5c8bnQ9x43eCrC5j3QOYK8+qtDemturA9rLV3sr 9FElYAuwZx/pzL6gM/uCavaFTqcv6Mh11gF1FqhzPeusmvtINfeRUu4jnWcf ac12pTXblYxsV3rOv++9ksRKz+0Vzu3VcrZXOgFLwBZgTz1LL8Bm25A2gD1t Q1qeU6TlOUVKnlPkW+NYVxNZuWYGS7Knj5EQRblLal+5zlbrX2dr9O/KXaN/ 7Zu+/g3W5qNgYz4yNuYjk775yNliMYOzJWKGlbtEzGDsFzMEa7YRbNjG+uWa Gbbh3zSQXT/Eu9klJdbfuXB2v3PxsQ3YBmwFlk92QLkDyhUot17l2t5XsLH3 ZWzsfXnr28nyyCyPzFbNbJ8nazYZbNik5Q6bdLacLEG5lMsdE8qVq1ybuzcr wDZg9WBbyeW2ksulnstt7Sq3QP+W3L+j11xuO/t3jFznMaDOAnWuZ51Hz/07 eu7fwdC/5ezfwbmPBuc+GjX30RhnH42mmW2a2cKZ1X6x0N4G7S0N2Ku9lH1h UPaFPimzcvpCKwX6t+T+1QH9W89y87ixpFRuHjcePZ7jxqhQ5wp1HlBnPuqs YyZdLWmzz4SadPVMg5euCtS5QJ071LmddaaZWZoddJXZRifbZ7bJPrNNds02 Oei0yb7ep/vYmll/ny5YOtkB7ACWga0X27Pv9z6Azb4/yun7vXdgQc8Mei6X rhR0paCrlnXV56UrgToL1Jlynfu46tygzg3qXHKdu151puxHnbIf6ch+1OX0 o17zmNPrBLYDe445NHJ7acD4LDA+17O9lGOVJWWWgT3HK5U8Xqnk8Uopj1c6 Th9UmI8U5iOB+Uiv+UiJgCVgC7CnbSjMZQpzmcBcptdcJuD7Ar4v4Pt6+b6M 3L8ycv+KdGDP/hUBVoClzMq82JbHWGl5jJWSx1j51mVzOSeJjVdjDcVLsqfP QP2Ylet5SfqNV8FaHBtsxLHGRhxr0hfHBmt7I8HG3ojljr0Rk769kWBtLgs2 5rKVe98L8lrUg+WZy+XZgYVy6SyX7Y5NsHHHxti4Y+MtKBcrwAqwLbPf2mqz BCwBW4A9+4jtbk+wcbfH2LjbY9I4bYMp9y9T7t82c/+ynP3LFfRcs57byHpm vvRse4ybrZmNPUZn6WAb2HMDe25gz3zZs/0O5GYV2JbZ73cgN8tZz/Hbs567 Zj1/vz37sVAuQ7kVyu1XuS3rOX77znOXrOfvt+82W7I9t5LtmXq258anPdPI 7aWR20sC7a1ne4mzLxBnX6CafYH66QvV7hQ5W+NO0cpd406Rsd+domAl67lK 1nOlrOc6Tj2XmXVVZtZV0ayr2k5dlZ77qPTcR4VzH9Vy9lHpDCwDS8Ceei4K rALbMlvmxRLUmVKdnxV8rnORq84VdFVnZkcH9tJVJWAJ2NxHha8+gnGj5HHD V+m/QHPAlmyTpQiw2SZLO22yFKhzgTp3qHM76vzoMo2xS0qs5jG20DzZAewA VoCtN1uALZnlAWw92WzPS8os2MZpz09uAhZ0BXNZOeeyRx8zswp21cCuSrlY BpaBTb7g1g0sQ3sZ2ptjlac9V3ubZrZpZgtnVvvFQh+13EdjDmCvPiLQMxGw JbNy6blCe/Pc/e7QZPacu5/cFdjsgyP74MMePvieviV25DHWd1I2e46xT24G loGF/qWzf0eOGZaUWdDVGTM8bZLM5rjuPbXL7BnXvSd3wEKdGep8ju1PvYAF ex5gz+Oy56EVWOgjmsBefSRQrkC5BOWe8eS7nwdsA7YCyxdbgAVfqAPY0xda yeW2ksulnstt7SqXoX8Z+jfHKk//Xf3LYFcMdpXjuoe97CrPv0v62J7n30cX pw+OAuXCfNQ7lHvNR31kH+wj+2CX7IODTh/sMB91mI96no+e1p/zUYf5qMN8 1Bn695qPuuYxtmseY3vLY2yf5xjbwY86+FEHP+qXH3XJttEl20anbBt9nLZB M9skTbBJBZuk0yY7zEcd5qMO81G/5qPO0F6G9lZo77lOeXJXYPO40csE9hw3 CMZYgjGWYIxt1xjbG+i5gZ4L6FlPPXfwow5+pOBH/fKjTg3YBmwF9uqjAnWG eFI71PmMJ9+zdGAJ2ALsqSuFeVBhHlSYB/s1D+qswOb+VYH+pbN/VbLvq2Tf V8q+r+P0fQWbVLBJBZvUyyaVG7DQR7UCe/aRgj0r2LOCPetlzwpxnUJcpxDX 6RXXKcR1CnGdQFynV1ynBHrOezL+KyG/oMeAhdhMITYTiM30is0E7ErArgTs Si+7kpF1JSPrSgR0VU9dCYzPAuOzwPgs1xoWfJ/A9wl8ny7ff8KCvPfVa977 0pHXVp3PvS/NYztpHttJ89hO/RzbCWyDwDYIbIM+2xBagxHpOpsQohGSPX3/ 7qH42YT/FUS52LUXtFnfC3LW94Kc3XtBHzuAHcBqZvd++8cKsAJsA1YvtgHb gK3A8sHab8IEG78J46xCe9vZXpkCLNRZoc501lnWvtlmfd/MWd83c3bvm31s AxbaK9DeerV3nQ9+bM2snw8GSyfbQVcddMWgq3rpau0VfGwHVjK79wo+Ftrb ob0M7S1Xe9c+w8cSsAXYdrICrABLmf1+82eznH1BGHyhZl+QfvqCNGhvg/aW 3F7Rq70ENknZJuP3CsJSLpskaC8RsNBeudpLYFeU7Sp+2zBbd2btN2CDjd+A ddbvbIfW+8USsFBnhTrTWWd7/3ezmm0y3v+N1p82ycrAMrAE7Om/9nuMm5Xc v/F7jKG5s39ZCrB5bOc6gD3Hdvtt8M0ytLdCe/vV3pZ9n1v2fS4d2NP37Xfj Pxb6t+T+/X43/mMFWLDn0oA97ZnBnhnsuYE982XPXEHPNeu5ddAzn3puYM8N 7LmBPfNlz/73WIMdWc/xd8SCPfVsf/vsY6FcgXLrVW7P/ht/38rZlv33+/tW m1Wos0KdG9S5XHUGP2rgRw38qF1+ZH+DbLMC5VIH9iqXQVcMuqpZV9/fXNss AUuZjb9FknsM2Ap1rrnO8TcEg73qXAVYATb7wvd79R9LwBKwBdjTFxr4QgNf IPCFdvtCgf4tDCz0bzv7lyA2I4jNCGKzdsVmBLEZQWxGEJu1KzYjmFMI5hSC OaVdc4r9bY6PBV0J6IpOXRH4L4H/Evhvu/yXIK4jiOsI4rp2xXUEcR1BXEcQ 17UrriOIrwjiK4L4ql3xFWmOkUhzjEQtx0g0zxiJwPcJfJ/A9+nyfYJ5kGAe JJgH6ZoHiaF/Gfq3DGCv/oUYiSBGqhAj0RUjEfg+ge9X8H26fJ8qlFuh3A7l 8lluhbmswlxWYS6jay6rI9e5DqizQJ3rWefa87hRex43Kudxg8o5blSI6yrE dRXiunrFdVWhzgp1bg3Yq85agQU90wT20rMWYAuwA9jTrirYcwV7rmDP9bLn CvZcwZ4r2HO97LlCXFchrqsQ19UrrquU/bdS9t8yO7Cn/1aC9lIHFtorV3sh JqwQExaICesVE9aax6ta83hVRh6vKp/jVa1gz5WBJWAve64N2AZsBfZcL1Tw /Qq+X8D36+37MO9XmPcLzPv1mvdrgT4q0Ecd+qhdfQR7QRX2ggrsBdVrL6gW 6N8C/duhf9vZv2VmPZcJelbQM516LiPbRhlgGwK2UU/bKDBOFhgnC4yT9Ron yyBgob0C7a1XezX7b9Hsv6Vl/y3z9N+ioCsFXbUK7KUrhTor1LkVYO86F2DB JmGcLNc4WSBmKBAzFIgZyhUzFIH+Fehfyv1bxtW/sI9UYB+pwD5SufaRCuwj FdhHKrCPVK59pMJQLkO5Fcrtd7kVWBg3ygT2HDdKy75fGvh+yb5f9PT90hhY GCcLAXuOk4WApcTWOYGVi63gC1UzO8AX+PIFGJ9LHp8fFnzhGp8L7LeXvN/+ 3qgC9rDJ943+j11SYmF9VM710ZO7A9uBhT6icbECrADbgNWTHVDugHIFyq1X ub1ktpfMNvD9Uk82j3VLymzq31cXF0vAErAF2HayAn0k0Ed5zHnYq4/ymLOk zGpmzzHnyV2BrZmtE1i6WNCzgJ7zHqNbN7AMembQcwU9n/sq729dAAt1LlDn c8x5+qFltoEP5j3z987fyRLUOe/nvDfIMnvu57w3wYBtwEK5cpWbY8IlJTbH hH6bElnooxyb+a9IfOzVRwX8N8dXfgNps2d89eoS2NxHQ6GP2tlHA8acAWPO yGPO+77rxTZgQc8Kej5js/e+YWbz/sb7axyZPfc33ttcwIJtMNhGOW1jwHg1 YLwaDfroGq+Ggq4UdJXXsH4DFFiBOgvUmXKdx7jqDP47wH8H+O+4/HeA/w7w 3wH+Oy7/HS2PdaMNYPNYN/Qc60YjYAnYAuw5Po8GdW65zn1CnfWqM4Fd5TWs 3zD72MuuKrQ3ryX9lthmz7Xkkxv6CGKVPqCPzljlvasIbAO2Anv5EYw5A8ac DmPOOMccnXldtqTN6sjrMp3nukxHjnN05DhHR45zdJ5xzpN7ADuA1czSPNkc qywpsTlW0XnGKk/uBmwDtgJ76RnG5wHjc4fxeVzjc4eYsENM2BVs8tJVz2ur JX117nltpf1cWz0lMZTLUG6eywbJWW4+49Oez/i05zM+7ecZ3/vLNrlciCe7 wDh5xZN9QJ0H1FmgzucdDJV8HqqSz0NV8nmoynke+v6OUS63w5jTYMw5z9pU csygkmMG5RwzqFwxQ1ewDQXbaGAb5znd+7cdgIVxI6/3376/2AIsjBvZrupl V9ry+ndJX3tbXv9qO9e/2nJstqSPpRybabtisw7zUYf5qMN81M/5SCuMVxXG qwrjFV0+CPveCvveCvveeu17a8k+uKSPLdkHtV4+WLJtLCmx2Ta03rZB4Eew 7ta87naPBLaCL+T9Sf+l2s2e+5PvXePMwtpZ89r5/f39iwWbLNkmVcEm22GT AvOgwDwoMA/KNQ9Kz3t9S0ps3uuTce71CfiRgB8J+JFcfiSa2yua2yuS2yt6 tve99Zp0pfmMr2o+4/Nb2MDm8/0lJTaf7/stbGBh7aywdlZYO+u1dtYGbAO2 AHuNzwprSYW1pMJaUq+1pFYoN5/v+68nb/Y8339/cRRYBhZ0dY7tPPPZ4pI2 yyOfLfI8zxYZ1mUM6zKGdRnf6zLJZ+VV8ll5lXxWXvU8K69wF7HCXcQKdxHr dReRhVMfLemrs9TURyydTzbH3iw59mbOsTfLGXsz3INiuAfFcA+Kr3tQzDlu X9LHthy3M59x+5ObgWVgCdjTNtrMttFmto0m2TaYTj3DfSSG+0gM95H4uo/E cLeH4W4Pw90evu72MGU/WtLH1uxHTKcfMZz/Mpz/Mpz/8nX+y1VynavkOlfK da7jrHPN++1LSmzeb+d67re3WZJtLGmzbfRkG222wzbayH7URvajNrIftXn6 UbP32jbLktma5qP2vde22XynaEkf2/OdojbOO0UN4vYGcXuDuL1dcXvr0N4O 7e3Q3nG119572ixzZmvq3/a997TZHE+2nuPJFu8BRQv4ZLM9t57tuWm259ZP e24wxjYYYxuMse0aYx8Xze2VHE8+QW9ur57xZJN8P6dJvp/TJN/PaXLez2mS fbBJ9sEm2QebnD7YBGxSwCYFbFIum4R5ocG80GBeaNe80CS/N9EkvzfROL83 0eR8b6JxvqPeON9Rb8xQ7nlHvXFe4zTOa5zGeY3T+FzjNFgvNFgvNFgvtGu9 8DzPNlk522St2SbrOG0S7n40uPvR4O5Hu+5+NLiT0OBOQoM7Ce26k9DgbkCD uwEN7ga0625Ag/P9Buf7Dc7323W+/+SuwEKdBep8zqGtjGxXZWS7KpztqtbT rgr4YAEfLOCD5fLBAj5YwAcL+GC5fLCAHxXwowJ+VC4/gnPnBufODc6d23Xu 3Oy3STdb89lx/DZp1hyy0Edw12WCXZXLrkoBPcO7S7ODnq93lybc25xwb3Pm e5tvey6WgWVgCdjzzHpm/11SYrP/0jz9lyacs084Z59wzj6vc/aZ99uXlNkC 7HmvYML95wn3nwfcf57X/Wc4LyM4LyM4L6PrvOz5L9QZ7j8PuP88r/vPE87o J7wTN+CMfl7vxE14J26CXQ14J27edgXvtU14r23Ae23zeq9twD3kAfeQB9xD ntc9ZNj3Jtj3Jtj3pmvfmwbcZRpwl2nAXaZ53WUa4AsDfGHAO3Hz8oUB9zYH 3NsccG9zXPc2B9zbHHBvc8C9zXHd24SzNoKzNoKzNrrO2mjA3csBdy8H3L0c 191LOPMiOPMiOPOi68yLRo5jaeQ4luL3+UPrl13B/ckB9yc73J8c1/3JAb4w wBc6+MK4fGHAewQD3iPo8B7BuN4jGAX6N59ZU1fo3/PM+mlT9oWe90aowz2Z ce6NPLkbsKBnuE84rvuEHd4D6vAeUIf3gMb1HlCH+/wd7vN3uM8/rvv8PZ93 U8/n3dQZ7Pk8737alPu3w33+Dvf5+3Wf/2lTZgX0TFnP9tf5kK3AQv/muy7U z7suT5ugvfAeUIf3gPr1HlCH+88d7j93uP/cr/vPHfy3g/928N9++W+H9wg6 vEeg8B5Bv94jgP12gv12gv12uvbbCfbbCfbbCfbb6dpvpw73cjvcy1W4l9uv e7kKPqjggwo+2C8fVJiPFOYjhfmoX/ORwnykMB8pzEf9mo8U3l9QeH9B4f2F fr2/oPC+s8L7zgrvO/frfWf7nd7NCrSX4J30cbUX4kmFeFIhntQrnlS4p6pw T1Xhnqpe91QVfFDBBxV8UC8ftN/B2CzBe9YTypWrXLgvqgTv4MN9Ud3nVjZD dDtqs8mjx0nbO7P0OGhbwnfOVsuPf/7t/dPkz9KSfvC7iaNE5cc//PXz8C+e f/4/+iUdB2VuZHN0cmVhbQplbmRvYmoKNyAwIG9iagoxMTA1NAplbmRvYmoK NSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGIC9UZXh0XQovRXh0R1N0YXRlIDEwIDAgUgovRm9udCAxMSAwIFIKPj4K L0NvbnRlbnRzIDYgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9Q YWdlcyAvS2lkcyBbCjUgMCBSCl0gL0NvdW50IDEKPj4KZW5kb2JqCjEgMCBv YmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKPj4KZW5kb2JqCjQg MCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUvTmFtZS9SNC9UUi9JZGVudGl0eT4+ CmVuZG9iagoxMCAwIG9iago8PC9SNAo0IDAgUj4+CmVuZG9iagoxMSAwIG9i ago8PC9SOQo5IDAgUj4+CmVuZG9iago5IDAgb2JqCjw8L1N1YnR5cGUvVHlw ZTEvQmFzZUZvbnQvSGVsdmV0aWNhL1R5cGUvRm9udC9OYW1lL1I5Pj4KZW5k b2JqCjggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9I ZWx2ZXRpY2E+PgplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHTlUgR2hv c3RzY3JpcHQgNy4wNyk+PmVuZG9iagp4cmVmCjAgMTIKMDAwMDAwMDAwMCA2 NTUzNSBmIAowMDAwMDExMzgwIDAwMDAwIG4gCjAwMDAwMTE2NzMgMDAwMDAg biAKMDAwMDAxMTMyMSAwMDAwMCBuIAowMDAwMDExNDI4IDAwMDAwIG4gCjAw MDAwMTExNjAgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDEx MTM5IDAwMDAwIG4gCjAwMDAwMTE2MTQgMDAwMDAgbiAKMDAwMDAxMTU0MyAw MDAwMCBuIAowMDAwMDExNDgzIDAwMDAwIG4gCjAwMDAwMTE1MTMgMDAwMDAg biAKdHJhaWxlcgo8PCAvU2l6ZSAxMiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAg Ugo+PgpzdGFydHhyZWYKMTE3MjMKJSVFT0YK --1589707168-1242171243-1181886482=:12496 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 --1589707168-1242171243-1181886482=:12496-- From idr-bounces@ietf.org Fri Jun 15 01:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4hq-0000kr-9w; Fri, 15 Jun 2007 01:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4ho-0000gr-GS for idr@ietf.org; Fri, 15 Jun 2007 01:50:44 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4hn-0004Ti-S2 for idr@ietf.org; Fri, 15 Jun 2007 01:50:44 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5F5pY6W002152; Fri, 15 Jun 2007 01:51:34 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706150551.l5F5pY6W002152@sailbum.orleans.occnc.com> To: Danny McPherson From: Curtis Villamizar Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-reply-to: Your message of "Thu, 14 Jun 2007 16:40:31 MDT." <75E42991-5683-422A-89AD-733A11CEF6EE@tcb.net> Date: Fri, 15 Jun 2007 01:51:34 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: idr List Routing , Pekka Savola 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 <75E42991-5683-422A-89AD-733A11CEF6EE@tcb.net> Danny McPherson writes: > > > On Jun 14, 2007, at 9:59 AM, Pekka Savola wrote: > > > > (The header fields already tell the length of the message, so > > allocating 4K buffer for each BGP message (when most messages are > > much smaller than 4K) is probably a waste in many cases.) > > Pekka, > Do you have some references to data supporting your comment here > regarding most messages being smaller than 4K? > > -danny I looked into exactly this more than a decade ago. Its not likely to have changed much. Most of the time you get an occasional BGP keepalive. This is uninteresting. What is interesting is when a transient occurs. You have to engineer for the stress conditions and this is it for a BGP implementation. At that time many peers sent a large number of prefixes with the same AS path. These got packed into multiple full BGP updates and a few partial updates. Then there were AS paths (and other attributes, but mostly AS path) that had a smaller number of prefixes. If the BGP sender is efficient then lots of small updates are packed into a single write. TCP will deliver this as a stream of TCP segments making use of the full MSS. On the receiving end one big read will pick up multiple BGP updates. The BGP adj-in RIB processing is done (which is very minimal) and a read is immediately reposted. This way the flow of BGP updates goes quickly. By the time the BGP adj-out processing happens most or all of the updates have been transferred. A possible slow step is getting the route changes jammed into the forwarding cards. This too has improved. So during a transient most of the reads are delivering either full BGP updates or multiple partially filled updates. If the read buffer is larger than 4KB this is even more efficient as multiple full BGP updates can be read in a single read. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 15 02:05:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4vX-0003ZG-7A; Fri, 15 Jun 2007 02:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4vW-0003ZB-Mo for idr@ietf.org; Fri, 15 Jun 2007 02:04:54 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4vV-0006ZU-5U for idr@ietf.org; Fri, 15 Jun 2007 02:04:54 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5F65h97002262; Fri, 15 Jun 2007 02:05:43 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706150605.l5F65h97002262@sailbum.orleans.occnc.com> To: Erblichs From: Curtis Villamizar Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-reply-to: Your message of "Thu, 14 Jun 2007 15:58:53 PDT." <4671C82D.2DEE5F08@earthlink.net> Date: Fri, 15 Jun 2007 02:05:42 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: idr , Danny McPherson 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 <4671C82D.2DEE5F08@earthlink.net> Erblichs writes: > > Danny McPherson, eta al, > > Let me take a stab at this, but do your own investigation.. > > IMO, one item is due to the use of TCP by BGP. After one > RTO timeout, most implimentations use a slow-start after > idle. To preserve TCP's fast transmit and power of two > mem allocation the stardard link's MTU is 1.5K, times four > with a reduction to the closest power of two, thus 4K. > > Oh, and the recieve window size is normally 4 x MTU which > is then capped at 6K for slow-start. > > Mitchell Erblich > ---------------- Not even close. The BGP update size has nothing to do with the TCP socket buffer size that you set with setsockopt SO_SNDBUF and SO_RCVBUF. The BGP update size can be 4K and the socket buffer size can be 16KB or 64KB (or larger with modern TCP). Or it could be smaller but you wouldn't want to do that. And the MTU of concern then was FDDI or DS3/HSSI (4372? something >4KB). Also the MTU and TCP MSS are not quite the same thing. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 15 10:53:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDAy-0005xR-U6; Fri, 15 Jun 2007 10:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDAx-0005x4-2u for idr@ietf.org; Fri, 15 Jun 2007 10:53:23 -0400 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDAv-0005le-PD for idr@ietf.org; Fri, 15 Jun 2007 10:53:23 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id EB8253494; Fri, 15 Jun 2007 14:53:20 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID340LFoo2V5401Xo1; Fri, 15 Jun 2007 14:53:21 -0000 X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID340LFoo2V5401Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 08:51:46 -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] why has 4096 bytes limit on BGP messages size? Date: Fri, 15 Jun 2007 08:53:16 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F020B70FC1C@VS4.EXCHPROD.USA.NET> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] why has 4096 bytes limit on BGP messages size? Thread-Index: AcevEKo5nxacpLAqQ6CFE3jEhDfgXgAS5CeA From: "Susan Hares" To: "Pekka Savola" , "Danny McPherson" X-OriginalArrivalTime: 15 Jun 2007 14:51:46.0826 (UTC) FILETIME=[B26676A0:01C7AF5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: idr List Routing 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: What is the complexity of the BGP peering at your DFZ? Can you give an overview of the type of updates this represents? =20 Without that information, it is difficult to quantify your data point.=20 Millions of routers in several virtual routers with RD tags may have a different flow pattern of updates.=20 Thanks, Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Friday, June 15, 2007 1:48 AM To: Danny McPherson Cc: idr List Routing Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? On Thu, 14 Jun 2007, Danny McPherson wrote: > On Jun 14, 2007, at 9:59 AM, Pekka Savola wrote: >> (The header fields already tell the length of the message, so allocating 4K=20 >> buffer for each BGP message (when most messages are much smaller than 4K)=20 >> is probably a waste in many cases.) > > Pekka, > Do you have some references to data supporting your comment here > regarding most messages being smaller than 4K? Yes. I've sometimes taken debugs logs of BGP when a DFZ table flapped=20 and looked at the packets. Here's a plot of BGP Update size versus=20 occurrences (in this about 10-15min trace, 87K BGP updates). BGP=20 Updates are sent by a Juniper T-series router. The smallest is 26B,=20 the largest 4095B. Top 20 sizes (6995 through 1229 occurrences) are=20 all between 58 and 95 bytes. (Not sure if the small attachment gets on the list, but if not, I'll=20 post it somewhere.) --=20 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 Jun 15 11:23:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDdi-0006Sh-3L; Fri, 15 Jun 2007 11:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDWa-0004FZ-IS for idr@ietf.org; Fri, 15 Jun 2007 11:15:44 -0400 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDK3-0008Cs-Se for idr@ietf.org; Fri, 15 Jun 2007 11:02:48 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id D75D73435; Fri, 15 Jun 2007 15:01:52 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID763LFoPB20270Xo2; Fri, 15 Jun 2007 15:01:53 -0000 X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID763LFoPB20270Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 09:01:16 -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] why has 4096 bytes limit on BGP messages size? Date: Fri, 15 Jun 2007 09:02:43 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F020B70FC4A@VS4.EXCHPROD.USA.NET> In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F020B70FC1C@VS4.EXCHPROD.USA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] why has 4096 bytes limit on BGP messages size? Thread-Index: AcevEKo5nxacpLAqQ6CFE3jEhDfgXgAS5CeAAAB2LLA= From: "Susan Hares" To: "Susan Hares" , "Pekka Savola" , "Danny McPherson" X-OriginalArrivalTime: 15 Jun 2007 15:01:16.0281 (UTC) FILETIME=[05D26690:01C7AF5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: idr List Routing 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: Oops - I shouldn't type before my coffee in the morning. Please change the question to the following information:=20 What is the complexity of the BGP peering at your DFZ? Can you give an overview of the type of updates this represents? =20 Without that information, it is difficult to quantify your data point.=20 Millions of routes in several virtual routers with RD tags may have a different flow pattern of updates.=20 Thanks, -----Original Message----- From: Susan Hares [mailto:skh@nexthop.com]=20 Sent: Friday, June 15, 2007 10:53 AM To: Pekka Savola; Danny McPherson Cc: idr List Routing Subject: RE: [Idr] why has 4096 bytes limit on BGP messages size? Pekka: What is the complexity of the BGP peering at your DFZ? Can you give an overview of the type of updates this represents? =20 Without that information, it is difficult to quantify your data point.=20 Millions of routers in several virtual routers with RD tags may have a different flow pattern of updates.=20 Thanks, Sue -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Friday, June 15, 2007 1:48 AM To: Danny McPherson Cc: idr List Routing Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? On Thu, 14 Jun 2007, Danny McPherson wrote: > On Jun 14, 2007, at 9:59 AM, Pekka Savola wrote: >> (The header fields already tell the length of the message, so allocating 4K=20 >> buffer for each BGP message (when most messages are much smaller than 4K)=20 >> is probably a waste in many cases.) > > Pekka, > Do you have some references to data supporting your comment here > regarding most messages being smaller than 4K? Yes. I've sometimes taken debugs logs of BGP when a DFZ table flapped=20 and looked at the packets. Here's a plot of BGP Update size versus=20 occurrences (in this about 10-15min trace, 87K BGP updates). BGP=20 Updates are sent by a Juniper T-series router. The smallest is 26B,=20 the largest 4095B. Top 20 sizes (6995 through 1229 occurrences) are=20 all between 58 and 95 bytes. (Not sure if the small attachment gets on the list, but if not, I'll=20 post it somewhere.) --=20 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jun 17 21:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05o4-0005SC-8r; Sun, 17 Jun 2007 21:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05o3-0005O9-9S for idr@ietf.org; Sun, 17 Jun 2007 21:13:23 -0400 Received: from [202.96.99.56] (helo=mailgate.zjgsu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I05o1-0003qr-85 for idr@ietf.org; Sun, 17 Jun 2007 21:13:23 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 50203.2516453744; Sat, 16 Jun 2007 09:01:12 +0800 (CST) Received: from jiafenggen (nat.zjgsu.edu.cn [202.96.99.60]) by mail.zjgsu.edu.cn (Postfix) with SMTP id EB17F1140496; Mon, 18 Jun 2007 09:09:11 +0800 (CST) Date: Mon, 18 Jun 2007 09:12:25 +0800 From: "Fenggen Jia" To: "idr" Subject: Re: Re: Re: [Idr] why has 4096 bytes limit on BGP messages size? X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20070618010911.EB17F1140496@mail.zjgsu.edu.cn> X-Spam-Score: 4.2 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tli 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: , Content-Type: multipart/mixed; boundary="===============0029301157==" Errors-To: idr-bounces@ietf.org --===============0029301157== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksYWxsLA0KCUkgdGhpbmsgbXkgaW5pdGFsIHF1ZXN0aW9uIGlzIHdoeSB0aGUgcHJvdG9jb2wg aGFzIDRLIGxpbWl0IG9uIG1lc3NhZ2VzIHNpemVzLHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhl IGltcGxlbWVudGF0aW9uLGFuIGltcGxlbWVudGF0aW9uIG1heSBjaG9zZSB0byB1c2UgbGFyZ2Ug cmVhZCBvciB3cml0ZSBidWZmZXIoPjRLKSB0byBoYW5kbGUgbXVsdGlwbGUgdXBkYXRlcyBvbmUg dGltZSxzdGlsbCBteSBxdWVzdGlvbiBpcyBpZiBtZXNzYWdlIHNpemUgbGltaXQgaXMgYSBnb29k IHByYXRpY2UgaW4gcHJvdG9jb2wgZGVzaWduPw0KWW91cnMsRmVuZ2dlbg0KDQo+VGhlbiB3aHkg bm90IG90aGVyIGxpbWl0LGhvdyBpcyA0MDk2IGJ5dGVzIGRlcml2ZWQsIHRoYW5rcy5CVFcsd2hl dGhlciBpdCdzIGEgZ29vZCBwcmF0aWNlIGluIHByb3RvY29sIGRldmlzZSB0byBsaW1pdCBtZXNz YWdlIHNpemVzP0kgc2VlIGluIHJpcFYxIHRoYXQgdGhlIG1heGltdW0gUERVIGxlbmd0aCBpcyA1 NzZieXRlcyBpdHMgcmVhc29uIGlzIHRvIGF2b2lkIElQIGZyYWdtZW50YXRpb24sYnV0IGluIHJp cG5nIHRoZSBQRFUgbGVuZ3RoIGlzIGRldGVybWluZWQgb25seSBieSB0aGUgbGluayBNVFUsYW5k IGluIHNubXAgaSBhbHNvIGRvZXNuJ3Qgc2VlIHRoZSBtZXNzYWdlIHNpemUgbGltaXQuIA0KPllv dXJzLEZlbmdnZW4NCj4+DQo+Pk9uIEp1biAxMywgMjAwNywgYXQgMTA6MDEgUE0sIEZlbmdnZW4g SmlhIHdyb3RlOg0KPj4NCj4+PiBoaSxhbGwsDQo+Pj4gICAgICAgSSBhbSB3b25kZXJpbmcgd2h5 IEJHUCBoYXMgNDA5NiBieXRlcyBsaW1pdCBvbiBhbGwgaXRzICANCj4+PiBtZXNzYWdlcyxzaG91 bGQgd2UgbGVhdmUgaXQgdG8gdGhlIGltcGxlbWVudGF0b3IgdG8gZGVjaWRlLHRoYW5rcyENCj4+ DQo+Pg0KPj5XZWxsLCB0aGUgcHJvYmxlbSB3aXRoIHRoYXQgaXMgdGhhdCBhIHNlbmRlciBjb3Vs ZCB0aGVuIGNyZWF0ZSBhbiAgDQo+PmFyYml0cmFyaWx5IGxvbmcgbWVzc2FnZSwgd2hpY2ggY291 bGQgYmUgYXJiaXRyYXJpbHkgcHJvYmxlbWF0aWMgZm9yICANCj4+YSByZWNlaXZlci4NCj4+DQo+ PlRvbnkNCj4+DQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5JZHIgbWFpbGluZyBsaXN0DQo+SWRyQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCj0gPSA9ID0gPSA9ID0gPSA9 ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaHWwg0KwPGjoQ0K IA0KCQkJCSANCqGhoaGhoaGhoaGhoaGhoaFGZW5nZ2VuIEppYQ0KoaGhoaGhoaGhoaGhoaGhoWZn amlhQG1haWwuempnc3UuZWR1LmNuICANCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNy0wNi0xOA0K DQo= --===============0029301157== 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 --===============0029301157==-- From idr-bounces@ietf.org Sun Jun 17 23:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0816-0004ZO-Ry; Sun, 17 Jun 2007 23:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0814-0004Xy-OS for idr@ietf.org; Sun, 17 Jun 2007 23:34:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0814-0005c3-Do for idr@ietf.org; Sun, 17 Jun 2007 23:34:58 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Jun 2007 20:34:58 -0700 X-IronPort-AV: i="4.16,432,1175497200"; d="scan'208"; a="166956763:sNHT49700160" 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/8.12.11) with ESMTP id l5I3YvEV004300; Sun, 17 Jun 2007 20:34:57 -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 l5I3YvtV019658; Mon, 18 Jun 2007 03:34:57 GMT 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); Sun, 17 Jun 2007 20:34:57 -0700 Received: from [192.168.0.100] ([10.21.65.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 20:34:57 -0700 In-Reply-To: <20070618010911.EB17F1140496@mail.zjgsu.edu.cn> References: <20070618010911.EB17F1140496@mail.zjgsu.edu.cn> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? Date: Sun, 17 Jun 2007 20:34:56 -0700 To: "Fenggen Jia" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jun 2007 03:34:57.0392 (UTC) FILETIME=[A487D700:01C7B159] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2300; t=1182137697; x=1183001697; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20why=20has=204096=20bytes=20limit=20on=20BGP=2 0messages=20size? |Sender:=20; bh=Vqso/18hs56fDtfB7trY55rtoC3lzC0zHjpaSm4ja28=; b=yUMIJA3Lf3Dh9RrnmJg50IjEo15otUM363Ewu2Wz4jAkkS4l/1sHNVJ0mvczMKzJmGkKcynK e13wy79WGuRPQJ+CZwmNDq8bwZAhg4rCu8Za/9gk+6Jnwa1kBHy63WxD; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: idr 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 Jun 17, 2007, at 6:12 PM, Fenggen Jia wrote: > I think my inital question is why the protocol has 4K limit on > messages sizes,that is different from the implementation,an > implementation may chose to use large read or write buffer(>4K) to > handle multiple updates one time,still my question is if message > size limit is a good pratice in protocol design? Hmmm, ok, I guess we haven't been explicit enough. I'll try again: 1) First, an implementation should NOT be using a message size that is different than the specified 4k message size limit. If an implementation sends messages more than 4k, then other implementations will not be able to parse them. If an implementation cannot receive 4k messages, then it will also not be able to interoperate. 1a) Having a fixed size is good because it makes the protocol implementations easy. There is no point to having complexity in an implementation if it provides no benefit. Large messages don't provide a wonderful benefit, as they need to be large enough to carry the path attributes and associated prefixes. For this purpose 4k is probably adequate to date. 1b) Historically, 4k was considered a bit wasteful. Of course, it was wonderfully simple compared to EGP which used fragmented packets. Care to parse a 16k jumbo-gram? Care to debug that? Trust me, it's not fun. 2) The 4k message size is *completely independent* of the TCP window size. An implementation is perfectly free to compose any number of messages, each of which is within the 4k limit. The implementation can then cram any number of messages into its TCP socket, up to the buffering limits of that TCP. 2a) Thus, the message size is *NOT* performance limiting, except when an implementation could actually overfill a message. Folks maintaining current implementations might chime in here as to whether or not they see this. So, in summary, yes, a 4k message size limit is a fine situation *for BGP*, for the way that it behaves and the job that it does. This does *NOT* necessarily generalize to other protocols, (e.g. OSPF) where 4k exceeds the most common MTUs. In those cases, you'd end up with fragmentation, and that's bad. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 18 01:04:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09PV-0004V4-D1; Mon, 18 Jun 2007 01:04:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09PU-0004Pj-3o for idr@ietf.org; Mon, 18 Jun 2007 01:04:16 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09PT-0006fw-H6 for idr@ietf.org; Mon, 18 Jun 2007 01:04:16 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5I550pR003832; Mon, 18 Jun 2007 01:05:00 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706180505.l5I550pR003832@sailbum.orleans.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-reply-to: Your message of "Sun, 17 Jun 2007 20:34:56 PDT." <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com> Date: Mon, 18 Jun 2007 01:04:59 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: idr 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 Hi Tony, Some further clarification inline, not for you since you know this, but for anyone that might still be confusing BGP message size and TCP buffer size (aka TCP window size). In message <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com> Tony Li writes: > > On Jun 17, 2007, at 6:12 PM, Fenggen Jia wrote: > > > I think my inital question is why the protocol has 4K limit on > > messages sizes,that is different from the implementation,an > > implementation may chose to use large read or write buffer(>4K) to > > handle multiple updates one time,still my question is if message > > size limit is a good pratice in protocol design? > > Hmmm, ok, I guess we haven't been explicit enough. I'll try again: We've been clear to the careful reader. I mentioned that the TCP window has nothing to do with the BGP message size. That was a different person confused about this. > 1) First, an implementation should NOT be using a message size that > is different than the specified 4k message size limit. If an > implementation sends messages more than 4k, then other > implementations will not be able to parse them. If an implementation > cannot receive 4k messages, then it will also not be able to > interoperate. > > 1a) Having a fixed size is good because it makes the protocol > implementations easy. There is no point to having complexity in an > implementation if it provides no benefit. Large messages don't > provide a wonderful benefit, as they need to be large enough to carry > the path attributes and associated prefixes. For this purpose 4k is > probably adequate to date. Right. > 1b) Historically, 4k was considered a bit wasteful. Of course, it > was wonderfully simple compared to EGP which used fragmented > packets. Care to parse a 16k jumbo-gram? Care to debug that? Trust > me, it's not fun. Actually EGP was worse than that. EGP required that you put everythin in one dategram packet which eventually exceeded the IP 64KB limit. Fortunately only one network was using EGP when that happenned (NASA still had Proteon routers that ran EGP and not BGP so they had to take partial routing and use default - they were even worse off when CIDR came along but finally retired the Proteons). Then there was the AGS FDDI interface that couldn't handle 5 consecutive IP packets or fragments without dropping the 5th one. Not amusing when EGP packets required 5 fragments (somewhere beyond 20KB in size). Those were interesting times. Its boring at times now that things mostly work. :-) > 2) The 4k message size is *completely independent* of the TCP window > size. An implementation is perfectly free to compose any number of > messages, each of which is within the 4k limit. The implementation > can then cram any number of messages into its TCP socket, up to the > buffering limits of that TCP. I think that is the point people are missing. > 2a) Thus, the message size is *NOT* performance limiting, except when > an implementation could actually overfill a message. Folks > maintaining current implementations might chime in here as to whether > or not they see this. Yes BGP updates are filled and spill into a second update. No it is not performance limiting. But you knew that. Performance is determined by the TCP buffer size set. TCP buffer size in BSD is set with a setsockopt as I had mentioned before. TCP buffer size has nothing to do with BGP message size. BGP message size has little to do with performance unless as I had mentioned parsing the attributes such as AS Path more than once ever became an issue. If anything it is less an issue over time. > So, in summary, yes, a 4k message size limit is a fine situation *for > BGP*, for the way that it behaves and the job that it does. This > does *NOT* necessarily generalize to other protocols, (e.g. OSPF) > where 4k exceeds the most common MTUs. In those cases, you'd end up > with fragmentation, and that's bad. OSPF does not use TCP therefore its message size is relevant to performance and cannot exceed the MTU. BGP uses TCP therefore its message size is not relevant to performance except for internal parsing issues and the MTU is irrelevant to the BGP message size. > Regards, > Tony Curtis ps - For those new to IDR (and some of the posters on this thread seem to be) this sort of mini-lecture on how TCP works and how BGP uses it is somewhat of a rerun. The topic or something similar comes up on this mailing list every few years. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 18 02:39:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0AtD-0005MN-9i; Mon, 18 Jun 2007 02:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0AtB-0005Lm-GR for idr@ietf.org; Mon, 18 Jun 2007 02:39:01 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0AtB-0008E5-26 for idr@ietf.org; Mon, 18 Jun 2007 02:39:01 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1212554nzd for ; Sun, 17 Jun 2007 23:39:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DCi58LhZEOdDzENhoLrhGSZqjaF/fH1bqN9nxPyaNMSol6fowDuFIpLKFjmZvHCaY0ivW0SpV12fz/XOmCycaTWThBAYeWTG3jfbelZyXrBh/Mc81GpP79s3MWpYEzqelNCmDbB0+cerCiWd0ovwfkCB3t6WKlix7oCfpbcEKlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AFwY67ZxrizGKdIJaXvaQzJXpRBkvKktAv7eCqBYllqnUY9B5f0Ojmq7i/j/WcVEMGpbeYkKhl2LAMaiowTaRGRdbNwyXtZpNZcY5KJTNyf29gQMqWTsC3yqE3YpupckOh1d36rPUKo+yMckRfhnLje0FXGV3fKhgnhandZCqlE= Received: by 10.114.123.1 with SMTP id v1mr5815223wac.1182148740330; Sun, 17 Jun 2007 23:39:00 -0700 (PDT) Received: by 10.114.154.5 with HTTP; Sun, 17 Jun 2007 23:39:00 -0700 (PDT) Message-ID: <77ead0ec0706172339i69ef6febwaea1ca5eec9a3386@mail.gmail.com> Date: Sun, 17 Jun 2007 23:39:00 -0700 From: "Vishwas Manral" To: curtis@occnc.com Subject: Re: [Idr] why has 4096 bytes limit on BGP messages size? In-Reply-To: <200706180505.l5I550pR003832@sailbum.orleans.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com> <200706180505.l5I550pR003832@sailbum.orleans.occnc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Tony Li , idr 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, > > Hmmm, ok, I guess we haven't been explicit enough. I'll try again: > > We've been clear to the careful reader. I mentioned that the TCP > window has nothing to do with the BGP message size. > > BGP uses TCP therefore its message size is not relevant to performance > except for internal parsing issues and the MTU is irrelevant to the > BGP message size. I agree with both the statements above. Having recently written some DTCP/ IP and AKE implementation from scratch (both work over TCP), I agree with you. The TCP does not differentiate between packet boundaries from the application. So if 2 packets of size 2500 are sent from the application it could be similar to the case of having sent 1 packet of 5000 bytes. Let me know if I am wrong? Thanks, Vishwas On 6/17/07, Curtis Villamizar wrote: > > Hi Tony, > > Some further clarification inline, not for you since you know this, > but for anyone that might still be confusing BGP message size and TCP > buffer size (aka TCP window size). > > In message <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com> > Tony Li writes: > > > > On Jun 17, 2007, at 6:12 PM, Fenggen Jia wrote: > > > > > I think my inital question is why the protocol has 4K limit on > > > messages sizes,that is different from the implementation,an > > > implementation may chose to use large read or write buffer(>4K) to > > > handle multiple updates one time,still my question is if message > > > size limit is a good pratice in protocol design? > > > > Hmmm, ok, I guess we haven't been explicit enough. I'll try again: > > We've been clear to the careful reader. I mentioned that the TCP > window has nothing to do with the BGP message size. > > That was a different person confused about this. > > > 1) First, an implementation should NOT be using a message size that > > is different than the specified 4k message size limit. If an > > implementation sends messages more than 4k, then other > > implementations will not be able to parse them. If an implementation > > cannot receive 4k messages, then it will also not be able to > > interoperate. > > > > 1a) Having a fixed size is good because it makes the protocol > > implementations easy. There is no point to having complexity in an > > implementation if it provides no benefit. Large messages don't > > provide a wonderful benefit, as they need to be large enough to carry > > the path attributes and associated prefixes. For this purpose 4k is > > probably adequate to date. > > Right. > > > 1b) Historically, 4k was considered a bit wasteful. Of course, it > > was wonderfully simple compared to EGP which used fragmented > > packets. Care to parse a 16k jumbo-gram? Care to debug that? Trust > > me, it's not fun. > > Actually EGP was worse than that. EGP required that you put everythin > in one dategram packet which eventually exceeded the IP 64KB limit. > Fortunately only one network was using EGP when that happenned (NASA > still had Proteon routers that ran EGP and not BGP so they had to take > partial routing and use default - they were even worse off when CIDR > came along but finally retired the Proteons). Then there was the AGS > FDDI interface that couldn't handle 5 consecutive IP packets or > fragments without dropping the 5th one. Not amusing when EGP packets > required 5 fragments (somewhere beyond 20KB in size). Those were > interesting times. Its boring at times now that things mostly work. :-) > > > 2) The 4k message size is *completely independent* of the TCP window > > size. An implementation is perfectly free to compose any number of > > messages, each of which is within the 4k limit. The implementation > > can then cram any number of messages into its TCP socket, up to the > > buffering limits of that TCP. > > I think that is the point people are missing. > > > 2a) Thus, the message size is *NOT* performance limiting, except when > > an implementation could actually overfill a message. Folks > > maintaining current implementations might chime in here as to whether > > or not they see this. > > Yes BGP updates are filled and spill into a second update. No it is > not performance limiting. But you knew that. > > Performance is determined by the TCP buffer size set. TCP buffer size > in BSD is set with a setsockopt as I had mentioned before. TCP buffer > size has nothing to do with BGP message size. > > BGP message size has little to do with performance unless as I had > mentioned parsing the attributes such as AS Path more than once ever > became an issue. If anything it is less an issue over time. > > > So, in summary, yes, a 4k message size limit is a fine situation *for > > BGP*, for the way that it behaves and the job that it does. This > > does *NOT* necessarily generalize to other protocols, (e.g. OSPF) > > where 4k exceeds the most common MTUs. In those cases, you'd end up > > with fragmentation, and that's bad. > > OSPF does not use TCP therefore its message size is relevant to > performance and cannot exceed the MTU. > > BGP uses TCP therefore its message size is not relevant to performance > except for internal parsing issues and the MTU is irrelevant to the > BGP message size. > > > Regards, > > Tony > > Curtis > > ps - For those new to IDR (and some of the posters on this thread seem > to be) this sort of mini-lecture on how TCP works and how BGP uses it > is somewhat of a rerun. The topic or something similar comes up on > this mailing list every few years. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 18 02:49:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0B3Z-0006v9-Ju; Mon, 18 Jun 2007 02:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0B3Y-0006uw-GI for idr@ietf.org; Mon, 18 Jun 2007 02:49:44 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0B3X-0002bV-6U for idr@ietf.org; Mon, 18 Jun 2007 02:49:44 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5I6mA7u007639; Mon, 18 Jun 2007 01:49:40 -0500 (CDT) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 01:48:39 -0500 Received: from INEXC1U01.in.lucent.com ([135.254.223.20]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 12:18:34 +0530 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] why has 4096 bytes limit on BGP messages size? Date: Mon, 18 Jun 2007 12:18:34 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196586F557@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0706172339i69ef6febwaea1ca5eec9a3386@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] why has 4096 bytes limit on BGP messages size? thread-index: Acexc3AaY0spk6oyQW6SQBup3HW+OQAAHWjg References: <982B9BFB-D286-40D5-9A07-3D2DB51BC102@cisco.com><200706180505.l5I550pR003832@sailbum.orleans.occnc.com> <77ead0ec0706172339i69ef6febwaea1ca5eec9a3386@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 18 Jun 2007 06:48:34.0853 (UTC) FILETIME=[B113B550:01C7B174] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: idr 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 Vishwas, > I agree with both the statements above. Having recently written some > DTCP/ IP and AKE implementation from scratch (both work over TCP), I > agree with you. The TCP does not differentiate between packet > boundaries from the application. So if 2 packets of size 2500 are sent > from the application it could be similar to the case of having sent 1 > packet of 5000 bytes. >=20 > Let me know if I am wrong? Yup, you are right. The application at the other end would never know if TCP received two packets each of 2500 bytes or a single packet of 5000 bytes.=20 Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 18 09:56:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HiU-0003D4-UV; Mon, 18 Jun 2007 09:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HiS-00039Z-Lw for idr@ietf.org; Mon, 18 Jun 2007 09:56:24 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0HiR-0004CM-T3 for idr@ietf.org; Mon, 18 Jun 2007 09:56:24 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 18 Jun 2007 06:56:23 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5IDuFJ42073; Mon, 18 Jun 2007 06:56:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200706181356.l5IDuFJ42073@merlot.juniper.net> To: idr-ads@tools.ietf.org Subject: [Idr] Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.tx MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37476.1182174975.1@juniper.net> Date: Mon, 18 Jun 2007 06:56:15 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Cc: skh@nexthop.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 Dave and Ross, The IDR WG completed the Last Call on draft-ietf-idr-rfc3065bis-06. The document is ready for publication as Draft Standard. Yakov. ------- Forwarded Message Date: Sun, 03 Jun 2007 20:33:07 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] Last Call on editorial change in draft-ietf-idr-rfc3065bis-06.tx t Folks, This is to start the IDR WG Last Call on draft-ietf-idr-rfc3065bis-06.txt. Please note that the scope of this Last Call is limited to only the revised text. The Last Call ends on June 17. Yakov. - ------- Forwarded Message Date: Sun, 03 Jun 2007 22:37:21 -0400 From: "John G. Scudder" To: idr@ietf.org cc: John Scudder Subject: [Idr] draft-ietf-idr-rfc3065bis-06.txt editorial change Folks, While editing draft-ietf-idr-rfc3065bis-06.txt for publication, the vigilant RFC Editor pointed out several nits with the draft. Most can be resolved as minor editorial changes, however, one of them is slightly more than that. Section 4.1 of the draft ("AS_PATH Modification Rules") is essentially a cut-n-paste of section 5.1.2 of the base spec, with necessary changes for confederations. Unfortunately, we did not revise the draft to match when the base spec was revised. To correct this, we propose to re-do section 4.1. There are no changes of any substance compared to earlier versions, i.e. the intent is still to say "do what the base spec does, only do it with confed-type segments", but the text is brought into line with RFC 4271. The change is extensive enough that we thought it worthwhile to poll the WG again. Chairs, please consider this a request for a WGLC, only on this revised text. Thanks, - - --John (with Danny and Paul) Revised section 4.1: 4.1. AS_PATH Modification Rules AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or AS_CONFED_SEQUENCES. When a BGP speaker propagates a route it learned from another BGP speaker's UPDATE message, it modifies the route's AS_PATH attribute based on the location of the BGP speaker to which the route will be sent: a) When a given BGP speaker advertises the route to another BGP speaker located in its own Member-AS, the advertising speaker SHALL NOT modify the AS_PATH attribute associated with the route. b) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is a member of the local confederation, the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_CONFED_SEQUENCE, the local system prepends its own Member-AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and prepend its own AS number to this new segment. 2) if the first path segment of the AS_PATH is not of type AS_CONFED_SEQUENCE the local system prepends a new path segment of type AS_CONFED_SEQUENCE to the AS_PATH, including its own Member-AS Number in that segment. 3) if the AS_PATH is empty, the local system creates a path segment of type AS_CONFED_SEQUENCE, places its own Member-AS Number into that segment, and places that segment into the AS_PATH. c) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is not a member of the local confederation, the advertising speaker SHALL update the AS_PATH attribute as follows: 1) if any path segments of the AS_PATH are of the type AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST be removed from the AS_PATH attribute, leaving the sanitized AS_PATH attribute to be operated on by steps 2, 3 or 4. 2) if the first path segment of the remaining AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS Confederation Identifier as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). If the act of prepending will cause an overflow in the AS_PATH segment (i.e., more than 255 ASes), it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. 3) if the first path segment of the remaining AS_PATH is of type AS_SET, the local system prepends a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS Confederation Identifier in that segment. 4) if the remaining AS_PATH is empty, the local system creates a path segment of type AS_SEQUENCE, places its own AS Confederation Identifier into that segment, and places that segment into the AS_PATH. When a BGP speaker originates a route then: a) the originating speaker includes its own AS Confederation Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring autonomous systems that are not members of the local confederation. In this case, the AS Confederation Identifier of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute. a) the originating speaker includes its own Member-AS Number in a path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring Member Autonomous Systems that are members of the local confederation. In this case, the Member-AS Number of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute. c) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to BGP speakers residing within the same Member-AS. (An empty AS_PATH attribute is one whose length field contains the value zero). Whenever the modification of the AS_PATH attribute calls for including or prepending the AS Confederation Identifier or Member-AS Number of the local system, the local system MAY include/prepend more than one instance of that value in the AS_PATH attribute. This is controlled via local configuration. Diff vs. draft-ietf-idr-rfc3065bis-06.txt (ends up including pretty much the whole section): 3,10c3,12 < < When implementing BGP Confederations Section 5.1.2 of [BGP-4] is < replaced with the following text: < < When a BGP speaker propagates a route which it has learned from < another BGP speaker's UPDATE message, it SHALL modify the route's < AS_PATH attribute based on the location of the BGP speaker to which < the route will be sent: - - --- > AS_PATH is a well-known mandatory attribute. This attribute > identifies the autonomous systems through which routing information > carried in this UPDATE message has passed. The components of this > list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or > AS_CONFED_SEQUENCES. > > When a BGP speaker propagates a route it learned from another BGP > speaker's UPDATE message, it modifies the route's AS_PATH attribute > based on the location of the BGP speaker to which the route will be > sent: 19c21 < the local confederation, the advertising speaker SHALL update - - --- > the local confederation, the advertising speaker updates 23,25c25,31 < AS_CONFED_SEQUENCE, the local system SHALL prepend its own < Member-AS Number as the last element of the sequence (put < it in the leftmost position). - - --- > AS_CONFED_SEQUENCE, the local system prepends its own Member-AS > number as the last element of the sequence (put it in the > leftmost position with respect to the position of octets in the > protocol message). If the act of prepending will cause an > overflow in the AS_PATH segment (i.e., more than 255 ASes), it > SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and > prepend its own AS number to this new segment. 28c34 < AS_CONFED_SEQUENCE the local system SHALL prepend a new path - - --- > AS_CONFED_SEQUENCE the local system prepends a new path 31a38,42 > 3) if the AS_PATH is empty, the local system creates a path > segment of type AS_CONFED_SEQUENCE, places its own Member-AS > Number into that segment, and places that segment into the > AS_PATH. > 40c51 < AS_PATH attribute to be operated on by steps 2 or 3. - - --- > AS_PATH attribute to be operated on by steps 2, 3 or 4. 43,51c54,65 < AS_SEQUENCE, the local system SHALL prepend its own < AS Confederation Identifier as the last element of the sequence < (put it in the leftmost position). < < 3) if there are no path segments following the removal of the < first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the < first path segment of the remaining AS_PATH is not of type < AS_SEQUENCE the local system SHALL prepend a new path segment < of type AS_SEQUENCE to the AS_PATH, including its own AS - - --- > AS_SEQUENCE, the local system prepends its own AS Confederation > Identifier as the last element of the sequence (put it in > the leftmost position with respect to the position of > octets in the protocol message). If the act of prepending > will cause an overflow in the AS_PATH segment (i.e., more > than 255 ASes), it SHOULD prepend a new segment of type > AS_SEQUENCE and prepend its own AS number to this new > segment. > > 3) if the first path segment of the remaining AS_PATH is of type > AS_SET, the local system prepends a new path segment of > type AS_SEQUENCE to the AS_PATH, including its own AS 54,63c68,86 < When a BGP speaker originates a route: < < a) the originating speaker SHALL include an empty AS_PATH attribute < in all UPDATE messages sent to BGP speakers residing within the < same Member-AS. (An empty AS_PATH attribute is one whose length < field contains the value zero). < < b) the originating speaker SHALL include its own Member-AS Number in < an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all < UPDATE messages sent to BGP speakers located in neighboring - - --- > 4) if the remaining AS_PATH is empty, the local system creates > a path segment of type AS_SEQUENCE, places its own AS > Confederation Identifier into that segment, and places > that segment into the AS_PATH. > > When a BGP speaker originates a route then: > > a) the originating speaker includes its own AS Confederation > Identifier in a path segment, of type AS_SEQUENCE, in the AS_PATH > attribute of all UPDATE messages sent to BGP speakers located in > neighboring autonomous systems that are not members of the local > confederation. In this case, the AS Confederation Identifier of > the originating speaker's autonomous system will be the only entry > the path segment, and this path segment will be the only segment > in the AS_PATH attribute. > > a) the originating speaker includes its own Member-AS Number in a > path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute > of all UPDATE messages sent to BGP speakers located in neighboring 65,66c88,102 < confederation (i.e., the originating speaker's Member-AS Number < will be the only entry in the AS_PATH attribute). - - --- > confederation. In this case, the Member-AS Number of the > originating speaker's autonomous system will be the only entry the > path segment, and this path segment will be the only segment in > the AS_PATH attribute. > > c) the originating speaker includes an empty AS_PATH attribute in > all UPDATE messages sent to BGP speakers residing within the same > Member-AS. (An empty AS_PATH attribute is one whose length field > contains the value zero). > > Whenever the modification of the AS_PATH attribute calls for > including or prepending the AS Confederation Identifier or > Member-AS Number of the local system, the local system MAY > include/prepend more than one instance of that value in the > AS_PATH attribute. This is controlled via local configuration. 68,74d103 < c) the originating speaker SHALL include its own AS Confederation < Identifier in an AS_SEQUENCE segment of the AS_PATH attribute of < all UPDATE messages sent to BGP speakers located in neighboring < autonomous systems that are not members of the local < confederation. (In this case, the originating speaker's AS < Confederation Identifier will be the only entry in the AS_PATH < attribute). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jun 18 16:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NWC-0000TF-GO; Mon, 18 Jun 2007 16:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NWA-0000S5-VK for idr@ietf.org; Mon, 18 Jun 2007 16: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 1I0NW9-0003Wu-Vq for idr@ietf.org; Mon, 18 Jun 2007 16:08:06 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jun 2007 13:08:00 -0700 X-IronPort-AV: i="4.16,436,1175497200"; d="scan'208,217"; a="167483888:sNHT2586390291" 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/8.12.11) with ESMTP id l5IK806K002519 for ; Mon, 18 Jun 2007 13:08:00 -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 l5IK7p2Q004767 for ; Mon, 18 Jun 2007 20:08:00 GMT 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, 18 Jun 2007 13:08:00 -0700 Received: from [171.71.55.99] ([171.71.55.99]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:07:59 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) To: idr Message-Id: References: From: Tony Li Date: Mon, 18 Jun 2007 13:07:58 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jun 2007 20:07:59.0829 (UTC) FILETIME=[5E6E3850:01C7B1E4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20609; t=1182197280; x=1183061280; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Fwd=3A=20I-D=20ACTION=3Adraft-li-bgp-stability-01.txt=20 |Sender:=20; bh=p8a42XaIs5xTDNDbKkGo+Wz5wU+Wak4H1myiqzKmM0k=; b=D89zzasEePZdCZ9AD6WhoFgMPL3pRJWuxaXxqP/lkl6+9VgxQgMehb9IifRqbUTpBNxyy3PF ryVD/Zm/EoVyQzI7dp+j5CZa7qO8hdGvyRqZF3nY0w+1qRDriu8O7tqVkPb9ChB8LH+MTbthmV ZULbzD0Zx5+fHnjB9MLpD0jw0=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Subject: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-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: , Content-Type: multipart/mixed; boundary="===============0605360631==" Errors-To: idr-bounces@ietf.org --===============0605360631== Content-Type: multipart/alternative; boundary=Apple-Mail-7--120867827 --Apple-Mail-7--120867827 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Please note some significant changes since the previous version. We now have some analysis that shows techniques that could possibly reduce churn by 20-35%. Please see the draft for details. Thanks, Geoff & Tony Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 18, 2007 12:50:02 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-li-bgp-stability-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : BGP Stability Improvements > Author(s) : G. Huston, T. Li > Filename : draft-li-bgp-stability-01.txt > Pages : 23 > Date : 2007-6-18 > > BGP is the routing protocol used to tie the Autonomous Systems (ASes) > of the Internet together. The ongoing stability of BGP in the face > of arbitrary inputs, both malicious and unintentional, is of > primary > importance to the overall stability of the Internet. The overall > issue is not a new one. Previously, one aspect of stability, known > as route flap damping was originally discussed in RFC 2439. In the > intervening years, a great deal of experience with flap damping and > > other stability concerns has been accumulated. Most recently, the > issue of BGP stability has been highlighted in RAWS. This document > describes the experience that has been gained concerning > stability in > the intervening years, hypotheses about remaining problems, > suggestions for experiments to be performed, and proposals for > possible alternatives. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-li-bgp-stability-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-li-bgp-stability-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-li-bgp-stability-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-6-18125717.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-7--120867827 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hi all,

Please note some = significant changes since the previous version.=A0 We now have some = analysis that shows techniques that could possibly reduce churn by = 20-35%.=A0 Please see the draft for details.

Thanks,
Geoff = & Tony


Begin forwarded message:

Date: June 18, 2007 12:50:02 PM = PDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-li-bgp-stability-01.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : BGP Stability = Improvements
Author(s) : G. = Huston, T. Li
Filename : = draft-li-bgp-stability-01.txt
= Pages = = : 23
Date : 2007-6-18


BGP is the = routing protocol used to tie the Autonomous Systems (ASes)
=A0=A0 = of the Internet together.=A0 = The ongoing stability of BGP in the face
=A0=A0 = of arbitrary inputs, both malicious and unintentional, is of = primary
=A0=A0 importance to the overall = stability of the Internet.=A0 = The overall
=A0=A0 issue is not a new = one.=A0 Previously, one = aspect of stability, known
=A0=A0 as route flap damping was = originally discussed in RFC 2439.=A0= In the
=A0=A0 intervening years, a great = deal of experience with flap damping and

=A0=A0 other stability concerns = has been accumulated.=A0 = Most recently, the
=A0=A0 issue of BGP stability has = been highlighted in RAWS.=A0 = This document
=A0=A0 describes the experience = that has been gained concerning stability in
=A0=A0 = the intervening years, hypotheses about remaining = problems,
=A0=A0 suggestions for = experiments to be performed, and proposals for
=A0=A0 = possible alternatives.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-li-bgp-stability-01.txt

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-li-bgp-stability-01.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-li-bgp-stability-01.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-7--120867827-- --===============0605360631== 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 --===============0605360631==-- From idr-bounces@ietf.org Tue Jun 19 01:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0WOg-0000Sm-Dm; Tue, 19 Jun 2007 01:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0WOe-0000Ok-Lz for idr@ietf.org; Tue, 19 Jun 2007 01:36:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0WOe-0004i4-B2 for idr@ietf.org; Tue, 19 Jun 2007 01:36:56 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1536083nzd for ; Mon, 18 Jun 2007 22:36:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r/6bZNdXHDE6KlzBraHJqNAvABSXT4zcJLnjlWihWZf7DwTJ7zuhidbKfTWhp/U6m7ptm+CP6jyS95LgazhzckJcARuFJeP0PK7Eiq1Lki+Ymu2S5giy+N0vWlYpbuM/+HGsnUFW6LnW0Ytv8ceFhQinRrRfxiSLfhdJxuapxkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YnBqKRiABSekdKUS/CHUK0W/eDwiFt3MQAZky2phNWe019tzB2ygPRRMTLpG6sR/B3HCo8fpB4y0vKK0jQDZr3ODM2BOT2sWprREq1jMFoT5rwqYjKUFwSth9DRoD5rLesKttcUuupZmtL7JNV7jPaAcQ1eO3Ljz0Zl6ftZxrJc= Received: by 10.114.59.1 with SMTP id h1mr7033776waa.1182231415718; Mon, 18 Jun 2007 22:36:55 -0700 (PDT) Received: by 10.114.154.5 with HTTP; Mon, 18 Jun 2007 22:36:55 -0700 (PDT) Message-ID: <77ead0ec0706182236ud60aa17g3bf68963c3c99202@mail.gmail.com> Date: Mon, 18 Jun 2007 22:36:55 -0700 From: "Vishwas Manral" To: "Tony Li" Subject: Re: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt 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: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: idr 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 Tony, The draft looks very good to me. One small comment was that all along in the draft some numbers have been mentioned. It would be good to further characterize the measurements, like for how long the measurements were done and the methodology in brief. thanks, Vishwas On 6/18/07, Tony Li wrote: > > > Hi all, > > Please note some significant changes since the previous version. We now > have some analysis that shows techniques that could possibly reduce churn by > 20-35%. Please see the draft for details. > > Thanks, > Geoff & Tony > > > Begin forwarded message: > > From: Internet-Drafts@ietf.org > Date: June 18, 2007 12:50:02 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-li-bgp-stability-01.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : BGP Stability Improvements > Author(s) : G. Huston, T. Li > Filename : draft-li-bgp-stability-01.txt > Pages : 23 > Date : 2007-6-18 > > > BGP is the routing protocol used to tie the Autonomous Systems (ASes) > of the Internet together. The ongoing stability of BGP in the face > of arbitrary inputs, both malicious and unintentional, is of primary > importance to the overall stability of the Internet. The overall > issue is not a new one. Previously, one aspect of stability, known > as route flap damping was originally discussed in RFC 2439. In the > intervening years, a great deal of experience with flap damping and > > other stability concerns has been accumulated. Most recently, the > issue of BGP stability has been highlighted in RAWS. This document > describes the experience that has been gained concerning stability in > the intervening years, hypotheses about remaining problems, > suggestions for experiments to be performed, and proposals for > possible alternatives. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-li-bgp-stability-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-li-bgp-stability-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-li-bgp-stability-01.txt". > > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-6-18125717.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ > 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 Jun 19 20:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nl9-00027y-L9; Tue, 19 Jun 2007 20:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nl8-00027t-Ea for idr@ietf.org; Tue, 19 Jun 2007 20:09:18 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nl7-0000bp-0g for idr@ietf.org; Tue, 19 Jun 2007 20:09:18 -0400 Received: from [202.12.29.180] (dhcp180.apnic.net [202.12.29.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 80356D5F2D; Wed, 20 Jun 2007 10:09:15 +1000 (EST) Message-ID: <4678709E.5030004@apnic.net> Date: Wed, 20 Jun 2007 10:11:10 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt References: <77ead0ec0706182236ud60aa17g3bf68963c3c99202@mail.gmail.com> In-Reply-To: <77ead0ec0706182236ud60aa17g3bf68963c3c99202@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Tony Li , idr 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 numbers in section 4.3.1 were based on a data collection of the entire set of BGP updates gathered from 1 April 2007 0000 UTC+1000 until 1 May 2007 0000 UTC+1000, using a single eBGP feed from AS4637 that provided a full route set to the data collector. AS4637 has a footprint across Asia and parts of North America, as I understand it, and it operates as a transit provider. The eBGP feed was from a Cisco router that (by default) used a 30 second MRAI Timer. The data collection BGP engine was a Cisco router using an update collection configuration via logging debug bgp updates through syslog. regards, Geoff Vishwas Manral wrote: > Hi Tony, > > The draft looks very good to me. > > One small comment was that all along in the draft some numbers have > been mentioned. It would be good to further characterize the > measurements, like for how long the measurements were done and the > methodology in brief. > > thanks, > Vishwas > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 19 20:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nww-0003bi-Sj; Tue, 19 Jun 2007 20:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nwv-0003bd-GF for idr@ietf.org; Tue, 19 Jun 2007 20:21:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nwu-000864-65 for idr@ietf.org; Tue, 19 Jun 2007 20:21:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2007 17:21:27 -0700 X-IronPort-AV: i="4.16,440,1175497200"; d="scan'208"; a="168380964:sNHT46474740" 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/8.12.11) with ESMTP id l5K0LRIh009553; Tue, 19 Jun 2007 17:21:27 -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 l5K0LRaI026631; Wed, 20 Jun 2007 00:21:27 GMT 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.1830); Tue, 19 Jun 2007 17:21:27 -0700 Received: from [209.19.49.106] ([10.21.83.228]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:21:27 -0700 In-Reply-To: <4678709E.5030004@apnic.net> References: <77ead0ec0706182236ud60aa17g3bf68963c3c99202@mail.gmail.com> <4678709E.5030004@apnic.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77787422-93FA-40E7-BAEB-2349FF41F840@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt Date: Tue, 19 Jun 2007 17:21:25 -0700 To: Geoff Huston X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Jun 2007 00:21:27.0241 (UTC) FILETIME=[F12AE390:01C7B2D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1154; t=1182298887; x=1183162887; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Fwd=3A=20I-D=20ACTION=3Adraft-li-bgp-stabilit y-01.txt |Sender:=20; bh=5WkjNkSmq2Oum/DM7GAUfFe1d9xbhDTWkwQf4km1COM=; b=Mvro5g226UX/kDliY2NYlDW3SlWGVmOlWDEFit6UvoRBOYRITrT7pAUy/n3c+gSM9IHO+lzr Au8/+f12ybo+3RGi+/kpwzh7PWEIq8tu2CrZYYjexuqTvT+zg7W9W8ZdkwFHBXhC/BeriB+Oul yHbegJomIjabflO5780tphlj0=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: idr 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 Jun 19, 2007, at 5:11 PM, Geoff Huston wrote: > The numbers in section 4.3.1 were based on a data collection of the > entire set of BGP updates gathered from 1 April 2007 0000 UTC+1000 > until 1 May 2007 0000 UTC+1000, using a single eBGP feed from > AS4637 that provided a full route set to the data collector. AS4637 > has a footprint across Asia and parts of North America, as I > understand it, and it operates as a transit provider. > > The eBGP feed was from a Cisco router that (by default) used a 30 > second MRAI Timer. > > The data collection BGP engine was a Cisco router using an update > collection configuration via logging debug bgp updates through syslog. And I corroborated this data by examining the update logs from AS4637 from 24-May 2007 00:30 UTC to 6-Jun 2007 23:02 for the set of known, active beacon sites. The numbers in section 3.6 were also based on analysis of the beacon data set. Note that my analysis was independently formulated from Geoff's, so it's not only separate, non-intersecting data sets, it also is two completely independent implementations. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 15:44:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SZa-0000ku-Gf; Thu, 21 Jun 2007 15:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SZZ-0000ko-N7 for idr@ietf.org; Thu, 21 Jun 2007 15:44:05 -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 1I1SZY-0007Kw-Bx for idr@ietf.org; Thu, 21 Jun 2007 15:44:05 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2007 12:44:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACdyekarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="496609893:sNHT173838670" 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/8.12.11) with ESMTP id l5LJi1t9004545 for ; Thu, 21 Jun 2007 12:44:01 -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 l5LJi0ms022421 for ; Thu, 21 Jun 2007 19:44:01 GMT 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.1830); Thu, 21 Jun 2007 12:44:00 -0700 Received: from [171.71.55.99] ([171.71.55.99]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 12:44:00 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9E5380E8-8554-428E-B0CE-E9D6A94D276F@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: idr From: Tony Li Date: Thu, 21 Jun 2007 12:43:59 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 19:44:00.0816 (UTC) FILETIME=[83F38300:01C7B43C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=570; t=1182455041; x=1183319041; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Incoming=20discussion... |Sender:=20; bh=qu84otu6URyKrNIsCXg4t6i+V9BEqEhGPvAWVjkEGKE=; b=oHtOq53XsnmpC10sC1jKfOzQs6Pdu3cl4RJVBe1dH5Aw23mTdmZeMUZMH/TLb8/sXEMd8sqp h5j2bxtc750QzB9dXIAxkX1oeVy8ott9U+lRfq/8XQ15FlM5jJuZTDaN; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Idr] Incoming discussion... 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, The Routing Research Group mailing list has sprouted a discussion of BGP stability issues. With my RRG co-chair hat on, I've asked folks to redirect that discussion here. I believe it's appropriate because most of the discussion centers on questions about BGP semantics and tweaks to BGP. As part of doing this, you may see what appear to be fragments of conversations. For those interested in the earlier messages, the RRG archives can be found here: http://psg.com/lists/rrg/ Thanks for your patience and attention, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 16:03:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SsH-00006z-EA; Thu, 21 Jun 2007 16:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SsG-00006u-SG for idr@ietf.org; Thu, 21 Jun 2007 16:03:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SsG-0003fn-GP for idr@ietf.org; Thu, 21 Jun 2007 16:03:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2007 13:03:24 -0700 X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="169774354:sNHT48378834" 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/8.12.11) with ESMTP id l5LK3Nt8032270; Thu, 21 Jun 2007 13:03:23 -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 l5LK3Gmo009883; Thu, 21 Jun 2007 20:03:16 GMT 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.1830); Thu, 21 Jun 2007 13:03:16 -0700 Received: from [171.71.55.99] ([171.71.55.99]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 13:03:15 -0700 In-Reply-To: <467A97C0.8060708@firstpr.com.au> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <1182430311.467a7467c1ec7@webmail.nist.gov> <467A97C0.8060708@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70EF2922-C291-4BB3-86E6-F1029A6A22A5@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 21 Jun 2007 13:03:13 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 20:03:15.0887 (UTC) FILETIME=[346D5BF0:01C7B43F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2445; t=1182456203; x=1183320203; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RRG]=20Re=3A=20BGP=20path=20hunting, =20MRAI=20timer= 20and=20Path=20Length=20Damping |Sender:=20; bh=Hcz7vGrkmDrDt25kV9EWb17RmcX48wPrvQ1Pur83GXI=; b=aVa20j04W322NmfSBov6f4V+S2Na9SLavHI7i+YpVn9fKIeyVS33Fd2Jn2WXpT1FWh+T21GW cYt2b1ntvqfGqrkpYoH3u/cbaNy1E5OwQ12s+F2waBw44t+iToRBk5wNbgVwMkTtvWqrKaKmt7 eNKtvagzxYrXMjzNZseGpRuXs=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: idr , "K. Sriram" Subject: [Idr] Re: [RRG] Re: BGP path hunting, MRAI timer and Path Length Damping 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 Robin, On Jun 21, 2007, at 8:22 AM, Robin Whittle wrote: > The text you quoted was added to the I-D between February and > June 2002. > > I wonder if router behaviour really did change before January > 2006's RFC 4271. > > Tony, can you tell us the background for this change to the > scope of the MRAI timer? I imagine there was a strong reason, > since the removed text talks about avoiding long-lived > black-holes as being the reason to exempt withdrawals from the > MRAI delay system. No, I'm sorry, I wasn't paying close attention at the time, as I was focused elsewhere. Yes, having withdrawals subject to MRAI is sub- optimal because of the black-hole issue. Think about how this compounds as it transits numerous ASes. That said, implementing MRAI precisely per the spec turns out to be decidedly non-trivial. One significant complication is policy. After a BGP speaker completes its best path computation, it then proceeds to compute its updates to its neighbors. Policy may be applied at this point, and the BGP speaker may decide that it is not allowed to send its best path to one or more of its neighbors. However, it may also decide to advertise its best path to another set of its neighbors. Thus, the BGP speaker may not know whether or not it needs to send a withdrawal until after it has completed its best path selection and is doing update computation. This becomes awkward because if the MRAI does apply, then the speaker should start a timer for that prefix and for that particular set of neighbors. This gets complicated in a hurry, and can also consume a non-trivial amount of state. For this reason, I would not be surprised if implementations did not actually follow the letter of the spec and simply applied MRAI more broadly. > If that pattern is the sole or primary cause of "path hunting", > then it seems that this significant problem can be attributed to > the change in the BGP RFC, maybe the I-Ds which lead to it and > whatever decisions "one major router vendor" made around late 2000. No, it's only one cause. Path hunting is the result of diffractive wavefronts that affect both updates and withdraws. Please see our stability spec for some additional explanation, or come to the IDR meeting in Chicago and see our talk, complete with illustrations of path hunting behaviors. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 16:32:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TJy-00077K-V8; Thu, 21 Jun 2007 16:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TJy-00074o-4c for idr@ietf.org; Thu, 21 Jun 2007 16:32:02 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TJw-0005Gz-KE for idr@ietf.org; Thu, 21 Jun 2007 16:32:02 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 0A8F853F3EA; Thu, 21 Jun 2007 16:32:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id G5BnhtQCkA78; Thu, 21 Jun 2007 16:31:55 -0400 (EDT) Received: from [172.16.13.202] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id DAAD053E0FC; Thu, 21 Jun 2007 16:31:54 -0400 (EDT) In-Reply-To: <467A97C0.8060708@firstpr.com.au> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <1182430311.467a7467c1ec7@webmail.nist.gov> <467A97C0.8060708@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "John G. Scudder" Date: Thu, 21 Jun 2007 16:31:50 -0400 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: idr@ietf.org Subject: [Idr] Re: [RRG] Re: BGP path hunting, MRAI timer and Path Length Damping X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: idr@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org [replies directed to idr@ietf.org; rrg bcc'd] On Jun 21, 2007, at 11:22 AM, Robin Whittle wrote: > Tony, can you tell us the background for this change to the > scope of the MRAI timer? I imagine there was a strong reason, > since the removed text talks about avoiding long-lived > black-holes as being the reason to exempt withdrawals from the > MRAI delay system. Well I'm not Tony but a perusal of the IDR mailing list from 2002 quickly reveals the below message which introduces substantially the same text as is found in RFC 4271. In the cited text, Pedro argues that one cannot readily distinguish in BGP between "good news" and "bad news" and thus it makes no sense to treat withdraws differently. (N.b. the archive at ietf.org seems to only extend back to June 1, 2003. I've already suggested the IDR co-chairs look into this.) --John > To: idr@merit.edu > Subject: BGP4 -17 version > Date: Mon, 25 Mar 2002 07:31:31 -0800 > From: Yakov Rekhter > Sender: owner-idr@merit.edu > > Folks, > > In view of the last paragraph in the attached, how about if 9.2.1.1 > be replaced with the following: > > 9.2.1.1 Frequency of Route Advertisement > > The parameter MinRouteAdvertisementInterval determines the > minimum amount of time that must elapse between advertisement > and/or withdrawal of routes to a particular destination by a > BGP speaker to a peer. This rate limiting procedure applies on > a per-destination basis, although the value of > MinRouteAdvertisementInterval is set on a per BGP peer basis. > > Two UPDATE messages sent by a BGP speaker to a peer that advertise > feasible routes and/or withdrawal of unfeasible routes to some > common set of destinations MUST be separated by at least > MinRouteAdvertisementInterval. Clearly, this can only be achieved > precisely by keeping a separate timer for each common set of > destinations. This would be unwarranted overhead. Any technique > which ensures that the interval between two UPDATE messages sent > from a BGP speaker to a peer that advertise feasible routes > and/or withdrawal of unfeasible routes to some common set of > destinations will be at least MinRouteAdvertisementInterval, > and will also ensure a constant upper bound on the interval is > acceptable. > > Since fast convergence is needed within an autonomous system, > either (a) the MinRouteAdvertisementInterval used for internal > peers SHOULD be shorter than the MinRouteAdvertisementInterval > used for external peers, or (b) procedure describe in this > section SHOULD NOT apply for routes sent to internal peers. > > This procedure does not limit the rate of route selection, but > only the rate of route advertisement. If new routes are selected > multiple times while awaiting the expiration of > MinRouteAdvertisementInterval, the last route selected SHALL be > advertised at the end of MinRouteAdvertisementInterval. > > > ------- Forwarded Message > > Date: Tue, 05 Mar 2002 10:50:02 -0800 > From: Pedro Roque Marques > To: Alex Zinin > cc: > Subject: Re: RFC Violation > > Alex Zinin writes: > > > Pedro, > > > I see your point. Note that when you are sending a WITHDRAWN, you > > know it is a bad news. > > Alex, > A link up event will often cause a router to send withrawns as it > changes it's best path from one that it's policy and/or ibgp flooding > rules allow it to advertise to one that is rejected. > > The inverse is true for a link down event... > > I still maintain that it is not possible in BGP to distinguish if an > update corresponds to a link up/down event... or what information you > wish to send fast/slow. > > I also believe that it is a major mistake to threat advertisements > differently than withrawns, specially from a queuing/timing point of > view. The only thing you are going to get out of that is weird > blackholes and more instability... > > AFAIK, no major vendor implements their advertisement > rate-controller/queueing in a way as to threat updates and withrawns > differently. > > Pedro. > > ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 16:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMP-00020K-GJ; Thu, 21 Jun 2007 16:34:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMO-00020F-O6 for idr@ietf.org; Thu, 21 Jun 2007 16:34:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TMO-0006S6-Db for idr@ietf.org; Thu, 21 Jun 2007 16:34:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2007 13:34:32 -0700 X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="169794568:sNHT46452762" 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/8.12.11) with ESMTP id l5LKYVje016727; Thu, 21 Jun 2007 13:34:31 -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 l5LKYVXH018026; Thu, 21 Jun 2007 20:34:31 GMT 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.1830); Thu, 21 Jun 2007 13:34:31 -0700 Received: from [171.71.55.99] ([171.71.55.99]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 13:34:30 -0700 In-Reply-To: <20070621140029.5D0F386AE7@mercury.lcs.mit.edu> References: <20070621140029.5D0F386AE7@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 21 Jun 2007 13:34:29 -0700 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 20:34:30.0881 (UTC) FILETIME=[9202BD10:01C7B443] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2080; t=1182458071; x=1183322071; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RRG]=20Geoff=20Huston's=20article=20on=20BGP=20stabi lity,=20update=20statistics=20and=20damping |Sender:=20; bh=/bLxmmrhcpl9XFZcRkcN2l4HzD39NGtdGWyWKwpT8Z4=; b=Z4QCXsIkAL1lruvW4Mth6gSEm8UicTwx2QAxKtphCmYZjWbkV9qs4UINMc20i55Nl9laKlqC HtZCrXnVb+kM/HqZvaDsUYRvftaZlHh7g32cMuP+yQuBcj9tUDvvv4+j; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: idr Subject: [Idr] Re: [RRG] Geoff Huston's article on BGP stability, update statistics and damping 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 Noel, On Jun 21, 2007, at 7:00 AM, Noel Chiappa wrote: >> From: Robin Whittle > >> Geoff Huston has a new article "Damping BGP": > >> "... the busiest 1% of prefixes responsible for 24% of the routing >> updates for the month." > > While I agree that whatever's causing this ought to be fixed, there > are some > points we need to not lose sight of. > > First, fixing this would be a *one-time* improvement in the growth > curve for > the update rate (versus long-term time). I.e. you'd see a flat spot > (or a > drop) in the curve, after which it would resume its previous growth. Hopefully, we would see a flat spot, and then an actual decrease in the growth rate of churn. If we have a mechanism that truly is capable of reducing churn, and assuming that the amount of churn is proportional to the number of prefixes, then we should be able to reduce the update rate to truly reflect the topological events and the growth in number of prefixes. > Second, 25% is not peanuts, but it's also not an order of > magnitude, and > eliminating these wouldn't get us into a whole new operating > region. I don't > know what the current growth rate for BGP updates is, but if it's > anything > like the growth rate of the table itself (as one might reasonably > assume it > is), 25% is not a long calendar time. I believe that the point that we're making is that the churn rate is well _ABOVE_ the growth rate of the table new to new prefixes. The amplification of path hunting is a major contributor to unnecessary updates. > Again, it ought to be fixed, but let's not kid ourselves that this > is the > solution to our problems. No one was claiming that it was. As you may recall, we've identified two problems: a) the increase in the size of the table is giving us concern and b) the subsequent update rate seems to grow unreasonably even with respect to (a). The goal here is to attack only (b), and (a) is an entirely separate issue. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 17:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ToA-0005XY-0F; Thu, 21 Jun 2007 17:03:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1To8-0005XB-AF for idr@ietf.org; Thu, 21 Jun 2007 17:03:12 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1To3-0005mo-GJ for idr@ietf.org; Thu, 21 Jun 2007 17:03:12 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 21 Jun 2007 14:03:06 -0700 Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5LL35J09336; Thu, 21 Jun 2007 14:03:05 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <467AE787.706@juniper.net> Date: Thu, 21 Jun 2007 23:03:03 +0200 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Tony, In the text of section 3.4 I found the below when discussing how to differentiate if the prefix is from stub or from multihomed site. Unfortunately, it seems difficult to distinguish between stub prefixes and non-stub prefixes. To do so would seem to require require explicit annotation that could only be reasonably generated by manual configuration and would likely be incorrect. Wouldn't one way of automatically addressing this problem result in an extension to BGP where ASBR or RR when learning two disjoined paths for a given prefix automatically mark it with some new transitive attribute or well known community ? Once marked as such given prefix marking would not be removable .. pretty much just like ORIGINATOR is applied today by RRs for other purposes ? Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 18:05:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Ulz-0005pm-SN; Thu, 21 Jun 2007 18:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Uly-0005pg-GJ for idr@ietf.org; Thu, 21 Jun 2007 18:05:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Ulx-0007ui-53 for idr@ietf.org; Thu, 21 Jun 2007 18:05:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2007 15:04:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHKSekarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="5345611:sNHT15247470" 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/8.12.11) with ESMTP id l5LM4wu5008158; Thu, 21 Jun 2007 15:04:58 -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 l5LM4nms001790; Thu, 21 Jun 2007 22:04:58 GMT 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, 21 Jun 2007 15:04:54 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:04:54 -0700 In-Reply-To: <467AE787.706@juniper.net> References: <467AE787.706@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C18EB29-5A86-40F6-B2FA-84DD2EF3C74E@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt Date: Thu, 21 Jun 2007 15:04:53 -0700 To: raszuk@juniper.net X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 22:04:54.0485 (UTC) FILETIME=[32BB0850:01C7B450] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=769; t=1182463498; x=1183327498; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Fwd=3A=20I-D=20ACTION=3Adraft-li-bgp-stabilit y-01.txt |Sender:=20; bh=X0TjaRBiRv0j4DJ8txpwJuNcTH8cA/dV8hR4PSFjd28=; b=PH6DFiaXILxxDOgn7mEn25e8rwPsd71HXpTPP5eptx3a1wsFVlMPyD0wjiIHYLOkwBEFf7Mb tAwHp9L6oNuNrs/nWMOGxPfFQdeMVA2KKrKiRvSQRsBvjrJ5+FPndb1k; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: idr 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 Jun 21, 2007, at 2:03 PM, Robert Raszuk wrote: > Wouldn't one way of automatically addressing this problem result in an > extension to BGP where ASBR or RR when learning two disjoined paths > for > a given prefix automatically mark it with some new transitive > attribute > or well known community ? Once marked as such given prefix marking > would > not be removable .. pretty much just like ORIGINATOR is applied > today by RRs for other purposes ? Hi Robert, Interesting idea. I think you really mean that you want to have two different penultimate AS'es in the path. That's certainly a hint. What about domains that are dual-homed to the same provider? What happens when the alternate path is withdrawn? Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 18:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VL6-0002uG-Rj; Thu, 21 Jun 2007 18:41:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VL5-0002u2-4r for idr@ietf.org; Thu, 21 Jun 2007 18:41:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1VL3-000874-K1 for idr@ietf.org; Thu, 21 Jun 2007 18:41:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2007 15:41:06 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANObekarR7MVh2dsb2JhbACPJAIJDiw X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="163757753:sNHT670417821" 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/8.12.11) with ESMTP id l5LMf6qM029522; Thu, 21 Jun 2007 15:41: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 l5LMf1mo001200; Thu, 21 Jun 2007 22:41:01 GMT 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, 21 Jun 2007 15:41:01 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:41:01 -0700 In-Reply-To: <1182430311.467a7467c1ec7@webmail.nist.gov> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <1182430311.467a7467c1ec7@webmail.nist.gov> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 21 Jun 2007 15:40:59 -0700 To: ksriram@nist.gov X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 22:41:01.0093 (UTC) FILETIME=[3E212D50:01C7B455] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1057; t=1182465666; x=1183329666; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20BGP=20path=20hunting, =20MRAI=20timer=20and=20Path=20L ength=20Damping |Sender:=20; bh=UPFc5O4cWnh3HOHBfA/IObUXZ0tmbaXzGjV5xuSf+8U=; b=fLJzXgHa3FCkfrC9DLfeiCJm+iL1NVgNTbCbrVL6qZ1wIGFRUEV0hAKQ1GLmAbOPXolsgk0B qYsKjyL8GnoOqhA7B9oIDC4om9vJwDj7EQQLyMkMRECdDvXX9Na92AgSltE3EiAU8jMEjFSVNU RRkNA/DwKaQekLPouDKAdGO0E=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: idr , Robin Whittle Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping 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 Jun 21, 2007, at 5:51 AM, ksriram@nist.gov wrote: > Based on this one might infer that BGP routers have implemented > "not applying MRAI to withdrawals" for a fairly long time (prior to > RFC 4271). > To what extent have router vendors updated and deployed the MRAI > per RFC 4271 (so that MRAI does indeed apply to withdrawals)? > Tony: Can you please share with us your thoughts on this? I'm afraid that I can't claim to have a useful opinion. I can tell you that historically, certain implementations never implemented MRAI at all, and another implementation did a very simplistic implementation. However, my involvement at the development level basically stopped in 1994, except for a very brief stint in 2005. It would be far more accurate if the current maintainers of implementations were to step up and describe the behavior of their implementations currently. Yes, I realize that there are competitive pressures that work against this, so some may be understandably reluctant. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 18:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VPx-0005Ik-TX; Thu, 21 Jun 2007 18:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VPw-0005If-Id for idr@ietf.org; Thu, 21 Jun 2007 18:46:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1VPv-0007te-7h for idr@ietf.org; Thu, 21 Jun 2007 18:46:20 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2007 15:46:04 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAP6cekarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="5364526:sNHT4110927588" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5LMk3uk032400; Thu, 21 Jun 2007 15:46:03 -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 l5LMjwvv011137; Thu, 21 Jun 2007 22:45:58 GMT 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.1830); Thu, 21 Jun 2007 15:45:58 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:45:58 -0700 In-Reply-To: References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 21 Jun 2007 15:45:57 -0700 To: "John G. Scudder" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 22:45:58.0392 (UTC) FILETIME=[EF556780:01C7B455] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=576; t=1182465963; x=1183329963; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RRG]=20BGP=20path=20hunting, =20MRAI=20timer=20and=20 Path=20Length=20Damping |Sender:=20; bh=gOaN5PIl7XaLMYBBfPJSHKPtW7xSXcdHpqzPFZ7Btl0=; b=sJ5+I5zcAuQrQgPprVkWs7blBcJ0zL9tgDZmQLQVOmscp+0lWIAzX4NfK7FsvhwT8hEEnL4Z DXUHkU6VuNybJXYreRJNnUEop5POzRXfIf0FtqATeFyjss1WcaG7U2JQ; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: idr , Robin Whittle , "K. Sriram" Subject: [Idr] Re: [RRG] BGP path hunting, MRAI timer and Path Length Damping 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 Jun 21, 2007, at 5:24 AM, John G. Scudder wrote: > On Jun 21, 2007, at 4:39 AM, Robin Whittle wrote: >> Here is my understanding, based on Geoff's diagram and Tony's >> written explanation. Is there a better explanation somewhere? > [of path hunting] > > "Delayed Internet routing convergence" by Labovitz, Ahuja, Bose and > Jahanian. (IEEE/ACM Transactions on Networking, June 2001. A > version appeared in the SIGCOMM 2000 proceedings also I think.) More accessible as: http://www.cs.toronto.edu/syslab/courses/csc2209/06au/papers/bgp.pdf Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 18:55:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VYy-0006H0-VW; Thu, 21 Jun 2007 18:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VYx-0006Gl-JQ for idr@ietf.org; Thu, 21 Jun 2007 18:55:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1VYs-0000uU-5d for idr@ietf.org; Thu, 21 Jun 2007 18:55:39 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 21 Jun 2007 15:46:19 -0700 X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="23004750:sNHT520562812" Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5LMkFJ40652; Thu, 21 Jun 2007 15:46:16 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <467AFFB5.6090904@juniper.net> Date: Fri, 22 Jun 2007 00:46:13 +0200 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt References: <467AE787.706@juniper.net> <5C18EB29-5A86-40F6-B2FA-84DD2EF3C74E@cisco.com> In-Reply-To: <5C18EB29-5A86-40F6-B2FA-84DD2EF3C74E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Tony, > Interesting idea. I think you really mean that you want to have two > different penultimate AS'es in the path. That's certainly a hint. Yes that was the scenario I had in mind. > What about domains that are dual-homed to the same provider? Wouldn't that provider in most cases mask the immediately connected to the end AS link failure within his own AS ? I think we could treat those therefor as stub in the bigger picture of the 3.4 proposal. > What happens when the alternate path is withdrawn? I think we could solve that with some long enough timer ... if the alternate path is withdrawn for sufficiently long time the non-stub site becomes stub by the ASBR/RR which did the original marking or has had all the info to be a marker candidate. Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jun 21 19:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1W4G-0004tK-H9; Thu, 21 Jun 2007 19:28:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1W4F-0004tF-LV for idr@ietf.org; Thu, 21 Jun 2007 19:27:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1W4E-0006h6-2d for idr@ietf.org; Thu, 21 Jun 2007 19:27:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2007 16:27:57 -0700 X-IronPort-AV: i="4.16,449,1175497200"; d="scan'208"; a="169875042:sNHT56386791" 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/8.12.11) with ESMTP id l5LNRvkl023407; Thu, 21 Jun 2007 16:27:57 -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 l5LNRuka016693; Thu, 21 Jun 2007 23:27:56 GMT 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.1830); Thu, 21 Jun 2007 16:27:56 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 16:27:55 -0700 In-Reply-To: <467A393E.7040106@firstpr.com.au> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 21 Jun 2007 16:27:54 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Jun 2007 23:27:55.0811 (UTC) FILETIME=[CBD50F30:01C7B45B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6067; t=1182468477; x=1183332477; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20BGP=20path=20hunting, =20MRAI=20timer=20and=20Path=20L ength=20Damping |Sender:=20; bh=s2iZRk4R9QdDywmJk0zihzfz+jQ7wByMxJFHoPkiafs=; b=AY0sP9V6UtTb2Qcpmh53x+9kgk/8iTy2QB12Lm/lA8qSXeAwXSj0MGrn4MneFEpU5cNEW2vP UWLD/P78xtoBdPHZ72IbYwhRldvYTi574J7b1djpV4LOSaIfCgGhBfRf; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: idr , "K. Sriram" Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping 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 Robin, On Jun 21, 2007, at 1:39 AM, Robin Whittle wrote: > Tony, can you advise on this? Anyone else? I'll try. > Geoff's diagram : > > http://www.potaroo.net/ispcol/2007-06/dampbgp.html > > explains the pattern of behavior which results in a series of > longer best-path messages emanating out from the local part of > the network, followed by a withdrawal. > > I am not sure about the time elapsed between the four sections > of Fig 1, which I will call A, B, C and D. The first thing to understand is that there is no absolute standard of time in any of this. BGP (and routers in general) are 'soft' real- time systems. That is, given a task to do, they will get around to it, but it will frequently be a 'best effort' approach, and not scheduled to a precise moment. Other computations within the protocol and outside of the protocol in other management functions may cause significant time variances in event latency. > Here is my understanding, based on Geoff's diagram and Tony's > written explanation. Is there a better explanation somewhere? > > A This is the steady state before T = 0.0, when (2) detects > that its link to (1) goes down. We should note that at this point, AS 5 should have paths as follows: 2: 2 1 3: 3 2 1 4: 4 3 2 1 > B, sort of . . . > > T = 0.1 secs > > (2) sends withdrawals to (5) and (3). > > This is almost immediately after the link goes down - say > a 0.1 second processing time after (2) determines that (1) > is unreachable. This is the time it takes to generate two > withdrawal announcements. Again, this would be ideal... Reality is that you have asynchronous systems, updates are not computed simultaneously, and can be delayed for a variety of reasons. > (3) gets the withdrawal too. This is where my understanding > departs from the diagram. In B, (5) has sent an > announcement but 3 hasn't. I figure they would typically > send their announcements at about the same time. Recall 5's path table from above. After processing the update from (2), it's path table should look like: 3: 3 2 1 4: 4 3 2 1 Since 5 and 3 are not synchronized at all, there's a significant race between the withdrawal from 3 and the advertisement of "5 3 2 1" by (5). > In my understanding, at 0.1 seconds, both (5) and (3) have > been sent the withdrawal from (2) but have not yet processed > them. In figure B, we see (5) advertising its alternate path. It has processed the withdrawal from 2, but not processed the to-be- delivered withdrawal from 3. > In my understanding, there is no strung out sequence of longer > and longer paths being announced by 5, as Geoff's diagram > depicts. Just the first announcement at T = 0.1s of a longer > path, followed by a withdrawal at T = 30.2 seconds. This does > not really resemble the "path hunting" pattern Geoff and Tony > refer to. First, that is *exactly* path hunting. You're assuming that 5 implements MRAI and doing so fairly precisely. If 5 does not implement MRAI, you'd see exactly the set of updates in Geoff's diagram. > My understanding of what Geoff writes is that "path hunting" > occurs anyway, and is exacerbated in variations in the time > constant of the Minimum Route Advertisement Interval (MRAI) > Timer. I am not sure if these are small variations of fractions > of a second from the default 30 seconds, or some other default > or configured values such as 20 to 50 seconds. I don't see how > various values of MRAI in different routers would affect my > explanation of what happens in the situation depicted by Geoff's > diagram, other than to change the delay time to 20.2 or 50.2 > seconds, for instance. You just need a slightly richer topology to create more interesting race conditions. > II guess this would need to replace the MRAI timer's function, or > operate with longer time constants than that timer, but I don't > think Tony's I-D mentions this. The assumption was that this would subsume MRAI. > This sounds like a great idea. I understand that when applied > to Geoff's diagram, here is what would happen, assuming for the > moment that there was no MRAI timer: > > T = 0.1 seconds > > (2) sends withdrawals to (5) and (3). > > > T = 0.2 seconds. > > (5) gets (2)'s withdrawal and does not announce anything, > since its best path "3, 2, 1" is now longer than before, > and Tony's (Geoff's?) PLD algorithm is invoked. Exact ownership of the algorithm isn't clear to me. It's been kicked around a bit and I thought I heard of it from someone, but I checked with them and they denied it. In any case, I'll explicitly relinquish any claim to it. I'm much more interested in getting it deployed... > So with this PLD algorithm, as I understand it, there is only > one message sent by (5), and it is the correct one, sent at 0.4 > seconds, not at 30.2 seconds as with current arrangements. Sounds right. > Tony, you co-wrote the RFC - what do you think? Co-edited and really just for 1771. As always, I think that the RFC is a fine goal, and that implementors frequently take short cuts that may or may not be warranted. I'm not throwing rocks at them because frankly, many of those rocks would end up back in my lap. As I noted earlier, implementing MRAI per the letter of the spec is non-trivial, and I sympathize with those who decided not to implement it. On the flip side, I'm also leery of having a system that has no built-in protections against persistent, rapid oscillation. If there are no protections built in, then some poor network operator will be awakened at 4am with a router that is melting down under the update load. I've done that too and wouldn't wish that on anyone. Thus, I think we have a responsibility to provide a better set of mechanisms. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 22 04:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eUs-00032z-BV; Fri, 22 Jun 2007 04:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eUr-0002yy-09 for idr@ietf.org; Fri, 22 Jun 2007 04:28:01 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1eUm-0007Rc-RO for idr@ietf.org; Fri, 22 Jun 2007 04:28:00 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id EFAD859DDD; Fri, 22 Jun 2007 18:27:54 +1000 (EST) Message-ID: <467B8800.7030609@firstpr.com.au> Date: Fri, 22 Jun 2007 18:27:44 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: idr , "John G. Scudder" References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: Tony Li , "K. Sriram" Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping 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 Tony, Thanks for your response. My knowledge of BGP is shallower than probably everyone on this list. I hope to understand BGP and the behavior of the BGP system better. Maybe I can contribute some useful ideas or provoke helpful discussion. I am glad to have worked out those examples and found what you define as "path hunting": >> In my understanding, there is no strung out sequence of longer >> and longer paths being announced by 5, as Geoff's diagram >> depicts. Just the first announcement at T = 0.1s of a longer >> path, followed by a withdrawal at T = 30.2 seconds. This does >> not really resemble the "path hunting" pattern Geoff and Tony >> refer to. > > First, that is *exactly* path hunting. with the qualification that actual behavior varies a lot due to timing variations, topology, router implementation details, configuration etc. I also understand that the term "path hunting" extends to the broader patterns which resemble reverberation in acoustics - of series of typically longer-path announcements for a prefix, often at about 30 second intervals, which are later followed by a withdrawal. Your I-D also states that "path hunting" occurs when a prefix is first advertised, but that seems pretty natural and hard to prevent. I don't think this would be as destructive as the MRAI timer holding back a withdrawal for 30 seconds just after an AA+ has been sent. "Path hunting" after a first advertisement is a consequence of the path-vector protocol. Maybe your proposed Path Length Damping would be marginally effective at reducing the propagation of sub-optimal "best paths" sometimes before the final, stable, optimal "best path", by expediting the announcements of shorter paths and withdrawals, and delaying longer path announcements. > The assumption was that this would subsume MRAI. I am reading the second version of your ID now: http://tools.ietf.org/html/draft-li-bgp-stability and I see Geoff is a co-author and that you have a section "Deprecate MRAI". Perhaps you could add to the "Path Hunting" section the history of the MRAI timer's changing specification - as discussed in the last day or so - and the statement from 2002 that few router vendors implemented the RFC 1771 version of it. Does the apparent failure of Flap Damping coincide with the general change from (I guess) late 1990s MRAI compliance with RFC 1771 to the problematic RFC 4271 mode of also stopping withdrawals? I think it would also be helpful to add minimal example of the mechanism, as I tried to work it out for single and multiple systems. All that is needed is: (3) (6) / \ / \ / \ / \ Upstream (1)--X--(2)---(4)---(5)---(7)---> routers to show how it generates a prompt AA+, a 30 second delayed A++ and a 60 second delayed withdrawal. Also, I could show how the new algorithm would result in a much better outcome. I can write a concise account of this, for an appendix of your I-D if you like. I would base it on the exact timings as I did before, but add the qualification that in reality, timings would not be so exact, but the behavior would be broadly similar. >From the 01 version of your and Geoff's I-D: (39% of activity involves a pair of updates inside 31 seconds.) Only 28% of the updates for the month are not part of any sequence, while 26% of updates are part of a coupled update pair, and 46% of updates are part of sequences of 3 or more updates. So more than 2/3 of activity is seems clearly to be associated with delays caused by the MRAI timer in a small triangle of routers/ASes, or in more complex mesh structures. Getting rid of that mechanism would greatly reduce the burden of messages and speed up the propagation of withdrawals. Sequences of multiple messages might be replaced by a single message, which is more informative, and propagates quickly. > Exact ownership of the algorithm isn't clear to me. It's been > kicked around a bit and I thought I heard of it from someone, > but I checked with them and they denied it. In any case, I'll > explicitly relinquish any claim to it. I'm much more > interested in getting it deployed... Now I understand from messages on this list that the MRAI function is typically not implemented in a way which lets through withdrawals quickly, and looking at Geoff's analysis, it seems to me that some changes as you suggest would make a really significant reduction in message volumes and convergence time. > As I noted earlier, implementing MRAI per the letter of > the spec is non-trivial, and I sympathize with those who > decided not to implement it. On the flip side, I'm also > leery of having a system that has no built-in protections > against persistent, rapid oscillation. If there are no > protections built in, then some poor network operator will > be awakened at 4am with a router that is melting down under > the update load. I've done that too and wouldn't wish that > on anyone. I entirely agree, and unless something is done, the rising tide of prefixes and delayed, reverberated, unnecessary AA+ messages, with the much delayed withdrawals, will swamp all existing transit and multihomed border routers. All Internet users collectively pay for running and replacing these routers. > Thus, I think we have a responsibility to provide a better set > of mechanisms. Yes, but it seems to me the old RFC 1771 had a much better MRAI specification than what router vendors were generally implementing by 2002 or so, and better than is mandated by RFC 4271. Thanks John for the excerpt from the IDR list archives. >> Date: Tue, 05 Mar 2002 10:50:02 -0800 >> From: Pedro Roque Marques >> >> Alex Zinin writes: >> >> > Pedro, >> >> > I see your point. Note that when you are sending a >> > WITHDRAWN, you know it is a bad news. >> >> Alex, >> >> A link up event will often cause a router to send withrawns >> as it changes it's best path from one that it's policy and/or >> ibgp flooding rules allow it to advertise to one that is >> rejected. >> >> The inverse is true for a link down event... I don't understand these statements enough to criticise them. >> I still maintain that it is not possible in BGP to >> distinguish if an update corresponds to a link up/down >> event... or what information you wish to send fast/slow. I am a newbie to BGP, but the behavior of path length hunting is a major burden on all the routers, so I think that while the above statement may have some theoretical truth to it, the practical situation is that delaying the withdrawals is more more trouble than it is worth. >> I also believe that it is a major mistake to treat >> advertisements differently than withrawns, specially from a >> queuing/timing point of view. The only thing you are going to >> get out of that is weird blackholes and more instability... This is written by someone who presumably knows far more about BGP than I do, but I don't see why this would be true. >> AFAIK, no major vendor implements their advertisement >> rate-controller/queueing in a way as to threat updates and >> withrawns differently. >> >> Pedro. Lets say we have 500,000 prefixes. Do we have a single down counter for each prefix? I guess so. As far as I know, the same announcements go to all peers. This is a major challenge to implement. It is either a massive number of downcounters each with its own pointers to whatever it affects, or some kind of linked list of events to remember in the future, which could get very long, and would require tricky methods to take things out of and to incrementally chew through and take action upon as time passes by. There would never be 500,000 timers active at once, so maybe it could be implemented by having a pool of downcounters, say a few thousand, which are used by the first instances which need them and which are returned to the pool once they time out or no longer needed. Maybe there could be 4,000 down counters and each instance which wanted another down counter when the 4,000 are all busy would have its details and a time-stamp put into a queue. That would function as a timer and from the point of view of each instance. (However, then clearing the timer means finding the pointer in he queue and setting it to zero.) The end of the timer period would be when its pointer appeared at the exit of the queue. The router wouldn't bother emptying that queue while it was so busy as to be running 4,000 MRAI-like down-counters, which would only be for brief periods. Then there is the question of each router's message queue to each peer being throttled via TCP, with the software being able to find messages in the queue and delete them if something else happens after they were put in the queue. It seems there is now general agreement that Path Length Damping is a worthwhile goal. This is a slightly fancier version of the old (RFC 1771) MRAI specification. Yet by 2002, we are told that Cisco, Juniper et. al. had given up on following RFC 1771's strict instructions to exempt withdrawals from the MRAI mechanism. They presumably didn't do this lightly. I guess it was either that the cost of fully implementing RFC 1771's MRAI spec was either prohibitive, considering all the other things the CPU is trying to do - and/or that some engineers had already decided that there was little or no value in treating withdrawals differently from advertisements of feasible paths. Now the cost of this simplification in implementations - now mandated by the RFC 4271 - is either unacceptable or so costly that the simple MRAI function needs to be replaced by something fussier. CPUs and memories of newer routers have become faster, so maybe it is easier now to have the more complex MRAI-like timer. On the other hand, there are now far more prefixes and maybe more peers it has to be implemented for. Implementing a more complex MRAI-like timer in new firmware upgrades to older routers may be prohibitive. So I guess the trick is to find the simplest solution which will solve the problem. Here are my thoughts on the various algorithms: RFC 1771 MRAI ------------- Data: "most recently sent update" "most recent update not yet announced" Timer down counter [ Is update a [ withdrawal? Yes: Announce immediately and clear the counter. [ Write it to "most recently sent update". [ [ No: Counter set? No: Announce update, save it as "most recently sent update" and set timer to count down. Yes: Store update in "most recent update not yet announced". When timer counts down: If "most recent update not yet announced" differs from "most recently sent update", then announce "most recently received update not yet announced" and write this to "most recently sent update". RFC 4271 MRAI ------------- This is the same as the above, minus the first section marked with '['. This is simpler logic, but I don't see that it involves any less state than the RFC 1771 version. Path Length Damping ------------------- Data: "most recently sent update" "most recent update not yet announced" Integer: "previously announced update length" Timer down counter Update: (Treat withdrawal as having zero length.) Compare this update's length with "previously announced update length". Write this update's length to "previously announced update length". Was new update longer? Longer: Write it to "most recent update not yet announced". Set timer to count down. Same or shorter: Send update, write it to "most recently sent update" and clear counter. When timer counts down: Announce "most recently received update not yet announced" and write this to "most recently sent update". This requires storing an extra 16 bit integer for each prefix on each interface. I can't think of a simpler solution. I don't know enough about routers to estimate the real implementation costs of these, but I don't see why there was such resistance to implementing the RFC 1771 MRAI timer. It would be interesting to know what the difficulty was - because those difficulties may still be important and might prevent the adoption of Path Length Damping or some other mechanisms as your I-D suggests. By the way, I have a web page pointer to this discussion, which started on the RRG list and moved to here at the IDR list: http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_hunting_MRAI_disc and am trying to maintain a set of papers and proposals regarding improvements to BGP, and analysis of its problems: http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_improvements The list starts with this I-D. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jun 22 10:29:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k82-00019f-HK; Fri, 22 Jun 2007 10:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k81-00015b-CH for idr@ietf.org; Fri, 22 Jun 2007 10:28:49 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1k80-0004qQ-20 for idr@ietf.org; Fri, 22 Jun 2007 10:28:49 -0400 Received: from pc6 (1Cust5.tnt29.lnd3.gbr.da.uu.net [62.188.120.5]) by ranger.systems.pipex.net (Postfix) with SMTP id 04005E00023C; Fri, 22 Jun 2007 15:28:43 +0100 (BST) Message-ID: <002201c7b4d0$a2f968c0$0601a8c0@pc6> From: "tom.petch" To: "Tony Li" , References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net><1182338421.46790d755a0ac@webmail.nist.gov><467A393E.7040106@firstpr.com.au><1182430311.467a7467c1ec7@webmail.nist.gov> Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Date: Fri, 22 Jun 2007 12:29:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: idr X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org You could also look at RFC4276, the BGP4 implementation report, which gives some details for four implementations. Tom Petch ----- Original Message ----- From: "Tony Li" To: Cc: "idr" ; "Robin Whittle" Sent: Friday, June 22, 2007 12:40 AM Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping > > On Jun 21, 2007, at 5:51 AM, ksriram@nist.gov wrote: > > > Based on this one might infer that BGP routers have implemented > > "not applying MRAI to withdrawals" for a fairly long time (prior to > > RFC 4271). > > To what extent have router vendors updated and deployed the MRAI > > per RFC 4271 (so that MRAI does indeed apply to withdrawals)? > > Tony: Can you please share with us your thoughts on this? > > > I'm afraid that I can't claim to have a useful opinion. > > I can tell you that historically, certain implementations never > implemented MRAI at all, and another implementation did a very > simplistic implementation. However, my involvement at the > development level basically stopped in 1994, except for a very brief > stint in 2005. > > It would be far more accurate if the current maintainers of > implementations were to step up and describe the behavior of their > implementations currently. Yes, I realize that there are competitive > pressures that work against this, so some may be understandably > reluctant. > > Regards, > Tony > > _______________________________________________ > 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 Jun 22 13:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mp1-0006ty-0t; Fri, 22 Jun 2007 13:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1moz-0006lX-D9 for idr@ietf.org; Fri, 22 Jun 2007 13:21:21 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mou-0004FM-OE for idr@ietf.org; Fri, 22 Jun 2007 13:21:21 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id EF4FF53E0FC; Fri, 22 Jun 2007 13:21:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id qb5SvUl2xX1I; Fri, 22 Jun 2007 13:21:03 -0400 (EDT) Received: from [172.16.13.202] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 2309A53F3EB; Fri, 22 Jun 2007 13:21:03 -0400 (EDT) In-Reply-To: <467B8800.7030609@firstpr.com.au> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: "John G. Scudder" Date: Fri, 22 Jun 2007 13:20:55 -0400 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Tony Li , idr , "K. Sriram" Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping 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: , Content-Type: multipart/mixed; boundary="===============0134358209==" Errors-To: idr-bounces@ietf.org --===============0134358209== Content-Type: multipart/alternative; boundary=Apple-Mail-4-214708968 --Apple-Mail-4-214708968 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Robin, On Jun 22, 2007, at 4:27 AM, Robin Whittle wrote: ... >>> Date: Tue, 05 Mar 2002 10:50:02 -0800 >>> From: Pedro Roque Marques ... >>> I still maintain that it is not possible in BGP to >>> distinguish if an update corresponds to a link up/down >>> event... or what information you wish to send fast/slow. > > I am a newbie to BGP, but the behavior of path length hunting is > a major burden on all the routers, so I think that while the > above statement may have some theoretical truth to it, the > practical situation is that delaying the withdrawals is more > more trouble than it is worth. The above statement is not only theoretically true, it is also true in a practical sense. Perhaps an example will help. Consider the following very common scenario: P1--AS--P2 | / | |/ | C1 C2 AS connects to two peer ASes, P1 and P2. AS provides service to multi-homed customer C1, and transit customer C2. Normally, AS will reach C1 through the (C1, AS) link, and will advertise C1 reachability to P1, P2 and C2. Similarly, P1 will reach C1 through (C1, P1) and will advertise C1 reachability to AS. If (C1, AS) goes down, AS will reach C1 through P1. Due to policy, AS will not advertise this path to P2, and will advertise it to C2. Thus, one "bad news" event (the (C1, AS) link down) has been turned into an update with replacement route to one peer (C2) and an update with withdraw to two others (P1 and P2). Note that this scenario uses perfectly common types of BGP peering relationships and policies. --John --Apple-Mail-4-214708968 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Robin,

On Jun 22, 2007, at 4:27 = AM, Robin Whittle wrote:
...
Date:=A0 =A0 Tue, 05 Mar 2002 10:50:02 -0800
=
From:=A0 =A0 Pedro Roque Marques <roque@juniper.net>
...
=
I still maintain that it is not possible in BGP = to
distinguish if an update corresponds to a link = up/down
event... or what information you wish to send = fast/slow.

I am a = newbie to BGP, but the behavior of path length hunting is
a = major burden on all the routers, so I think that while the
=
above statement may have some theoretical truth to it, the
=
practical situation is that delaying the withdrawals is more
=
more trouble than it is worth.
=

The above statement is not only = theoretically true, it is also true in a practical sense.=A0 Perhaps an = example will help.=A0 Consider the following very common = scenario:

P1--AS--P2
=A0| / = |
=A0|/= =A0 |
C1=A0 C2

AS connects to two peer = ASes, P1 and P2.=A0 AS provides service to multi-homed customer C1, and = transit customer C2.

Normally, AS will reach C1 = through the (C1, AS) link, and will advertise C1 reachability to P1, P2 = and C2.=A0 Similarly, P1 will reach C1 through (C1, P1) and will = advertise C1 reachability to AS.

If (C1, AS) goes down, AS = will reach C1 through P1.=A0 Due to policy, AS will not advertise this = path to P2, and will advertise it to C2.=A0 Thus, one "bad news" event = (the (C1, AS) link down) has been turned into an update with replacement = route to one peer (C2) and an update with withdraw to two others (P1 and = P2).

Note = that this scenario uses perfectly common types of BGP peering = relationships and policies.

--John
= --Apple-Mail-4-214708968-- --===============0134358209== 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 --===============0134358209==-- From idr-bounces@ietf.org Fri Jun 22 17:02:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qGW-0001VJ-Sr; Fri, 22 Jun 2007 17:02:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qGU-0001UI-Oh for idr@ietf.org; Fri, 22 Jun 2007 17:01:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qGS-0003Ef-4C for idr@ietf.org; Fri, 22 Jun 2007 17:01:58 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 22 Jun 2007 14:01:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOLVe0arR7MVh2dsb2JhbACPJgIJDiw X-IronPort-AV: i="4.16,452,1175497200"; d="scan'208"; a="163903479:sNHT31633893" 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/8.12.11) with ESMTP id l5ML1pUg009677; Fri, 22 Jun 2007 14:01:51 -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 l5ML1dn0017470; Fri, 22 Jun 2007 21:01:40 GMT 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, 22 Jun 2007 14:01:28 -0700 Received: from [171.71.55.99] ([171.71.55.99]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 14:01:28 -0700 In-Reply-To: <467B8800.7030609@firstpr.com.au> References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B079921-73F4-4909-8CAC-83E85E58F90C@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Fri, 22 Jun 2007 14:01:25 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Jun 2007 21:01:28.0061 (UTC) FILETIME=[805692D0:01C7B510] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6569; t=1182546111; x=1183410111; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20BGP=20path=20hunting, =20MRAI=20timer=20and=20Path=20L ength=20Damping |Sender:=20; bh=ig/opGKKHUg4LMA6uLSkbdUhCG4lB61MJlTTVRDiEvU=; b=eMztRt5DfdicoVrDn/5nCERpJ8r0DU+YyQ7C7ZmurPCvtMHu+R5ejcdm494dm37ARXnhdY6G ugRLOjbAmjA84YVjY4P4foUmAv4yTX70EYcKXQHxSii+X3ELE5+OUpu2WWrDjnBQDvikPZ+yJa 9Ulh5NXHWigp4pWvqqUrcN3aU=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: idr , "K. Sriram" Subject: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping 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 Robin, > Your I-D also states that "path hunting" occurs when a prefix is > first advertised, but that seems pretty natural and hard to > prevent. Please read the rest of the draft. ;-) > I don't think this would be as destructive as the MRAI > timer holding back a withdrawal for 30 seconds just after an AA+ > has been sent. MRAI is simply one other cause of diffraction, resulting in path hunting and more unnecessary messaging. > "Path hunting" after a first advertisement is a consequence of > the path-vector protocol. Maybe your proposed Path Length > Damping would be marginally effective at reducing the > propagation of sub-optimal "best paths" sometimes before the > final, stable, optimal "best path", by expediting the > announcements of shorter paths and withdrawals, and delaying > longer path announcements. Please read the rest of the draft. ;-) In particular the sections on optimal path damping and delayed best path selection. > So more than 2/3 of activity is seems clearly to be associated > with delays caused by the MRAI timer in a small triangle of > routers/ASes, or in more complex mesh structures. Your assumption here seems to be that all delays are due to MRAI. That seems highly unlikely. MRAI just gives larger delays. There are others that are of influence as well. > Getting rid > of that mechanism would greatly reduce the burden of messages > and speed up the propagation of withdrawals. Sequences of > multiple messages might be replaced by a single message, which > is more informative, and propagates quickly. Exactly why some implementations have taken that path. >>> I also believe that it is a major mistake to treat >>> advertisements differently than withrawns, specially from a >>> queuing/timing point of view. The only thing you are going to >>> get out of that is weird blackholes and more instability... > > This is written by someone who presumably knows far more about > BGP than I do, but I don't see why this would be true. Yes, Pedro knows a good bit about BGP. I put high value on his opinion. To understand his perspective, I think you also need to consider cases where there are link failures within a more meshed topology. Rapid propagation of withdrawals (bad news) and slow propagation of alternate paths (good news) means that convergence to alternate paths will go through unnecessary churn. For example, the withdrawal might rapidly propagate up past the point where the alternate path would come into play and result in a blackhole while the alternate path information slowly catches up. As these are the cases where you really would like to converge quickly, this is problematic. >>> AFAIK, no major vendor implements their advertisement >>> rate-controller/queueing in a way as to threat updates and >>> withrawns differently. > > Lets say we have 500,000 prefixes. Do we have a single down > counter for each prefix? I guess so. As far as I know, the > same announcements go to all peers. This is fundamentally incorrect. Policy is peer specific. > This is a major challenge to implement. It is either a massive > number of downcounters each with its own pointers to whatever it > affects, or some kind of linked list of events to remember in > the future, which could get very long, and would require tricky > methods to take things out of and to incrementally chew through > and take action upon as time passes by. > > There would never be 500,000 timers active at once, so maybe it > could be implemented by having a pool of downcounters, say a few > thousand, which are used by the first instances which need them > and which are returned to the pool once they time out or no > longer needed. It's not particularly hard to set up a router that has multiple copies of the full routing table, prefers only one of them, and then has all of the preferred routes withdrawn. So, yes, you need to provision for all 500,000 timers. This assumes you're willing to bound your implementation to that number. FWIW, that number is no longer competitive and would need to be more like 1-2M. Certain folks seem to already be claiming 10M. > Then there is the question of each router's message queue to > each peer being throttled via TCP, with the software being able > to find messages in the queue and delete them if something else > happens after they were put in the queue. Removing messages after they are placed into the TCP stream is not a practical approach. Once the message has been played out of BGP and into the TCP socket, it is quite effectively "gone". The best that a BGP implementation can do is to ensure that it has filled the socket and not computed too many additional messages. Such messages would have to be explicitly buffered in BGP, which is expensive. It's far more effective to simply not compute updates faster than they are consumed and leave the data in BGP's internal data structures. > Yet by 2002, we are told that Cisco, Juniper et. al. had given > up on following RFC 1771's strict instructions to exempt > withdrawals from the MRAI mechanism. You're assuming that they complied with it in the first place. > They presumably didn't do this lightly. True, but they didn't spend eons thinking about the problem either. > Now the cost of this simplification in implementations - now > mandated by the RFC 4271 - is either unacceptable or so costly > that the simple MRAI function needs to be replaced by something > fussier. > > CPUs and memories of newer routers have become faster, so maybe > it is easier now to have the more complex MRAI-like timer. On > the other hand, there are now far more prefixes and maybe more > peers it has to be implemented for. The problem has not gotten easier. > Implementing a more complex MRAI-like timer in new firmware > upgrades to older routers may be prohibitive. > > So I guess the trick is to find the simplest solution which will > solve the problem. Isn't it always? ;-) > It would be interesting to know what the difficulty was - > because those difficulties may still be important and might > prevent the adoption of Path Length Damping or some other > mechanisms as your I-D suggests. Rather than 'difficulty', I would say that developers made the judgement call that the cost/benefit ratio was unacceptable. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Jun 23 03:59:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I20Wt-0005vR-NW; Sat, 23 Jun 2007 03:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I20Ws-0005vJ-6I for idr@ietf.org; Sat, 23 Jun 2007 03:59:34 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I20Wp-0000nx-Mq for idr@ietf.org; Sat, 23 Jun 2007 03:59:34 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id C860459E3D; Sat, 23 Jun 2007 17:59:26 +1000 (EST) Message-ID: <467CD2D4.20700@firstpr.com.au> Date: Sat, 23 Jun 2007 17:59:16 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: idr Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping References: <467799C6.3020302@firstpr.com.au> <4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> In-Reply-To: <467B8800.7030609@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: Tony Li , Noel Chiappa , "K. Sriram" 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 very much Tony, Geoff, John, Tom, Noel, Ricardo and Sriram. The Internet's routing and addressing system has trouble coming as surely as a freight train or a rising flood. I came to the RAM list asking questions and offering ideas, recognising I was a newbie. This lead me via the RRG and now to the home of those who build and try to improve BGP - the IDR mailing list. Here I sit asking difficult questions and receiving good answers from The Elders - on why the BGP mountain really can't be moved very much, or at least nowhere near enough that a new architecture will not be needed soon. I accept that while it would be good to improve BGP, including by any implementable changes as Tony and Geoff suggest, and perhaps with Root Cause Notification and other proposals, there is nothing we can do for the BGP routing system which will allow it to cope sufficiently with the growth in advertised routes which will occur unless some drastic action is taken, with a new architecture such as LISP or Ivip etc. and probably some new address policy to go with it. Thanks Tom to the pointer to the BGP Implementation RFC: http://tools.ietf.org/html/rfc4276#section-3.45 The four manufacturers state that they comply with the "delay withdrawals too" RFC 4271 MRAI timer specification. Tony suggests maybe not many routers ever implemented the "don't delay withdrawals" RFC 1771 specification. It would be good to hear from those who write the router code what chances there are of implementing anything more complex, such as Tony and Geoff's Path Length Damping, Optimal Path (Length) Hysteresis and/or Delayed Best Path Selection. Here a brief account of what I have learned so far, including from John's diagram and explanation of Pedro's statement. I don't expect anyone to read or respond. I really appreciate the help you have given me to date. This is my understanding so far about the crisis in routing and addressing, why we need a new architecture which broadly accepts the limits of the BGP system, and why heroics such as LISP are being seriously considered: There is an FIB problem, but the real problem is in the RIB and the CPU's ability to handle the demands of BGP communications. The fundamental problem is the routers' inability to cope with the number of advertised prefixes. If routers could handle endless prefixes and rapid updates then there would probably still be plenty of IPv4 addresses available because the space could be sliced and diced finely - including down to individual IP addresses - and used very efficiently. Portability, using the routing system for TE and probably mobility would be easily achieved by rapid changes to the routing system. The main problem seems to be the requirements placed on the routers' CPUs in simultaneously handling a complex group conversation with X number of peers, with a separate conversation about Y number of prefixes. Each peer may be sent a different message, for instance due to local policy which may be specific to each prefix and peer. Similarly, the messages received from each peer need to be considered in the light of peer-specific and prefix-specific policy. The messages and/or the result of this processing, usually needs to be stored. These messages can be quite long, and will get longer with longer paths and 32 bit AS numbers. (Also, with more optional transitive things being added to BGP messages.) Y is potentially millions, since this many end-users would like multihoming and portability. X, I guess, is typically 3 to 10, but I understand some transit routers have dozens or potentially hundreds of peers. Even if it was possible to use arbitrary amounts of RAM (which requires a 64 bit CPU) cope with whatever X*Y turns into, there is the problem of CPU speed and communications speed when considering the frequency of updates. Theoretically, if all routers could respond in close to zero time, with arbitrary numbers of peers and prefixes, all would be well. Because they can't and never will be able to, the time delays multiplied by the approximate edge-to-edge number of router hops from one side of the core to the other result in long delays in achieving connectivity and later optimally short paths. To ease the burden on routers - and so speed them up and enable them to handle more prefixes - BGP intentionally shortens the path description messages, whilst still providing robust loop protection and a rougher, but still useful, measure of "length". However, this simplified AS-based message means that a router (4) can't figure out for sure that path 4-3-2-1 is not going to work when it has just been told by its peer (2) that 2-1 doesn't work any more. / (3) /--------(5)-- / \ / / \ / \ / / / (1)-X-(2)---(4)--->-----------(6)-- \ / / \ (10)-(11)-(12)-(13)-(14)----/ As far as (4) knows, (2) isn't a solitary router, but something like the arrangement of routers 'R' below: (3) / \ /----R \ / \ (1)---R-------(4) So until (3) gets a withdrawal message to (4), and until (4) can propagate the resulting withdrawal to its peers (5) and (6) there is going to be a black hole with packets being sent to (4) when (4) has is no path to (1). The two sole points of connection to the rest of the Net (5) and (6) could also send packets to (1) via the longer path 14-13-12-11-10-1. But they won't until (4) issues its withdrawal. The current function of the MRAI timer, delaying withdrawals, means (typically, or often, depending on actual timings etc.) a 30 second delay in the withdrawal propagating from (4) in structures like that described above. The minimal structure for this problem to occur is something like: (3) / \ / \ (1)-X-(2)---(4)---- As I wrote in previous messages, the current MRAI timer typically delays the withdrawal another 30 seconds for every iteration of this loop system, although the actual behavior depends very much on policy and timing. The old MRAI specification from RFC 1771 had no such problem. (4) would quickly announce an AA+ and then very shortly after would announce a withdrawal. John explained why Pedro's 2002 statement >> I still maintain that it is not possible in BGP to >> distinguish if an update corresponds to a link up/down >> event... or what information you wish to send fast/slow. is true both theoretically and practically. I have added some other upstream links to John's original diagram: P1--AS--P2 | / | |/ | C1 C2 because I understand P1, AS and P2 are all ASes, presumably ISPs with multiple connections to other ASes. I assume that C1 has only the links shown and that C2 has links to many other systems. \ / \ / / \ / ASa-\ ASb--/---ASc \ \ / \ / /\ \ / / / \ \ / \ / \ / | --- P1--AS--P2---ASd---- | / | / / |/ |/ / C1 C2-----/ |\ > AS connects to two peer ASes, P1 and P2. AS provides > service to multi-homed customer C1, and transit customer C2. > > Normally, AS will reach C1 through the (C1, AS) link, and > will advertise C1 reachability to P1, P2 and C2. Similarly, > P1 will reach C1 through (C1, P1) and will advertise C1 > reachability to AS. > > If (C1, AS) goes down, AS will reach C1 through P1. > > Due to policy, AS will not advertise this path to P2 OK - I understand this is due to AS wanting to accept traffic for its customer C1, but only as long as C1 connects to AS's network (and pays for it). AS does not want to attract traffic directed to C1 through its network if it just has to pass it over to P1, which probably costs money or at least doesn't generate income. > and will advertise it to C2. I could understand this if C2 was a singlehomed or multihomed AS-end-user edge network. Since C2 is a transit provider, I understand that AS's relationships are: P1 and P2 are other ISPs. AS doesn't offer transit of packets from these networks, unless to a customer's network, such as C1 was, until the link went down. C2 is a transit provider (no local customers, like C1). AS will offer transit of packets to C2, so C2 can use AS's network as it would the network of another transit provider: to carry any packets anywhere. C2's network will also advertise to AS all its prefixes and so accept packets addressed to anywhere, if the AS network finds this path to C2 to be the best. > Thus, one "bad news" event (the (C1, AS) link down) has been > turned into an update with replacement route to one peer (C2) > and an update with withdraw to two others (P1 and P2). By "update with withdraw" I understand you mean a single "withdraw" message. Thanks very much for this diagram and explanation. I understand this justifies Pedro's statement. But this doesn't make me think well of the MRAI timer delaying withdrawals. I worked through what happens next and didn't immediately find problems caused by the MRAI timer. The problem condition occurs, for instance, when one router: 1 - First receives something caused by an event which is not reflective of the full story. This typically causes an A++. 2 - Shortly after, receives something else which is a fuller account of the situation, but does not announce its response for ~30 seconds due to the MRAI timer. If the second thing it announces was simply a longer path, or perhaps the same or a shorter path, then there is probably no trouble, because at all times the router could forward the packets to their destination. The problem arises primarily when the true situation was that the second item of news causes the router to realise it can't forward the packets to the destination at all. Then, there is a black hole for 30 seconds because the RFC 4271 MRAI timer won't let it announce to its peers that it really can't handle this prefix any more. The original RFC 1771 MRAI timer would not delay the withdrawal, so there would be no black hole for 30 seconds. What I find more convincing about the potential evils of rushing withdrawals and delaying some announcements of feasible paths is withdrawals propagating faster than the later news that the destination is now reachable. I imagined this and Tony mentioned it too. Tony wrote, in part: > Please read the rest of the draft. ;-) In particular the > sections on optimal path damping and delayed best path > selection. I think all three proposals look promising, as far as my limited understanding of BPG goes - and that probably two of them might do the trick as well as all three. It seems the real limitation is what the router vendors will actually implement, since for the last 5 years or more they wouldn't implement what I think is the relatively simple logic of testing for a withdrawal, in order to fully implement RFC 1771. I am not convinced that a genuine RFC 1771 MRAI timer would delay the propagation of feasible paths so much as to let a wave of withdrawals run faster through the system. (Various other comments which I agree with snipped.) >> Lets say we have 500,000 prefixes. Do we have a single down >> counter for each prefix? I guess so. As far as I know, the >> same announcements go to all peers. > > This is fundamentally incorrect. Policy is peer specific. OK, thanks. > It's not particularly hard to set up a router that has > multiple copies of the full routing table, prefers only one of > them, and then has all of the preferred routes withdrawn. I don't understand this. Can you give an example? > So, yes, you need to provision for all 500,000 timers. This > assumes you're willing to bound your implementation to that > number. FWIW, that number is no longer competitive and would > need to be more like 1-2M. Certain folks seem to already be > claiming 10M. Whew!!! >> Then there is the question of each router's message queue to >> each peer being throttled via TCP, with the software being >> able to find messages in the queue and delete them if >> something else happens after they were put in the queue. > > Removing messages after they are placed into the TCP stream is > not a practical approach. Once the message has been played > out of BGP and into the TCP socket, it is quite effectively > "gone". Yes, I understood this. I imagined a queue of messages for each peer, with the software reaching into that queue and plucking out things which have been made irrelevant by more recent developments. Geoff's recent article suggests that this is a common technique. > The best that a BGP implementation can do is to ensure that it > has filled the socket and not computed too many additional > messages. Such messages would have to be explicitly buffered > in BGP, which is expensive. It's far more effective to simply > not compute updates faster than they are consumed and leave > the data in BGP's internal data structures. OK - this makes sense. I thought it might be good for every router to wait a short time, such as 0.5 seconds, before transmitting anything - just in case something arrived on the heels of the first message which was more significant. This would be good for one router, but would slow the whole system down with no benefits if they all did it. >> Yet by 2002, we are told that Cisco, Juniper et. al. had >> given up on following RFC 1771's strict instructions to >> exempt withdrawals from the MRAI mechanism. > > You're assuming that they complied with it in the first place. I assumed this because the RFC was so clear and warned about black holes. It just an historical question now. >> They presumably didn't do this lightly. > > True, but they didn't spend eons thinking about the problem > either. ... > The problem has not gotten easier. > >> So I guess the trick is to find the simplest solution which >> will solve the problem. > > Isn't it always? ;-) Indeed. The push for simplicity is so strong that much has been lost Prefixes are so numerous that the path is described in a way that the router can't make as well an informed decision as it could otherwise. For instance if the path had a complete specification of the identity of each router, with a time-stamp (or router-local 32 bit message sequence number) for when each router last announced a feasible path which make subsequent routers include it on this path, then it would be easy for a router (4) to determine that the next best path 4-3-2-1 wasn't worth using, because "2" identifies a router, and the timestamp on "2" in this path was earlier than the time-stamp on 2's withdrawal message. I haven't read how Root Cause Notification works, but I understand it is intended to achieve the same outcome. Similarly, prefixes and numbers of peers are so numerous that five or more years ago router vendors for some reason gave up complying with RFC 1771's requirement to forward withdrawals promptly. >> It would be interesting to know what the difficulty was - >> because those difficulties may still be important and might >> prevent the adoption of Path Length Damping or some other >> mechanisms as your I-D suggests. > > Rather than 'difficulty', I would say that developers made the > judgement call that the cost/benefit ratio was unacceptable. Maybe if your and Geoff's I-D is successful and contributes either to a new RFC for BGP, or a separate RFC which updates RFC 4271's MRAI timer section, then if operators and/or router vendors are convinced of the benefits, they can rewrite at least some of the versions of their operating systems and market their routers with the new improved feature of providing optional RFC xxxx Path Length Damping etc. That would be really good. I find it striking that what you are proposing, at least with Path Length Damping, is similar to and not much more complex than what was absolutely required in 1995, probably widely ignored by 2002, and then formally prohibited in 2006! - Robin _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Jun 23 07:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I23NK-0004i0-J1; Sat, 23 Jun 2007 07:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I23NJ-0004ht-UL for idr@ietf.org; Sat, 23 Jun 2007 07:01:53 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I23NI-0004Fl-7C for idr@ietf.org; Sat, 23 Jun 2007 07:01:53 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 23 Jun 2007 04:01:52 -0700 X-IronPort-AV: i="4.16,454,1175497200"; d="scan'208"; a="23819648:sNHT67779932" Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l5NB1kJ18813; Sat, 23 Jun 2007 04:01:48 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <467CFD97.2050706@juniper.net> Date: Sat, 23 Jun 2007 13:01:43 +0200 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping References: <467799C6.3020302@firstpr.com.au><4678251A.5090002@apnic.net> <1182338421.46790d755a0ac@webmail.nist.gov> <467A393E.7040106@firstpr.com.au> <467B8800.7030609@firstpr.com.au> <467CD2D4.20700@firstpr.com.au> In-Reply-To: <467CD2D4.20700@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: Tony Li , idr , Noel Chiappa , "K. Sriram" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Robin, Just few observations ... * MRAI - Some implementations do not use it at all. Some have had a knob for years to configure it to zero, some have it zero only for particular AFI/SAFIs. I am not sure if from vendor point of view anything more is needed here. Perhaps this discussion will result in more broader tuning (lowering) of def MRAI timer between operators on those routers which have large defaults. * Control plane sizing - Internet table today is let's say 300K. Other applications routers have to deal with today are already reaching their tables to 1-2M. On average between implementations it takes about 50-70 MB for 100K of control plane routes (bgp/rib). So for one million we would use 500-700MB. Current RPs already have 4GB of RAM. Control plane distribution between many RPs is already available as well, resulting that only common RIB needs to keep all prefix + best (backup best) paths. The bottom line is that from control plane RAM point of view we still have some runway to the cliff. * CPUs + current internet stability proposals - I think this is the area which requires most current focus. Our laptops have few times more powerful CPUs then routers. Intel is pretty clear that scaling CPUs went into the multi-core avenue and speeding up the clock has significantly stopped. We (well all vendors) should utilize available CPU technology. Geoff's data that most churn is generated by roughly 10% of bad netizens of the Internet and recent proposals from tli/geoff have IMHO very good potential to vastly reduce churn leaving more BGP dedicated CPUs for actual BGP update/best-path processing. Other proposals in that space for example BGP Aggregate Withdraw could also help (IMHO :). * Indeed there are many various proposals to introduce hierarchy to the Internet today. I like hierarchy and word "tunneling" does not raise high blood pressure to me. But on the other hand I am not clear how can we all be sure that with some proposals today we are not just shifting current path hunting problem as well as other problems from flat BGP to a new mapping plane ? And if this mapping plane is free from such issues, why current BGP control plane could not be ? After all only scalable & realistic deployment model is to use those same CPUs and the same routers for all the work. Another point which usually I am finding not so intuitive is that most people does see Internet as huge chain of interconnected ASes to get from A to B. But here comes a surprise ... current average AS_PATH length is 3.4 - 3.8 depends on the geography. One of my & my colleague's proposals in that space to just aim at introducing hierarchy was to simply tunnel to automatically derived IP address representation of endpoint AS number. It would not address mobility nor Internet TE. But could introduce hierarchy. The issue with this is that due to such short AS_PATH as well as transit AS ASBRs which do home their customers all what we would gain is to keep P routers from storing all the BGP unicast routing tables. And that has been possible for years now already via many technologies. * From my point of view the biggest gain one could envision while introducing some form of mapping abstraction between EID & locators are not those which are listed in the IAB report. For me it is the opportunity to build and deliver internet wide new services. It has a full potential to become a direct analogy to introduction "Intelligent Network" layer to phone networks 15 years back. And that was a huge disruptive change to the way operators were delivering their services for X previous years. Not too mention that ISPs could be very happy and economically interested to deploy it as for them it could immediately result in new services to their customers they could finally start charging - something quite useful in the commodity Internet world today :-). Cheers, R. > Thanks very much Tony, Geoff, John, Tom, Noel, Ricardo and Sriram. > > The Internet's routing and addressing system has trouble coming > as surely as a freight train or a rising flood. > > I came to the RAM list asking questions and offering ideas, > recognising I was a newbie. This lead me via the RRG and now to > the home of those who build and try to improve BGP - the IDR > mailing list. > > Here I sit asking difficult questions and receiving good answers > from The Elders - on why the BGP mountain really can't be moved > very much, or at least nowhere near enough that a new > architecture will not be needed soon. > > I accept that while it would be good to improve BGP, including > by any implementable changes as Tony and Geoff suggest, and > perhaps with Root Cause Notification and other proposals, there > is nothing we can do for the BGP routing system which will allow > it to cope sufficiently with the growth in advertised routes > which will occur unless some drastic action is taken, with a new > architecture such as LISP or Ivip etc. and probably some new > address policy to go with it. > > Thanks Tom to the pointer to the BGP Implementation RFC: > > http://tools.ietf.org/html/rfc4276#section-3.45 > > The four manufacturers state that they comply with the "delay > withdrawals too" RFC 4271 MRAI timer specification. > > Tony suggests maybe not many routers ever implemented the "don't > delay withdrawals" RFC 1771 specification. > > It would be good to hear from those who write the router code > what chances there are of implementing anything more complex, > such as Tony and Geoff's Path Length Damping, Optimal Path > (Length) Hysteresis and/or Delayed Best Path Selection. > > > Here a brief account of what I have learned so far, including > from John's diagram and explanation of Pedro's statement. I > don't expect anyone to read or respond. I really appreciate the > help you have given me to date. > > > > This is my understanding so far about the crisis in routing and > addressing, why we need a new architecture which broadly accepts > the limits of the BGP system, and why heroics such as LISP are > being seriously considered: > > There is an FIB problem, but the real problem is in the RIB and > the CPU's ability to handle the demands of BGP communications. > The fundamental problem is the routers' inability to cope with > the number of advertised prefixes. > > If routers could handle endless prefixes and rapid updates then > there would probably still be plenty of IPv4 addresses available > because the space could be sliced and diced finely - including > down to individual IP addresses - and used very efficiently. > Portability, using the routing system for TE and probably > mobility would be easily achieved by rapid changes to the > routing system. > > The main problem seems to be the requirements placed on the > routers' CPUs in simultaneously handling a complex group > conversation with X number of peers, with a separate > conversation about Y number of prefixes. Each peer may be sent > a different message, for instance due to local policy which may > be specific to each prefix and peer. Similarly, the messages > received from each peer need to be considered in the light of > peer-specific and prefix-specific policy. The messages and/or > the result of this processing, usually needs to be stored. > These messages can be quite long, and will get longer with > longer paths and 32 bit AS numbers. (Also, with more optional > transitive things being added to BGP messages.) > > Y is potentially millions, since this many end-users would like > multihoming and portability. X, I guess, is typically 3 to 10, > but I understand some transit routers have dozens or potentially > hundreds of peers. > > Even if it was possible to use arbitrary amounts of RAM (which > requires a 64 bit CPU) cope with whatever X*Y turns into, there > is the problem of CPU speed and communications speed when > considering the frequency of updates. > > Theoretically, if all routers could respond in close to zero > time, with arbitrary numbers of peers and prefixes, all would be > well. > > Because they can't and never will be able to, the time delays > multiplied by the approximate edge-to-edge number of router hops > from one side of the core to the other result in long delays in > achieving connectivity and later optimally short paths. > > To ease the burden on routers - and so speed them up and enable > them to handle more prefixes - BGP intentionally shortens the > path description messages, whilst still providing robust loop > protection and a rougher, but still useful, measure of "length". > > However, this simplified AS-based message means that a router > (4) can't figure out for sure that path 4-3-2-1 is not going to > work when it has just been told by its peer (2) that 2-1 doesn't > work any more. > > / > (3) /--------(5)-- > / \ / / \ > / \ / / / > (1)-X-(2)---(4)--->-----------(6)-- > \ / / \ > (10)-(11)-(12)-(13)-(14)----/ > > As far as (4) knows, (2) isn't a solitary router, but something > like the arrangement of routers 'R' below: > > (3) > / \ > /----R \ > / \ > (1)---R-------(4) > > > So until (3) gets a withdrawal message to (4), and until (4) can > propagate the resulting withdrawal to its peers (5) and (6) > there is going to be a black hole with packets being sent to (4) > when (4) has is no path to (1). The two sole points of > connection to the rest of the Net (5) and (6) could also send > packets to (1) via the longer path 14-13-12-11-10-1. But they > won't until (4) issues its withdrawal. > > The current function of the MRAI timer, delaying withdrawals, > means (typically, or often, depending on actual timings etc.) a > 30 second delay in the withdrawal propagating from (4) in > structures like that described above. The minimal structure for > this problem to occur is something like: > > (3) > / \ > / \ > (1)-X-(2)---(4)---- > > As I wrote in previous messages, the current MRAI timer > typically delays the withdrawal another 30 seconds for every > iteration of this loop system, although the actual behavior > depends very much on policy and timing. > > The old MRAI specification from RFC 1771 had no such problem. > (4) would quickly announce an AA+ and then very shortly after > would announce a withdrawal. > > John explained why Pedro's 2002 statement > > >> I still maintain that it is not possible in BGP to > >> distinguish if an update corresponds to a link up/down > >> event... or what information you wish to send fast/slow. > > is true both theoretically and practically. > > I have added some other upstream links to John's original diagram: > > P1--AS--P2 > | / | > |/ | > C1 C2 > > because I understand P1, AS and P2 are all ASes, presumably ISPs > with multiple connections to other ASes. I assume that C1 has > only the links shown and that C2 has links to many other systems. > > \ / \ / / \ / > ASa-\ ASb--/---ASc > \ \ / \ / /\ > \ / / / \ > \ / \ / \ / | > --- P1--AS--P2---ASd---- > | / | / / > |/ |/ / > C1 C2-----/ > |\ > > > AS connects to two peer ASes, P1 and P2. AS provides > > service to multi-homed customer C1, and transit customer C2. > > > > Normally, AS will reach C1 through the (C1, AS) link, and > > will advertise C1 reachability to P1, P2 and C2. Similarly, > > P1 will reach C1 through (C1, P1) and will advertise C1 > > reachability to AS. > > > > If (C1, AS) goes down, AS will reach C1 through P1. > > > > Due to policy, AS will not advertise this path to P2 > > OK - I understand this is due to AS wanting to accept traffic > for its customer C1, but only as long as C1 connects to AS's > network (and pays for it). AS does not want to attract traffic > directed to C1 through its network if it just has to pass it > over to P1, which probably costs money or at least doesn't > generate income. > > > and will advertise it to C2. > > I could understand this if C2 was a singlehomed or multihomed > AS-end-user edge network. > > Since C2 is a transit provider, I understand that AS's > relationships are: > > P1 and P2 are other ISPs. AS doesn't offer transit of > packets from these networks, unless to a customer's > network, such as C1 was, until the link went down. > > C2 is a transit provider (no local customers, like C1). > AS will offer transit of packets to C2, so C2 can use > AS's network as it would the network of another transit > provider: to carry any packets anywhere. > > C2's network will also advertise to AS all its prefixes > and so accept packets addressed to anywhere, if the AS > network finds this path to C2 to be the best. > > > Thus, one "bad news" event (the (C1, AS) link down) has been > > turned into an update with replacement route to one peer (C2) > > and an update with withdraw to two others (P1 and P2). > > By "update with withdraw" I understand you mean a single > "withdraw" message. > > Thanks very much for this diagram and explanation. I understand > this justifies Pedro's statement. > > But this doesn't make me think well of the MRAI timer delaying > withdrawals. > > I worked through what happens next and didn't immediately find > problems caused by the MRAI timer. The problem condition > occurs, for instance, when one router: > > 1 - First receives something caused by an event which is > not reflective of the full story. This typically > causes an A++. > > 2 - Shortly after, receives something else which is a fuller > account of the situation, but does not announce its > response for ~30 seconds due to the MRAI timer. > > If the second thing it announces was simply a longer path, or > perhaps the same or a shorter path, then there is probably no > trouble, because at all times the router could forward the > packets to their destination. > > The problem arises primarily when the true situation was that > the second item of news causes the router to realise it can't > forward the packets to the destination at all. Then, there is a > black hole for 30 seconds because the RFC 4271 MRAI timer won't > let it announce to its peers that it really can't handle this > prefix any more. The original RFC 1771 MRAI timer would not > delay the withdrawal, so there would be no black hole for 30 > seconds. > > > What I find more convincing about the potential evils of rushing > withdrawals and delaying some announcements of feasible paths is > withdrawals propagating faster than the later news that the > destination is now reachable. I imagined this and Tony > mentioned it too. > > Tony wrote, in part: > > > Please read the rest of the draft. ;-) In particular the > > sections on optimal path damping and delayed best path > > selection. > > I think all three proposals look promising, as far as my limited > understanding of BPG goes - and that probably two of them might > do the trick as well as all three. > > It seems the real limitation is what the router vendors will > actually implement, since for the last 5 years or more they > wouldn't implement what I think is the relatively simple logic > of testing for a withdrawal, in order to fully implement RFC > 1771. I am not convinced that a genuine RFC 1771 MRAI timer > would delay the propagation of feasible paths so much as to let > a wave of withdrawals run faster through the system. > > (Various other comments which I agree with snipped.) > > >> Lets say we have 500,000 prefixes. Do we have a single down > >> counter for each prefix? I guess so. As far as I know, the > >> same announcements go to all peers. > > > > This is fundamentally incorrect. Policy is peer specific. > > OK, thanks. > > > It's not particularly hard to set up a router that has > > multiple copies of the full routing table, prefers only one of > > them, and then has all of the preferred routes withdrawn. > > I don't understand this. Can you give an example? > > > So, yes, you need to provision for all 500,000 timers. This > > assumes you're willing to bound your implementation to that > > number. FWIW, that number is no longer competitive and would > > need to be more like 1-2M. Certain folks seem to already be > > claiming 10M. > > Whew!!! > > > >> Then there is the question of each router's message queue to > >> each peer being throttled via TCP, with the software being > >> able to find messages in the queue and delete them if > >> something else happens after they were put in the queue. > > > > Removing messages after they are placed into the TCP stream is > > not a practical approach. Once the message has been played > > out of BGP and into the TCP socket, it is quite effectively > > "gone". > > Yes, I understood this. I imagined a queue of messages for each > peer, with the software reaching into that queue and plucking > out things which have been made irrelevant by more recent > developments. Geoff's recent article suggests that this is a > common technique. > > > The best that a BGP implementation can do is to ensure that it > > has filled the socket and not computed too many additional > > messages. Such messages would have to be explicitly buffered > > in BGP, which is expensive. It's far more effective to simply > > not compute updates faster than they are consumed and leave > > the data in BGP's internal data structures. > > OK - this makes sense. > > I thought it might be good for every router to wait a short > time, such as 0.5 seconds, before transmitting anything - just > in case something arrived on the heels of the first message > which was more significant. This would be good for one router, > but would slow the whole system down with no benefits if they > all did it. > > >> Yet by 2002, we are told that Cisco, Juniper et. al. had > >> given up on following RFC 1771's strict instructions to > >> exempt withdrawals from the MRAI mechanism. > > > > You're assuming that they complied with it in the first place. > > I assumed this because the RFC was so clear and warned about > black holes. It just an historical question now. > > >> They presumably didn't do this lightly. > > > > True, but they didn't spend eons thinking about the problem > > either. > > ... > > > The problem has not gotten easier. > > > >> So I guess the trick is to find the simplest solution which > >> will solve the problem. > > > > Isn't it always? ;-) > > Indeed. The push for simplicity is so strong that much has been lost > > Prefixes are so numerous that the path is described in a way > that the router can't make as well an informed decision as it > could otherwise. For instance if the path had a complete > specification of the identity of each router, with a time-stamp > (or router-local 32 bit message sequence number) for when each > router last announced a feasible path which make subsequent > routers include it on this path, then it would be easy for a > router (4) to determine that the next best path 4-3-2-1 wasn't > worth using, because "2" identifies a router, and the timestamp > on "2" in this path was earlier than the time-stamp on 2's > withdrawal message. I haven't read how Root Cause Notification > works, but I understand it is intended to achieve the same outcome. > > Similarly, prefixes and numbers of peers are so numerous that > five or more years ago router vendors for some reason gave up > complying with RFC 1771's requirement to forward withdrawals > promptly. > > > >> It would be interesting to know what the difficulty was - > >> because those difficulties may still be important and might > >> prevent the adoption of Path Length Damping or some other > >> mechanisms as your I-D suggests. > > > > Rather than 'difficulty', I would say that developers made the > > judgement call that the cost/benefit ratio was unacceptable. > > Maybe if your and Geoff's I-D is successful and contributes > either to a new RFC for BGP, or a separate RFC which updates RFC > 4271's MRAI timer section, then if operators and/or router > vendors are convinced of the benefits, they can rewrite at least > some of the versions of their operating systems and market their > routers with the new improved feature of providing optional RFC > xxxx Path Length Damping etc. > > That would be really good. I find it striking that what you are > proposing, at least with Path Length Damping, is similar to and > not much more complex than what was absolutely required in 1995, > probably widely ignored by 2002, and then formally prohibited in > 2006! > > - Robin > > > > _______________________________________________ > 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 Jun 24 12:31:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Uz2-0004p0-4r; Sun, 24 Jun 2007 12:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Uz0-0004ov-SS for idr@ietf.org; Sun, 24 Jun 2007 12:30:38 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Uyz-0000EF-Fe for idr@ietf.org; Sun, 24 Jun 2007 12:30:38 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5OGVFRC002264; Sun, 24 Jun 2007 12:31:16 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706241631.l5OGVFRC002264@sailbum.orleans.occnc.com> To: Robin Whittle From: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-reply-to: Your message of "Sat, 23 Jun 2007 17:59:16 +1000." <467CD2D4.20700@firstpr.com.au> Date: Sun, 24 Jun 2007 12:31:14 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Tony Li , idr , Noel Chiappa , "K. Sriram" 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 <467CD2D4.20700@firstpr.com.au> Robin Whittle writes: > > The Internet's routing and addressing system has trouble coming > as surely as a freight train or a rising flood. [...] > > Here I sit asking difficult questions and receiving good answers > from The Elders - on why the BGP mountain really can't be moved > very much, or at least nowhere near enough that a new > architecture will not be needed soon. [...] Your message had some good technical content but this was not good technical content. We've been hearing about the eminent collapse of BGP routing, exhaustion of IP routes, and other predictions of doom and calls for radical changes to the architecture for well over a decade, most of it from people with a limited knowledge of Internet operations if any. Please don't be counted among that set by including this sort of nonsense with your technical discussion. Thanks, Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jun 24 13:05:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2VWI-0005sO-Ti; Sun, 24 Jun 2007 13:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2VWH-0005o5-Sm for idr@ietf.org; Sun, 24 Jun 2007 13:05:01 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2VWE-0000tF-5r for idr@ietf.org; Sun, 24 Jun 2007 13:05:01 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 62C1259E46; Mon, 25 Jun 2007 03:04:56 +1000 (EST) Message-ID: <467EA42D.8030402@firstpr.com.au> Date: Mon, 25 Jun 2007 03:04:45 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: idr Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping References: <200706241631.l5OGVFRC002264@sailbum.orleans.occnc.com> In-Reply-To: <200706241631.l5OGVFRC002264@sailbum.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Tony Li , Noel Chiappa , "K. Sriram" 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 (By the way, I don't seem to be getting IDR list messages, although I am subscribed.) Hi Curtis, You criticised my statements, which were framed as being my understanding, although on their own they look like I was stating these things as if they were facts: >> The Internet's routing and addressing system has trouble coming >> as surely as a freight train or a rising flood. > [...] >> >> Here I sit asking difficult questions and receiving good answers >> from The Elders - on why the BGP mountain really can't be moved >> very much, or at least nowhere near enough that a new >> architecture will not be needed soon. > [...] > > Your message had some good technical content but this was not good > technical content. > > We've been hearing about the eminent collapse of BGP routing, > exhaustion of IP routes, and other predictions of doom and calls for > radical changes to the architecture for well over a decade, most of it > from people with a limited knowledge of Internet operations if any. > Please don't be counted among that set by including this sort of > nonsense with your technical discussion. As far as I know, the first quoted statement is consistent with the consensus of the RAW conference: http://tools.ietf.org/html/draft-iab-raws-report http://www.iab.org/about/workshops/routingandaddressing/ and with the exhaustion of IPv4 address space ca. 2010: http://www.potaroo.net/tools/ipv4/ As far as I know, the second quoted statement is consistent with the opinions expressed by most people on this list recently, and before that on the RRG and RAM list discussions: that while some worthwhile improvements probably can be made to the BGP system, with changes to the protocol and/or the configuration of routers, that these changes, combined with likely technical improvements in routers, will not on their own be able to cope with the growing "global BGP routing table" and with the update traffic which results from this growth and all other factors affecting updates. The fact that predictions of doom and gloom may have been made for a decade doesn't convince me that the current predictions are wrong. Also, as far as I know, the people who are now making these predictions are fully informed of the situation. If you can convince me that these statements are false, I would really appreciate it. I think it would be best if you did so with technical arguments rather than with the history of concern or unsupported negative assessments of the expertise of people who currently have serious concerns about the BGP system, addressing etc. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jun 24 13:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2WGa-0003t9-Jy; Sun, 24 Jun 2007 13:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2WGZ-0003sy-2U for idr@ietf.org; Sun, 24 Jun 2007 13:52:51 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2WGW-00032v-Fb for idr@ietf.org; Sun, 24 Jun 2007 13:52:51 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5OHrFEq003718; Sun, 24 Jun 2007 13:53:15 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706241753.l5OHrFEq003718@sailbum.orleans.occnc.com> To: Robin Whittle From: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-reply-to: Your message of "Mon, 25 Jun 2007 03:04:45 +1000." <467EA42D.8030402@firstpr.com.au> Date: Sun, 24 Jun 2007 13:53:15 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Tony Li , idr , Noel Chiappa , "K. Sriram" 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 <467EA42D.8030402@firstpr.com.au> Robin Whittle writes: > > As far as I know, the first quoted statement is consistent with > the consensus of the RAW conference: > > http://tools.ietf.org/html/draft-iab-raws-report > http://www.iab.org/about/workshops/routingandaddressing/ > > and with the exhaustion of IPv4 address space ca. 2010: > > http://www.potaroo.net/tools/ipv4/ If you look back at the RFC archives you'll find prior IAB workshops and reports predicting doom all the way back from the calls to convert from IP to OSI and from BGP to IDRP in the mid-1990s. In fact IDR was renamed from BGP to accomodate IDRP which then died due to lack of interest. If you want to see some real nonsense, take a look in the IRTF archives at the decade worth of discussions of replacing the interdomain routing system that sort of died down a few years ago. The fact that the IAB has repeatedly cried wolf doesn't mean they are addressing a non-issue. If calling an issue a crisis gets action more promptly then calling it a crisis prematurely may be good thing. In the past small changes (to the extent CIDR was a small change) have addressed the issues that were referred to as a crisis and that were used as justification to consider massive change or a wholesale new architecture. Lets get back to the topic of damping and broader topic of addressing the "issue" or route churn and let any "crisis" related to route churn or any other crisis be discussed elsewhere if people find a need to claim yet another crisis. As the author of the original route damping I can say that there never was a crisis or route churn. It was considered a good idea for two reasons. Eliminating the minority of constantly oscillating routes (that existed then) relieve the burden on core routers and make convergence for mostly stable routes faster. The widespread use of something more intellegent to limit route churn might allow greatly reducing (but probably not quite eliminating) MRAI. The high level of route churn at that time (and probably now) was more of a nuisance than a crisis. It was more about improving the performance of the Internet rather than saving it from disaster. Part of the problem with route damping as currently implemented is the spec clear calls for damping on a per destination per AS-path basis while implementation only allow a per destination basis. The result is that transient AS path changes resulting from a withdrawl penalize the destination even when the valid alternate AS path is very stable but takes a bit longer to arrive (which could happen for various reasons). That was a real problem that could magnify the impact of one or two route changes and cause unwanted damping. It should be noted (but rarely is) that if damping was implemented *as specified* this magnification would not happen. A separate practical problem was occasionally bringing up something new and having it go up and down a lot could cause the aggrevation of having it damped (and that sort of poor network admin could result in public whining about damping being harmful, for example from a certain individual at the last NANOG). The other part of the problem is one vendor set the default parameters too short. That was easily solved by RIPE making some reasonable recommendations for configuring the timers. btw- If most routes are mostly stable, the small churn on a transition is not really an issue. Peace, Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jun 26 21:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3MIj-00078H-IW; Tue, 26 Jun 2007 21:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3MIi-00078A-Mm for idr@ietf.org; Tue, 26 Jun 2007 21:26:32 -0400 Received: from c-24-7-120-3.hsd1.ca.comcast.net ([24.7.120.3] helo=sailbum.orleans.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3MIe-0008GU-0J for idr@ietf.org; Tue, 26 Jun 2007 21:26:32 -0400 Received: from sailbum.orleans.occnc.com (localhost [127.0.0.1]) by sailbum.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id l5R1RNIf001746; Tue, 26 Jun 2007 21:27:23 -0400 (EDT) (envelope-from curtis@sailbum.orleans.occnc.com) Message-Id: <200706270127.l5R1RNIf001746@sailbum.orleans.occnc.com> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) From: Curtis Villamizar Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping In-reply-to: Your message of "Mon, 25 Jun 2007 14:56:06 EDT." <20070625185606.7B31B86AFA@mercury.lcs.mit.edu> Date: Tue, 26 Jun 2007 21:27:23 -0400 X-Spam-Score: 1.8 (+) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 <20070625185606.7B31B86AFA@mercury.lcs.mit.edu> Noel Chiappa writes: > > > From: Curtis Villamizar > > > We've been hearing about the eminent collapse of BGP routing, > > exhaustion of IP routes, and other predictions of doom and calls for > > radical changes to the architecture for well over a decade, most of it > > from people with a limited knowledge of Internet operations if any. > > Curtis, nobody has a perfect crystal ball. I've been on both sides of this > general situation, making some predictions of problems that didn't come true > (on the one hand), and opposing alarums about what I thought were > non-problematic scenarios - later proven to be non-problematic (on the other). > > Do I wish I hadn't called some wrong? Yeah, because obviously it damages ones > credibility when you blow it. At the same time, I think we're a bit in the > position of lookouts on a military post; if you don't make some close calls > that are wrong, *because you're erring on the side of caution*, some day you > will Lose.Big because you'll miss a real one. Caution is always good. Panic isn't. > In the latest go-round, there are two pieces of real-world data that are > concerning me. The first is what I can glean from the data gatherered after > the Pacific earthquake, which I have mentioned before: > > The Renesys NANOG presentaion Taiwan quake seemed to indicate that "a > while" is on the order of an hour or so. (However, it's not clear if that > was the time it took BGP to recover, or the time needed to reroute some > circuits. The Rensys presentation also covers much longer-term outages, but > those were caused by the need to set up new business relationships - not > really a routing problem!) > > The other is something else I've mentioned before: > > I am told that it takes a core router .. [from one major vendor] a > significant fraction of an hour to load the current complete routing table > (via BGP) when it restarts I know that taking full routing can be done in a few minutes including at startup. Anything taking an hour has an implementation problem. That would not be a protocol problem. A widely deployed bad implementation can cause quite a disruption. We saw that as far back as the NSFNET days but the solution is to fix that implementation. > When Destination-Vector routing systems collapse from overload, they don't > usually degrade gracefully, there's usually a sharp knee, and then things get > quite bad pretty quickly. Are we anywhere near that? I have no idea, because > I don't think we have a really first-class understanding of the overall > operation of the Internet routing. It is possible to degrade gracefully. If not all implementations do degrade gradefully, that is an implementation problem. Consider the following points: There are a finite number of legitimite prefixes. There are mechanisms that can be put into place to distinguish between legitimite prefixes and those that are questionable. Whether these mechanisms are used enough is a separate question but some people do use the IRR. RPSEC has there own idea of how to do this but whether RPSEC has a good solution is a separate topic. The set of legitimite prefixes and therefore most important prefixes can be bounded. Routes change can be magnified but MRAI and other mechanisms and a finite number of routers limit that. Regardless of it being bounded the amount of route change that is possible is quite high. Proper processing of the Adj-In RIB will read in the input stream and the set of changes in very large chuncks approaching the limit set by the TCP window and the delay between routers. This can be a very high data. Multiple changes to the same prefix in the AdjIn should simply overwrite each other without incurring any significant overhead. Periodically the router must pause from reading the Adj-In stream and run the decision process, route install, and Adj-Out processing. Any relatively stable prefix that makes only a limited number of changes (even amplified a bit by multiple paths) will get its change through the Adj-RIB-In processing fairly quickly even if other things are oscillating wildly. So a good implementation of BGP (and they do exist) on a well administered network (some form of verification of legitimate prefixes is done to keep them finite and the provider knows how to avoid like BGP RR pitfalls, etc), should be capable of enduring almost arbitrarily high levels of routing nonsense from some corner of the Internet. That corner of the Internet might be completely hosed. This is nothing new. A decade ago InternetMCI deployed a full mesh of ATM links and their IGP melted down every few days and didn't stabilize for days at a time. This went on for many months until MCI gave up on that design. The route churn affected some other providers but not all. The NSFNET was fine (actually ANSNET at that point). I'll pick on them becausse they don't exist anymore. PSI had their share of problems too. Many others. The point is that BGP can survive this. A decade ago ANS sold more expensive network service with the market distinction of using the IRR to keep routing sane and being the most stable network. Some others sold cheaper service with in some cases shoddy administration that was deemed to be a "low opex" feature. That still exists today. Whether the routers can handle the load is an issue for the providers and for IETF is an issue for BMWG if they choose to take it on. There is work in BMWG in that area and providers and vendors have done their own testing since the mid-1950s, some doing more rigorous testing than others. Large commercial customers may want to wise up and start looking to see how their providers run their networks and ask what is being done to remain stable if parts or even the rest of the Internet went unstable. That might be all that is needed to fix the problem because the problems at this point may not be primarily technical. > All I know is that there are a couple of data items out there (particularly > the Taiwan one) which are somewhat troubling. Yes, the Internet is so big now > that it's unlikely to 'crash', in the naive sense, but we have historically > seen several events that screwed up reachability to large parts of the > Internet for many hours, so something slightly bigger is not that implausible. > > Just because it hasn't up till now is absolutely no guarantee that it never > will; the 'Challenger' disaster showed NASA how flawed that line of reasoning > is, and I hope we don't have to learn the same lesson the hard way. > > Noel Right. Good thing NASA didn't run the NSFNET. Curtis btw- this thread is a huge distraction from the topic of the i-d that Tony put before us. Regarding the draft: At this time, we have no recommendations for possible alternative parameter settings. RIPE made recommendations many years ago. Almost a decade ago. You've cited their recommendations so why is this comment there? The draft continues to ignore the suggestion that we implement BGP route flap damping as originally specified which is per AS path per prefix and not just per prefix. The logs I've seen indicate that there is not all that high a multiplier of prefixes if AS Path is included and the data structure for damping is tiny. It should be noted in Tony's draft that BGP Route Flap Damping was not implemented as specified in RFC2439 where the problem of multiple AS Paths for the same prefix was anticipated and handled. RFC2439: The tuple representing a route for the purpose of route flap damping is: tuple entry default options ------------------------------------------- NLRI prefix required length required AS path included option to exclude last AS set in path excluded option to include next hop excluded option to include MED excluded option to include in comparisons only The AS path is generally included in order to identify downstream instability which is not being damped or not being sufficiently damped and is alternating between a stable and an unstable path. Under rare circumstances it may be desirable to exclude AS path for all or a subset of prefixes. If an AS path ends in an AS set, in practice the path is always for an aggregate. Changes to the trailing AS set should be ignored. Ideally the AS path comparison should insure that at least one AS has remained constant in the old and new AS set, but completely ignoring the contents of a trailing AS set is also acceptable. The RFC recommended implementing AS Path as part of the tuple with the option to disable its use and tried to discourage disabling it in this text and elsewhere. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jun 27 00:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ok4-0006zz-6r; Wed, 27 Jun 2007 00:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ok3-0006xN-45 for idr@ietf.org; Wed, 27 Jun 2007 00:02:55 -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 1I3Ojz-0001SV-Pc for idr@ietf.org; Wed, 27 Jun 2007 00:02:55 -0400 Received: from [192.168.1.7] (VDSL-151-118-149-96.DNVR.QWEST.NET [151.118.149.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 8DB7164350; Tue, 26 Jun 2007 22:02:51 -0600 (MDT) In-Reply-To: <200706270127.l5R1RNIf001746@sailbum.orleans.occnc.com> References: <200706270127.l5R1RNIf001746@sailbum.orleans.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87BDB382-7A18-400C-9B47-04B7DC7D933F@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Re: BGP path hunting, MRAI timer and Path Length Damping Date: Tue, 26 Jun 2007 22:02:48 -0600 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: idr Routing List , Noel Chiappa 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 Jun 26, 2007, at 7:27 PM, Curtis Villamizar wrote: > This is nothing new. A decade ago InternetMCI deployed a full mesh of > ATM links and their IGP melted down every few days and didn't > stabilize for days at a time. This went on for many months until MCI > gave up on that design. The route churn affected some other providers > but not all. I don't recall it being quite that dramatic or fragile and we did stick with the architecture for more than a couple months, as we were a bit committed, you might say :-) That said, with "poor mans" mesh groups for constraining LSP flooding to carefully engineered overlay topologies, coupled with a slew of timers to throttle every function, from SPF [re]runs to LSP lifetimes, hellos and SNPs, guess you could say we had things tweaked. The interesting thing is that most of the timers that were put there at the time to slow things down are the very ones folks use to speed up convergence today. Of course, it wasn't a completely ideal situation, as you indicate. But yeah, this is probably a bit off topic at this point. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr