From root@core3.amsl.com Fri Oct 2 12:00:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8FF4B3A68C6; Fri, 2 Oct 2009 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091002190001.8FF4B3A68C6@core3.amsl.com> Date: Fri, 2 Oct 2009 12:00:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-rfc4893bis-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-rfc4893bis-01.txt Pages : 11 Date : 2009-10-02 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-rfc4893bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-02115407.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 7 09:45:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A72653A68DA; Wed, 7 Oct 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091007164501.A72653A68DA@core3.amsl.com> Date: Wed, 7 Oct 2009 09:45:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-aigp-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : The Accumulated IGP Metric Attribute for BGP Author(s) : R. Fernando, et al. Filename : draft-ietf-idr-aigp-01.txt Pages : 13 Date : 2009-10-07 Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aigp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-aigp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-07093552.I-D@ietf.org> --NextPart-- From ben_april@trendmicro.com Fri Oct 9 09:54:39 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573323A693F for ; Fri, 9 Oct 2009 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FouuKI90fLNy for ; Fri, 9 Oct 2009 09:54:38 -0700 (PDT) Received: from SJDCISCAN04.udc.trendmicro.com (sjdciscan04.udc.trendmicro.com [216.99.131.153]) by core3.amsl.com (Postfix) with ESMTP id 839CE3A68D2 for ; Fri, 9 Oct 2009 09:54:38 -0700 (PDT) Received: from SJDCISCAN04.udc.trendmicro.com (SJDCISCAN04 [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5EDB59A8950 for ; Fri, 9 Oct 2009 09:56:21 -0700 (PDT) Received: from sjdcexbh02.us.trendnet.org (sjdcexbh02.udc.trendmicro.com [216.99.131.187]) by SJDCISCAN04.udc.trendmicro.com (Postfix) with ESMTP id 53F5F9A885C for ; Fri, 9 Oct 2009 09:56:21 -0700 (PDT) Received: from SJDCEXMAIL01.us.trendnet.org ([10.30.240.41]) by sjdcexbh02.us.trendnet.org with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 09:56:23 -0700 Received: from ben-aprils-macbook-pro.local ([10.31.182.71]) by SJDCEXMAIL01.us.trendnet.org with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 09:56:22 -0700 Message-ID: <4ACF6B32.7030209@trendmicro.com> Date: Fri, 09 Oct 2009 12:56:18 -0400 From: Benjamin April Organization: TrendMicro - ATR User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: idr@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 16:56:22.0184 (UTC) FILETIME=[6DF1D280:01CA4901] Subject: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ben_april@trendmicro.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 16:54:39 -0000 Greetings, I find myself in the process of updating one of our BGP data-collectors to support 4-octet ASNs. I did my best to follow RFC-4893, however I have a nagging feeling that I don't understand one element. I hope you folks can point me in the right direction here. The language in question is in section 4.2.3. The passages of particular concern to me are: Under certain conditions, it may not be possible to reconstruct the entire AS path information from the AS_PATH and the AS4_PATH attributes of a route. This occurs when two or more routes that carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the AS4_PATH attribute of at least one of these routes carries at least one 4-octet AS number (as oppose to a 2-octet AS number that is encoded in 4 octets). Depending on the implementation, either the AS4_PATH attribute would be lost during route aggregation, or both the AS_PATH attribute and the AS4_PATH attribute would contain valid, partial information that cannot be combined seamlessly, resulting in incomplete AS path information in these cases. and In order to construct the AS path information, it would be necessary to first calculate the number of AS numbers in the AS_PATH and AS4_PATH attributes using the method specified in Section 9.1.2.2 [BGP] and [RFC3065] for route selection. If the number of AS numbers in the AS_PATH attribute is less than the number of AS numbers in the AS4_PATH attribute, then the AS4_PATH attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken as the AS path information. If the number of AS numbers in the AS_PATH attribute is larger than or equal to the number of AS numbers in the AS4_PATH attribute, then the AS path information SHALL be constructed by taking as many AS numbers and path segments as necessary from the leading part of the AS_PATH attribute, and then prepending them to the AS4_PATH attribute so that the AS path information has an identical number of AS numbers as the AS_PATH attribute. Forgive me, but this all sounds like an awful lot of hand-waving to me. Has anything been done since this RFC was published to better describe in a more formal way the procedure a BGP speaker should follow to re-construct an accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based on this description I can see more than one way to implement this. I would like to do so correctly, but I need to know what is correct first. Thanks Ben TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From enkechen@cisco.com Fri Oct 9 10:10:43 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8175628C1F6 for ; Fri, 9 Oct 2009 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCKZbq3wyl9X for ; Fri, 9 Oct 2009 10:10:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7685528C1FC for ; Fri, 9 Oct 2009 10:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5571; q=dns/txt; s=sjiport02001; t=1255108346; x=1256317946; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Enke=20Chen=20|Subject:=20Re :=20[Idr]=20Question=20about=20RFC4893|Date:=20Fri,=2009 =20Oct=202009=2010:12:21=20-0700|Message-ID:=20<4ACF6EF5. 10405@cisco.com>|To:=20ben_april@trendmicro.com|CC:=20idr @ietf.org,=20Enke=20Chen=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4ACF6B32.7030209@trendmicro.com> |References:=20<4ACF6B32.7030209@trendmicro.com>; bh=Dy40LaVlBeewBeIFLcUYT+hp39Z2i6o9zViuFxwQPHk=; b=goY8t09G3JnmMOtdZJcwLucu75HLv8kc02/T8+5Gv6L3NIE13ixgD6da cZ3BynXhaLVzs2jUN8hMZlVhTgC1PT17+ngbj+O8l51NzeLul+Ed2izS4 3/pZcQltiM6ebklIGSr2nl5tkYouZxR78GHwq6+CadbrwV7QJUdyRcTdG M=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEcLz0qrR7Ht/2dsb2JhbADDD5hIhCwE X-IronPort-AV: E=Sophos;i="4.44,533,1249257600"; d="scan'208";a="213086563" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2009 17:12:26 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n99HCQa6022676; Fri, 9 Oct 2009 17:12:26 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.3959); Fri, 9 Oct 2009 10:12:26 -0700 Received: from [10.21.121.206] ([10.21.121.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:12:25 -0700 Message-ID: <4ACF6EF5.10405@cisco.com> Date: Fri, 09 Oct 2009 10:12:21 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ben_april@trendmicro.com References: <4ACF6B32.7030209@trendmicro.com> In-Reply-To: <4ACF6B32.7030209@trendmicro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 17:12:25.0862 (UTC) FILETIME=[AC576A60:01CA4903] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 17:10:43 -0000 Ben, 1) RFC 4893 has been revised by the following document: http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt 2) Sect. 4.2.3 presents a complete, and precise algorithm for constructing the as-path: ---------------------------------- A NEW BGP speaker should also be prepared to receive the AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an OLD BGP speaker. When both the attributes are received, if the AS number in the AGGREGATOR attribute is not AS_TRANS, then: - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL be ignored, - the AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and - the AS_PATH attribute SHALL be taken as the AS path information. Otherwise, - the AGGREGATOR attribute SHALL be ignored, - the AS4_AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and - the AS path information would need to be constructed, as in all other cases. In order to construct the AS path information, it would be necessary to first calculate the number of AS numbers in the AS_PATH and AS4_PATH attributes using the method specified in Section 9.1.2.2 [RFC4271] and [RFC5065] for route selection. If the number of AS numbers in the AS_PATH attribute is less than the number of AS numbers in the AS4_PATH attribute, then the AS4_PATH attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken as the AS path information. If the number of AS numbers in the AS_PATH attribute is larger than or equal to the number of AS numbers in the AS4_PATH attribute, then the AS path information SHALL be constructed by taking as many AS numbers and path segments as necessary from the leading part of the AS_PATH attribute, and then prepending them to the AS4_PATH attribute so that the AS path information has an identical number of AS numbers as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or AS_CONFED_SET path segment SHALL be prepended if it is either the leading path segment or adjacent to a path segment that is prepended. ----------------------- Please let us know which part of the algorithm that you think is not clear. Regards, -- Enke Benjamin April wrote: > Greetings, > > I find myself in the process of updating one of our BGP > data-collectors to support 4-octet ASNs. I did my best to follow > RFC-4893, however I have a nagging feeling that I don't understand > one element. I hope you folks can point me in the right direction here. > > The language in question is in section 4.2.3. The passages of > particular concern to me are: > > Under certain conditions, it may not be possible to reconstruct the > entire AS path information from the AS_PATH and the AS4_PATH > attributes of a route. This occurs when two or more routes that > carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, > and the AS4_PATH attribute of at least one of these routes carries > at least one 4-octet AS number (as oppose to a 2-octet AS number > that is encoded in 4 octets). Depending on the implementation, > either the AS4_PATH attribute would be lost during route > aggregation, or both the AS_PATH attribute and the AS4_PATH > attribute would contain valid, partial information that cannot be > combined seamlessly, resulting in incomplete AS path information in > these cases. > > and > > In order to construct the AS path information, it would be necessary > to first calculate the number of AS numbers in the AS_PATH and > AS4_PATH attributes using the method specified in Section 9.1.2.2 > [BGP] and [RFC3065] for route selection. If the number of AS numbers > in the AS_PATH attribute is less than the number of AS numbers in > the AS4_PATH attribute, then the AS4_PATH attribute SHALL be > ignored, and the AS_PATH attribute SHALL be taken as the AS path > information. > > > If the number of AS numbers in the AS_PATH attribute is larger than > or equal to the number of AS numbers in the AS4_PATH attribute, then > the AS path information SHALL be constructed by taking as many AS > numbers and path segments as necessary from the leading part of the > AS_PATH attribute, and then prepending them to the AS4_PATH > attribute so that the AS path information has an identical number of > AS numbers as the AS_PATH attribute. > > > > Forgive me, but this all sounds like an awful lot of hand-waving to > me. Has anything been done since this RFC was published to better > describe in a more formal way the procedure a BGP speaker should > follow to re-construct an accurate AS_PATH from the AS4_PATH and > AS_PATH attributes? Based on this description I can see more than > one way to implement this. I would like to do so correctly, but I > need to know what is correct first. > > Thanks > Ben > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From enkechen@cisco.com Fri Oct 9 10:21:00 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C7E3A687C for ; Fri, 9 Oct 2009 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp0ilXoooSXG for ; Fri, 9 Oct 2009 10:20:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 325AB3A68D2 for ; Fri, 9 Oct 2009 10:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5931; q=dns/txt; s=sjiport06001; t=1255108964; x=1256318564; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Enke=20Chen=20|Subject:=20Re :=20[Idr]=20Question=20about=20RFC4893|Date:=20Fri,=2009 =20Oct=202009=2010:22:43=20-0700|Message-ID:=20<4ACF7163. 7060003@cisco.com>|To:=20ben_april@trendmicro.com|CC:=20i dr@ietf.org,=20Enke=20Chen=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4ACF6EF5.10405@cisco.com>|References:=20 <4ACF6B32.7030209@trendmicro.com>=20<4ACF6EF5.10405@cisco .com>; bh=Zw/nSRgIn8mhnwjKaJN76G0ygkHrMsmL9cOZ40rkXwY=; b=aVe2X37ZRQIJSYrqoRHY0OzJsegVsK0sjinTojsVLczMVG7EKF11jusn rhQvCGB1MM1LkpIOSQ++pwK98FGgJ+By+J2P2mm0xW4xrx2MOVbsPCyjR bFoIoJ5VxXlj72ftD8xaaDdziXH6JYnL2pS+ur6oODP0/cctWlak90xlB A=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANoNz0qrR7Ht/2dsb2JhbADDGphKhCwE X-IronPort-AV: E=Sophos;i="4.44,533,1249257600"; d="scan'208";a="405581738" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2009 17:22:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n99HMiMG002507; Fri, 9 Oct 2009 17:22:44 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.3959); Fri, 9 Oct 2009 10:22:43 -0700 Received: from [10.21.121.206] ([10.21.121.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:22:43 -0700 Message-ID: <4ACF7163.7060003@cisco.com> Date: Fri, 09 Oct 2009 10:22:43 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ben_april@trendmicro.com References: <4ACF6B32.7030209@trendmicro.com> <4ACF6EF5.10405@cisco.com> In-Reply-To: <4ACF6EF5.10405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 17:22:43.0483 (UTC) FILETIME=[1C78E6B0:01CA4905] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 17:21:00 -0000 Ben, A correction here: RFC 4893 is being revised (instead of "has been revised") by rfc4893bis. Thanks to an IDR member who pointed out the difference. -- Enke Enke Chen wrote: > Ben, > > 1) RFC 4893 has been revised by the following document: > > http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt > > 2) Sect. 4.2.3 presents a complete, and precise algorithm for > constructing the as-path: > > ---------------------------------- > > A NEW BGP speaker should also be prepared to receive the > AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an > OLD BGP speaker. When both the attributes are received, if the AS > number in the AGGREGATOR attribute is not AS_TRANS, then: > > - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL > be ignored, > > - the AGGREGATOR attribute SHALL be taken as the information > about the aggregating node, and > > - the AS_PATH attribute SHALL be taken as the AS path > information. > > Otherwise, > > - the AGGREGATOR attribute SHALL be ignored, > > - the AS4_AGGREGATOR attribute SHALL be taken as the information > about the aggregating node, and > > - the AS path information would need to be constructed, as in all > other cases. > > In order to construct the AS path information, it would be necessary > to first calculate the number of AS numbers in the AS_PATH and > AS4_PATH attributes using the method specified in Section 9.1.2.2 > [RFC4271] and [RFC5065] for route selection. > > If the number of AS numbers in the AS_PATH attribute is less than the > number of AS numbers in the AS4_PATH attribute, then the AS4_PATH > attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken > as the AS path information. > > If the number of AS numbers in the AS_PATH attribute is larger than > or equal to the number of AS numbers in the AS4_PATH attribute, then > the AS path information SHALL be constructed by taking as many AS > numbers and path segments as necessary from the leading part of the > AS_PATH attribute, and then prepending them to the AS4_PATH attribute > so that the AS path information has an identical number of AS numbers > as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or > AS_CONFED_SET path segment SHALL be prepended if it is either the > leading path segment or adjacent to a path segment that is prepended. > ----------------------- > > Please let us know which part of the algorithm that you think is not > clear. > > Regards, -- Enke > > Benjamin April wrote: >> Greetings, >> >> I find myself in the process of updating one of our BGP >> data-collectors to support 4-octet ASNs. I did my best to follow >> RFC-4893, however I have a nagging feeling that I don't understand >> one element. I hope you folks can point me in the right direction here. >> >> The language in question is in section 4.2.3. The passages of >> particular concern to me are: >> >> Under certain conditions, it may not be possible to reconstruct the >> entire AS path information from the AS_PATH and the AS4_PATH >> attributes of a route. This occurs when two or more routes that >> carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, >> and the AS4_PATH attribute of at least one of these routes carries >> at least one 4-octet AS number (as oppose to a 2-octet AS number >> that is encoded in 4 octets). Depending on the implementation, >> either the AS4_PATH attribute would be lost during route >> aggregation, or both the AS_PATH attribute and the AS4_PATH >> attribute would contain valid, partial information that cannot be >> combined seamlessly, resulting in incomplete AS path information in >> these cases. >> >> and >> >> In order to construct the AS path information, it would be necessary >> to first calculate the number of AS numbers in the AS_PATH and >> AS4_PATH attributes using the method specified in Section 9.1.2.2 >> [BGP] and [RFC3065] for route selection. If the number of AS numbers >> in the AS_PATH attribute is less than the number of AS numbers in >> the AS4_PATH attribute, then the AS4_PATH attribute SHALL be >> ignored, and the AS_PATH attribute SHALL be taken as the AS path >> information. >> >> >> If the number of AS numbers in the AS_PATH attribute is larger than >> or equal to the number of AS numbers in the AS4_PATH attribute, then >> the AS path information SHALL be constructed by taking as many AS >> numbers and path segments as necessary from the leading part of the >> AS_PATH attribute, and then prepending them to the AS4_PATH >> attribute so that the AS path information has an identical number of >> AS numbers as the AS_PATH attribute. >> >> >> >> Forgive me, but this all sounds like an awful lot of hand-waving to >> me. Has anything been done since this RFC was published to better >> describe in a more formal way the procedure a BGP speaker should >> follow to re-construct an accurate AS_PATH from the AS4_PATH and >> AS_PATH attributes? Based on this description I can see more than >> one way to implement this. I would like to do so correctly, but I >> need to know what is correct first. >> >> Thanks >> Ben >> >> TREND MICRO EMAIL NOTICE >> The information contained in this email and any attachments is >> confidential and may be subject to copyright or other intellectual >> property protection. If you are not the intended recipient, you are >> not authorized to use or disclose this information, and we request >> that you notify us by reply mail or telephone and delete the original >> message from your mail system. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > From samitac@ipinfusion.com Fri Oct 9 11:06:02 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E534428C168 for ; Fri, 9 Oct 2009 11:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7gbigO9qO5J for ; Fri, 9 Oct 2009 11:06:01 -0700 (PDT) Received: from n13b.bullet.mail.mud.yahoo.com (n13b.bullet.mail.mud.yahoo.com [68.142.207.222]) by core3.amsl.com (Postfix) with SMTP id 7FD5D28C0F0 for ; Fri, 9 Oct 2009 11:06:01 -0700 (PDT) Received: from [68.142.200.224] by n13.bullet.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 18:07:45 -0000 Received: from [68.142.201.69] by t5.bullet.mud.yahoo.com with NNFMP; 09 Oct 2009 18:07:45 -0000 Received: from [127.0.0.1] by omp421.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 18:07:45 -0000 X-Yahoo-Newman-Id: 57833.52291.bm@omp421.mail.mud.yahoo.com Received: (qmail 23405 invoked from network); 9 Oct 2009 18:07:44 -0000 Received: from (samitac@65.223.109.250 with login) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 09 Oct 2009 11:07:44 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 9dS4_6cVM1kafUW9Cu3bCBrhkHyWH6dZlEOSoD6oOycnKWb20EWxhWbH6ofXjyEk_4.eSQ1l_FX5IWETUb0gN4VoKbXFPnh9q.fAv4YWD8ZqGHuYtAxK5ub0GN16hErKcm.WykxOcS7aBXecmBioO8rZuf4l9vkiWD6WJv4jGGAkDY1Ou5OOXhtfG6zbPArV66BhsYgavWmrYWzcj.rNOa6AlNQfAzXjGorJ6FgAtLgX0XN3ZJN6Z0sixI7IRrzaw8gTnqXwBTj7qgkwfIiSyv_47hXFnGts_Q-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: , References: <4ACF6B32.7030209@trendmicro.com> In-Reply-To: <4ACF6B32.7030209@trendmicro.com> Date: Fri, 9 Oct 2009 11:07:42 -0700 Message-ID: <00d801ca490b$65507500$2ff15f00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpJARgBY55GtpWiQxyQFA/QbJVeLgABVUAQ Content-Language: en-us Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 18:06:03 -0000 Hi Ben, Please see below: > If the number of AS numbers in the AS_PATH attribute is larger than or equal > to the number of AS numbers in the AS4_PATH attribute, then the AS path > information SHALL be constructed by taking as many AS numbers and path > segments as necessary from the leading part of the AS_PATH attribute, and > then prepending them to the AS4_PATH attribute so that the AS path > information has an identical number of AS numbers as the AS_PATH attribute. > > > > Forgive me, but this all sounds like an awful lot of hand-waving to me. Has > anything been done since this RFC was published to better describe in a more > formal way the procedure a BGP speaker should follow to re-construct an > accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based on this > description I can see more than one way to implement this. I would like to > do so correctly, but I need to know what is correct first. > > Thanks > Ben > [SC>] I agree with you completely this handwaving portion in rfc 4893 is very problematic to the implementers who were not directly involved in the making of RFC 4893. I was not one of them. In 2008, I wrote a draft pointing out some of the problems we faced during implementation and to request an update of the RFC for future interoperability. Also presented the draft at WG in Spring 2008 IETF. Rfc4893-bis has considered some of the problems mentioned in the draft + others discussed in the working group alias. http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/ The following interpretation has been made in our implementation after talking with some other implementers. I believe rfc4893-bis now has the similar text: 1. If the number of ASNs in AS_PATH is less than the number of ASNs in AS4_PATH, then NBGP ignores AS4_PATH information. Example: AS_PATH: 2 23456 AS4_PATH: 70000 70001 70002 2. If the number of ASNs in AS_PATH attribute is greater than number of ASNs in AS4_PATH attribute, then there must be a few AS_TRANS numbers in AS_PATH. Reconstruct AS_PATH based on the AS4_PATH items corresponding to AS_TRANS numbers Examples: AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456 AS4_PATH: 65356, 77777 3. If the number of ASNs in AS_PATH and AS4_PATH attributes is same then it most likely means that all the AS numbers are AS4-byte unmappable numbers. Check the count of AS_TRANS numbers in AS_PATH and count of AS numbers in AS4_PATH. If they are the same then reconstruct AS information from AS4_PATH only (note this case is for AS num == AS4 num). If number of AS_TRANS in AS_PATH is less than the number in AS4_PATH values, then there is something wrong done by previous speakers. However, take the non-AS_TRANS AS values from AS_PATH and then prepend them with the AS4 values. Some examples will clarify this case: AS_PATH: 23456, 23456, 23456 AS4_PATH: 777777, 66666, 88888 Or AS_PATH: 2, 3, 4, 23456 AS4_PATH: 88888, 99999, 70000, 80000 Thanks, -Samita From enkechen@cisco.com Fri Oct 9 11:56:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F193A6841 for ; Fri, 9 Oct 2009 11:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eiam0DFkeTP6 for ; Fri, 9 Oct 2009 11:56:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5118B3A681B for ; Fri, 9 Oct 2009 11:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=4887; q=dns/txt; s=sjiport01001; t=1255114696; x=1256324296; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Enke=20Chen=20|Subject:=20Re :=20[Idr]=20Question=20about=20RFC4893|Date:=20Fri,=2009 =20Oct=202009=2011:58:15=20-0700|Message-ID:=20<4ACF87C7. 1090404@cisco.com>|To:=20Samita=20Chakrabarti=20|CC:=20ben_april@trendmicro.com,=20idr@iet f.org,=20Enke=20Chen=20|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20< 00d801ca490b$65507500$2ff15f00$@com>|References:=20<4ACF6 B32.7030209@trendmicro.com>=20<00d801ca490b$65507500$2ff1 5f00$@com>; bh=7cEhFa/RyCnsxBWiMEO25nqkeRtGM38HNAYOXTslOKo=; b=hPvD8WeCp4U0F+Y6SWTJ5+NKngtS5aBhCjlK5so//hp0NDeu2SNicSII OY1hm3apHfBcokF4xWJPQkIQ5G7UUjdHSOFUJD0AggGZzCWe9kuDA92eB vDmbks8dIjlKWvHPSjcB/XhoQkyds7tSUzwjc1bKpjapfQDR9EsNkGBrk s=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA8lz0qrR7Hu/2dsb2JhbADCfphChCwE X-IronPort-AV: E=Sophos;i="4.44,533,1249257600"; d="scan'208";a="253709489" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2009 18:58:16 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n99IwG76021757; Fri, 9 Oct 2009 18:58:16 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.3959); Fri, 9 Oct 2009 11:58:16 -0700 Received: from [10.21.121.206] ([10.21.121.206]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:58:15 -0700 Message-ID: <4ACF87C7.1090404@cisco.com> Date: Fri, 09 Oct 2009 11:58:15 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Samita Chakrabarti References: <4ACF6B32.7030209@trendmicro.com> <00d801ca490b$65507500$2ff15f00$@com> In-Reply-To: <00d801ca490b$65507500$2ff15f00$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 18:58:15.0734 (UTC) FILETIME=[7528FD60:01CA4912] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 18:56:32 -0000 Samita: We can argue about the presentation style and other portions in RFC4893. However, IMO the specific merge algorithm is complete, and precise, as I pointed out to Ben. Please see my comments inlined. Samita Chakrabarti wrote: > Hi Ben, > > Please see below: > > >> If the number of AS numbers in the AS_PATH attribute is larger than or >> > equal > >> to the number of AS numbers in the AS4_PATH attribute, then the AS path >> information SHALL be constructed by taking as many AS numbers and path >> segments as necessary from the leading part of the AS_PATH attribute, and >> then prepending them to the AS4_PATH attribute so that the AS path >> information has an identical number of AS numbers as the AS_PATH >> > attribute. > >> >> Forgive me, but this all sounds like an awful lot of hand-waving to me. >> > Has > >> anything been done since this RFC was published to better describe in a >> > more > >> formal way the procedure a BGP speaker should follow to re-construct an >> accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based on this >> description I can see more than one way to implement this. I would like to >> do so correctly, but I need to know what is correct first. >> >> Thanks >> Ben >> >> > [SC>] > > I agree with you completely this handwaving portion in rfc 4893 is very > problematic to the implementers who were not directly involved in the making > of RFC 4893. I was not one of them. In 2008, I wrote a draft pointing out > some of the problems we faced during implementation and to request an update > of the RFC for future interoperability. Also presented the draft at WG in > Spring 2008 IETF. Rfc4893-bis has considered some of the problems mentioned > in the draft + others discussed in the working group alias. > http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/ > > The following interpretation has been made in our implementation after > talking with some other implementers. > I believe rfc4893-bis now has the similar text: > 1. If the number of ASNs in AS_PATH is less than the number of ASNs in > AS4_PATH, then NBGP ignores AS4_PATH information. > Example: > AS_PATH: 2 23456 > AS4_PATH: 70000 70001 70002 > RFC 4893 has the following text in Sect. 4.2.3: If the number of AS numbers in the AS_PATH attribute is less than the number of AS numbers in the AS4_PATH attribute, then the AS4_PATH attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken as the AS path information. -------------------------------------------- I am wondering why this portion needed "interpretation" in your implementation. > 2. If the number of ASNs in AS_PATH attribute is greater than number of > > ASNs in AS4_PATH attribute, then there must be a few AS_TRANS > numbers in AS_PATH. Reconstruct AS_PATH based on the AS4_PATH > items corresponding to AS_TRANS numbers > Examples: > AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456 > AS4_PATH: 65356, 77777 > So what exactly is the problem with following RFC 4893 in this case? The (AS_PATH, AS4_PATH) is not really consistent here -- that is, 65356 is not represented in AS_PATH, and there is an extra 23456 in the middle. Most likely this is a crafted, lab scenario in which there is no single "correct" answer. > 3. If the number of ASNs in AS_PATH and AS4_PATH attributes is same > then it most likely means that all the AS numbers are AS4-byte unmappable > numbers. Check the count of AS_TRANS numbers in AS_PATH and count of AS > numbers in AS4_PATH. If they are the same then reconstruct AS information > from AS4_PATH only (note this case is for AS num == AS4 num). If number of > AS_TRANS in AS_PATH is less than the number in AS4_PATH values, then there > is something wrong done by previous speakers. However, take the non-AS_TRANS > AS values from AS_PATH and then prepend them with the AS4 values. Some > examples will clarify this case: > AS_PATH: 23456, 23456, 23456 > AS4_PATH: 777777, 66666, 88888 > So the merged as-path would consist of the valid AS numbers 777777, 66666, 88888 based on RFC 4893. This seems fine. Isn't it? > Or > AS_PATH: 2, 3, 4, 23456 > AS4_PATH: 88888, 99999, 70000, 80000 > This again is another inconsistent, artificially crafted scenario. Possibly there are more than one "correct" solutions, some more "correct" than others - depending on how the inconsistency was generated. As the as-path length must be maintained during the merge, no solution can possibly include all the valid AS numbers contained in AS_PATH / AS4_PATH. RFC 4893 would yield 88888, 99999, 70000, 80000 as the merged one. Why wouldn't it be good enough? Thanks. -- Enke From samitac@ipinfusion.com Fri Oct 9 12:03:06 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5697F3A687B for ; Fri, 9 Oct 2009 12:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgczoRfPudF3 for ; Fri, 9 Oct 2009 12:03:05 -0700 (PDT) Received: from n61.bullet.mail.sp1.yahoo.com (n61.bullet.mail.sp1.yahoo.com [98.136.44.37]) by core3.amsl.com (Postfix) with SMTP id 2643E3A681B for ; Fri, 9 Oct 2009 12:03:05 -0700 (PDT) Received: from [216.252.122.219] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 09 Oct 2009 19:04:48 -0000 Received: from [68.142.194.243] by t4.bullet.sp1.yahoo.com with NNFMP; 09 Oct 2009 19:04:48 -0000 Received: from [68.142.201.66] by t1.bullet.mud.yahoo.com with NNFMP; 09 Oct 2009 19:04:48 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 09 Oct 2009 19:04:48 -0000 X-Yahoo-Newman-Id: 743061.38533.bm@omp418.mail.mud.yahoo.com Received: (qmail 46990 invoked from network); 9 Oct 2009 19:04:48 -0000 Received: from (samitac@65.223.109.250 with login) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 09 Oct 2009 12:04:47 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: pLFPJ4kVM1lY76op0RDcrzZXYQIqQsluPqyI4AoIOOZ28pol_ICA91AQ3QoRwKloRo7IY7jvUbPaV.PtwoHrodDBQQ5WigntjM2PU_SmhZtB_.OmBU5moRJ_d8MXKXkvc9j.0jvNXh4lMTrfJVTMtQ8NpngX2llguA8zs4F_CbEiWkf987ds81dPt5W5U4lQwqIMfw0_JsEMKzxyutkWBkGRog_.MDmNsDW_WSzMePtg2Cgz_G8Vis4pVJl0NcSEF7SHz8j6Q47Y2u2GSsr4F6gDa9chDQGxVA-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Enke Chen'" References: <4ACF6B32.7030209@trendmicro.com> <00d801ca490b$65507500$2ff15f00$@com> <4ACF87C7.1090404@cisco.com> In-Reply-To: <4ACF87C7.1090404@cisco.com> Date: Fri, 9 Oct 2009 12:04:45 -0700 Message-ID: <00e901ca4913$5db8aa30$1929fe90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpJEiJ3awJf8XCtQsqQ1e78LvOH/QAAPRBw Content-Language: en-us Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:03:06 -0000 Hi Enke, I am OK with the current text in rfc4893-bis that you already pointed out. I provided some additional examples for clarification and for the purpose of discussion. Cheers, -Samita > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Friday, October 09, 2009 11:58 AM > To: Samita Chakrabarti > Cc: ben_april@trendmicro.com; idr@ietf.org; Enke Chen > Subject: Re: [Idr] Question about RFC4893 > > Samita: > > We can argue about the presentation style and other portions in RFC4893. > However, IMO the specific merge algorithm is complete, and precise, as I > pointed out to Ben. > > Please see my comments inlined. > > Samita Chakrabarti wrote: > > Hi Ben, > > > > Please see below: > > > > > >> If the number of AS numbers in the AS_PATH attribute is larger than > >> or > >> > > equal > > > >> to the number of AS numbers in the AS4_PATH attribute, then the AS > >> path information SHALL be constructed by taking as many AS numbers > >> and path segments as necessary from the leading part of the AS_PATH > >> attribute, and then prepending them to the AS4_PATH attribute so that > >> the AS path information has an identical number of AS numbers as the > >> AS_PATH > >> > > attribute. > > > >> > >> Forgive me, but this all sounds like an awful lot of hand-waving to me. > >> > > Has > > > >> anything been done since this RFC was published to better describe in > >> a > >> > > more > > > >> formal way the procedure a BGP speaker should follow to re-construct > >> an accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based > >> on this description I can see more than one way to implement this. I > >> would like to do so correctly, but I need to know what is correct first. > >> > >> Thanks > >> Ben > >> > >> > > [SC>] > > > > I agree with you completely this handwaving portion in rfc 4893 is > > very problematic to the implementers who were not directly involved in > > the making of RFC 4893. I was not one of them. In 2008, I wrote a > > draft pointing out some of the problems we faced during implementation > > and to request an update of the RFC for future interoperability. Also > > presented the draft at WG in Spring 2008 IETF. Rfc4893-bis has > > considered some of the problems mentioned in the draft + others discussed > in the working group alias. > > http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/ > > > > The following interpretation has been made in our implementation after > > talking with some other implementers. > > I believe rfc4893-bis now has the similar text: > > 1. If the number of ASNs in AS_PATH is less than the number of ASNs in > > AS4_PATH, then NBGP ignores AS4_PATH information. > > Example: > > AS_PATH: 2 23456 > > AS4_PATH: 70000 70001 70002 > > > > RFC 4893 has the following text in Sect. 4.2.3: > > If the number of AS numbers in the AS_PATH attribute is less than the > number of AS numbers in the AS4_PATH attribute, then the AS4_PATH > attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken > as the AS path information. > > -------------------------------------------- > > I am wondering why this portion needed "interpretation" in your > implementation. > > > > 2. If the number of ASNs in AS_PATH attribute is greater than number of > > > > ASNs in AS4_PATH attribute, then there must be a few AS_TRANS > > numbers in AS_PATH. Reconstruct AS_PATH based on the AS4_PATH > > items corresponding to AS_TRANS numbers > > Examples: > > AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456 > > AS4_PATH: 65356, 77777 > > > > So what exactly is the problem with following RFC 4893 in this case? > The (AS_PATH, AS4_PATH) is > not really consistent here -- that is, 65356 is not represented in > AS_PATH, and there is an extra 23456 in > the middle. Most likely this is a crafted, lab scenario in which there > is no single "correct" answer. > > > 3. If the number of ASNs in AS_PATH and AS4_PATH attributes is same > > then it most likely means that all the AS numbers are AS4-byte unmappable > > numbers. Check the count of AS_TRANS numbers in AS_PATH and count of AS > > numbers in AS4_PATH. If they are the same then reconstruct AS information > > from AS4_PATH only (note this case is for AS num == AS4 num). If number of > > AS_TRANS in AS_PATH is less than the number in AS4_PATH values, then there > > is something wrong done by previous speakers. However, take the non- > AS_TRANS > > AS values from AS_PATH and then prepend them with the AS4 values. Some > > examples will clarify this case: > > AS_PATH: 23456, 23456, 23456 > > AS4_PATH: 777777, 66666, 88888 > > > > So the merged as-path would consist of the valid AS numbers 777777, > 66666, 88888 based on RFC 4893. > This seems fine. Isn't it? > > > Or > > AS_PATH: 2, 3, 4, 23456 > > AS4_PATH: 88888, 99999, 70000, 80000 > > > > This again is another inconsistent, artificially crafted scenario. > Possibly there are more than one "correct" > solutions, some more "correct" than others - depending on how the > inconsistency was generated. As > the as-path length must be maintained during the merge, no solution can > possibly include all the valid AS > numbers contained in AS_PATH / AS4_PATH. > > RFC 4893 would yield 88888, 99999, 70000, 80000 as the merged one. Why > wouldn't it be good enough? > > Thanks. -- Enke > From enkechen@cisco.com Fri Oct 9 12:09:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99553A68EA for ; Fri, 9 Oct 2009 12:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gq9Y4NDb2Iu for ; Fri, 9 Oct 2009 12:09:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 456FE3A6819 for ; Fri, 9 Oct 2009 12:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5541; q=dns/txt; s=sjiport03001; t=1255115433; x=1256325033; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Enke=20Chen=20|Subject:=20Re :=20[Idr]=20Question=20about=20RFC4893|Date:=20Fri,=2009 =20Oct=202009=2012:10:32=20-0700|Message-ID:=20<4ACF8AA8. 1050704@cisco.com>|To:=20Samita=20Chakrabarti=20|CC:=20ben_april@trendmicro.com,=20idr@iet f.org,=20Enke=20Chen=20|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20< 4ACF87C7.1090404@cisco.com>|References:=20<4ACF6B32.70302 09@trendmicro.com>=20<00d801ca490b$65507500$2ff15f00$@com >=20<4ACF87C7.1090404@cisco.com>; bh=J5vg3eceyiirj8yahJ6A4s1Idcxfd6Q+9ySfzN05EMM=; b=ZLHnWbxZL12vlB55lCcWzpR+teYsbtWu1y5NjN0RdWpntxkjHv6EAOJ1 b/NYljuQIxZfS3cgwh0A+V1The30Tq+9HOjj5VwsPfneV/UBj0Me5AyB8 HuLM7LDQ8PMzZiUYGAUJKNf48FCvjsyCnFwuTkP2aIR6xPCDDi9Rs4IqD E=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO8mz0qrRN+J/2dsb2JhbADCdphDhCwEgVg X-IronPort-AV: E=Sophos;i="4.44,533,1249257600"; d="scan'208";a="195885278" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2009 19:10:33 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n99JAXbV001689; Fri, 9 Oct 2009 19:10:33 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.3959); Fri, 9 Oct 2009 12:10:33 -0700 Received: from [10.21.121.206] ([10.21.121.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 12:10:32 -0700 Message-ID: <4ACF8AA8.1050704@cisco.com> Date: Fri, 09 Oct 2009 12:10:32 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Samita Chakrabarti References: <4ACF6B32.7030209@trendmicro.com> <00d801ca490b$65507500$2ff15f00$@com> <4ACF87C7.1090404@cisco.com> In-Reply-To: <4ACF87C7.1090404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 19:10:32.0851 (UTC) FILETIME=[2C841E30:01CA4914] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:09:15 -0000 BTW, based on the on-line IETF track tool, there has been no change in the merge algorithm (Sect 4.2.3) from RFC 4893 to rfc4893bis-00.txt and to rfc4893bis-01.txt: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-rfc4893bis-00.txt http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr-rfc4893bis-01.txt Regards, -- Enke Enke Chen wrote: > Samita: > > We can argue about the presentation style and other portions in > RFC4893. However, IMO the specific > merge algorithm is complete, and precise, as I pointed out to Ben. > > Please see my comments inlined. > > Samita Chakrabarti wrote: >> Hi Ben, >> >> Please see below: >> >> >>> If the number of AS numbers in the AS_PATH attribute is larger than or >>> >> equal >> >>> to the number of AS numbers in the AS4_PATH attribute, then the AS path >>> information SHALL be constructed by taking as many AS numbers and path >>> segments as necessary from the leading part of the AS_PATH >>> attribute, and >>> then prepending them to the AS4_PATH attribute so that the AS path >>> information has an identical number of AS numbers as the AS_PATH >>> >> attribute. >> >>> >>> Forgive me, but this all sounds like an awful lot of hand-waving to me. >>> >> Has >> >>> anything been done since this RFC was published to better describe in a >>> >> more >> >>> formal way the procedure a BGP speaker should follow to re-construct an >>> accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based on >>> this >>> description I can see more than one way to implement this. I would >>> like to >>> do so correctly, but I need to know what is correct first. >>> >>> Thanks >>> Ben >>> >>> >> [SC>] >> I agree with you completely this handwaving portion in rfc 4893 is very >> problematic to the implementers who were not directly involved in the >> making >> of RFC 4893. I was not one of them. In 2008, I wrote a draft >> pointing out >> some of the problems we faced during implementation and to request an >> update >> of the RFC for future interoperability. Also presented the draft at >> WG in >> Spring 2008 IETF. Rfc4893-bis has considered some of the problems >> mentioned >> in the draft + others discussed in the working group alias. >> http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/ >> >> The following interpretation has been made in our implementation after >> talking with some other implementers. >> I believe rfc4893-bis now has the similar text: >> 1. If the number of ASNs in AS_PATH is less than the number of >> ASNs in >> AS4_PATH, then NBGP ignores AS4_PATH information. >> Example: >> AS_PATH: 2 23456 >> AS4_PATH: 70000 70001 70002 >> > > RFC 4893 has the following text in Sect. 4.2.3: > > If the number of AS numbers in the AS_PATH attribute is less than the > number of AS numbers in the AS4_PATH attribute, then the AS4_PATH > attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken > as the AS path information. > > -------------------------------------------- > > I am wondering why this portion needed "interpretation" in your > implementation. > > >> 2. If the number of ASNs in AS_PATH attribute is greater than >> number of >> >> ASNs in AS4_PATH attribute, then there must be a few >> AS_TRANS numbers in AS_PATH. Reconstruct AS_PATH based on >> the AS4_PATH items corresponding to AS_TRANS numbers >> Examples: >> AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456 >> AS4_PATH: 65356, 77777 >> > > So what exactly is the problem with following RFC 4893 in this case? > The (AS_PATH, AS4_PATH) is > not really consistent here -- that is, 65356 is not represented in > AS_PATH, and there is an extra 23456 in > the middle. Most likely this is a crafted, lab scenario in which > there is no single "correct" answer. > >> 3. If the number of ASNs in AS_PATH and AS4_PATH attributes is same >> then it most likely means that all the AS numbers are AS4-byte >> unmappable >> numbers. Check the count of AS_TRANS numbers in AS_PATH and count of AS >> numbers in AS4_PATH. If they are the same then reconstruct AS >> information >> from AS4_PATH only (note this case is for AS num == AS4 num). If >> number of >> AS_TRANS in AS_PATH is less than the number in AS4_PATH values, then >> there >> is something wrong done by previous speakers. However, take the >> non-AS_TRANS >> AS values from AS_PATH and then prepend them with the AS4 values. Some >> examples will clarify this case: >> AS_PATH: 23456, 23456, 23456 >> AS4_PATH: 777777, 66666, 88888 >> > > So the merged as-path would consist of the valid AS numbers 777777, > 66666, 88888 based on RFC 4893. > This seems fine. Isn't it? > >> Or >> AS_PATH: 2, 3, 4, 23456 >> AS4_PATH: 88888, 99999, 70000, 80000 >> > > This again is another inconsistent, artificially crafted scenario. > Possibly there are more than one "correct" > solutions, some more "correct" than others - depending on how the > inconsistency was generated. As > the as-path length must be maintained during the merge, no solution > can possibly include all the valid AS > numbers contained in AS_PATH / AS4_PATH. > > RFC 4893 would yield 88888, 99999, 70000, 80000 as the merged one. > Why wouldn't it be good enough? > > Thanks. -- Enke > > From samitac@ipinfusion.com Fri Oct 9 12:27:26 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1324B3A68A8 for ; Fri, 9 Oct 2009 12:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpXi5GT2qCBE for ; Fri, 9 Oct 2009 12:27:24 -0700 (PDT) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id AE7AE3A6872 for ; Fri, 9 Oct 2009 12:27:24 -0700 (PDT) Received: (qmail 34535 invoked from network); 9 Oct 2009 19:29:08 -0000 Received: from (samitac@65.223.109.250 with login) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 09 Oct 2009 12:29:07 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: 0QTFL4AVM1nwhUzMMPc37WVXCEEugWgWlHVtb2qU_43Y1TenUuV7kIaz_p1T8GE6ZVHsgGrELSK9bhMxKgTQwq5Gjl.VThROWcNk9tNdyYt_sGKHnMHmZ2xMpcSXiBBkGgSH3d41IR6HFxQ9MW7MkxDIjdFY0KSPaa6MP3HpKRhsII9gnstBIKfFB0orv8HUJJKVJ0c1JDG402CsQpsQtEqqw7Hpc1QQH8hzsqBXccGqRYmscV6lKQsdnKmcWUK1qYLNI0BJAbL4z376yxxTaD6SsG8Ct4rZwQ-- X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Enke Chen'" References: <4ACF6B32.7030209@trendmicro.com> <00d801ca490b$65507500$2ff15f00$@com> <4ACF87C7.1090404@cisco.com> <4ACF8AA8.1050704@cisco.com> In-Reply-To: <4ACF8AA8.1050704@cisco.com> Date: Fri, 9 Oct 2009 12:29:04 -0700 Message-ID: <00ea01ca4916$c3a09670$4ae1c350$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpJE9Fo0pXy0SM6SCaH4Qtq/FwL1QAAbn0A Content-Language: en-us Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:27:26 -0000 Hi Enke, You are right in pointing out that there is no change from RFC4893 merging text into the bis versions . I replied too fast. It's been a long time since we implemented this, but I remember it was not clear at that time and we had to do some interpretation of the text in RFC. Below, you have discussed the merged AS-PATH examples with the sample scenarios I provided. Do you think you can include some of those examples in the text for clarification? That might be helpful for the future implementations for clarity. Just a suggestion... Thanks, -Samita > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Friday, October 09, 2009 12:11 PM > To: Samita Chakrabarti > Cc: ben_april@trendmicro.com; idr@ietf.org; Enke Chen > Subject: Re: [Idr] Question about RFC4893 > > BTW, based on the on-line IETF track tool, there has been no change in the > merge algorithm (Sect 4.2.3) from RFC 4893 to rfc4893bis-00.txt and to > rfc4893bis-01.txt: > > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr- > rfc4893bis-00.txt > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr- > rfc4893bis-01.txt > > Regards, -- Enke > > Enke Chen wrote: > > Samita: > > > > We can argue about the presentation style and other portions in > > RFC4893. However, IMO the specific merge algorithm is complete, and > > precise, as I pointed out to Ben. > > > > Please see my comments inlined. > > > > Samita Chakrabarti wrote: > >> Hi Ben, > >> > >> Please see below: > >> > >> > >>> If the number of AS numbers in the AS_PATH attribute is larger than > >>> or > >>> > >> equal > >> > >>> to the number of AS numbers in the AS4_PATH attribute, then the AS > >>> path information SHALL be constructed by taking as many AS numbers > >>> and path segments as necessary from the leading part of the AS_PATH > >>> attribute, and then prepending them to the AS4_PATH attribute so > >>> that the AS path information has an identical number of AS numbers > >>> as the AS_PATH > >>> > >> attribute. > >> > >>> > >>> Forgive me, but this all sounds like an awful lot of hand-waving to me. > >>> > >> Has > >> > >>> anything been done since this RFC was published to better describe > >>> in a > >>> > >> more > >> > >>> formal way the procedure a BGP speaker should follow to re-construct > >>> an accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based > >>> on this description I can see more than one way to implement this. I > >>> would like to do so correctly, but I need to know what is correct > >>> first. > >>> > >>> Thanks > >>> Ben > >>> > >>> > >> [SC>] > >> I agree with you completely this handwaving portion in rfc 4893 is > >> very problematic to the implementers who were not directly involved > >> in the making of RFC 4893. I was not one of them. In 2008, I wrote a > >> draft pointing out some of the problems we faced during > >> implementation and to request an update of the RFC for future > >> interoperability. Also presented the draft at WG in Spring 2008 IETF. > >> Rfc4893-bis has considered some of the problems mentioned in the > >> draft + others discussed in the working group alias. > >> http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/ > >> > >> The following interpretation has been made in our implementation > >> after talking with some other implementers. > >> I believe rfc4893-bis now has the similar text: > >> 1. If the number of ASNs in AS_PATH is less than the number of > >> ASNs in > >> AS4_PATH, then NBGP ignores AS4_PATH information. > >> Example: > >> AS_PATH: 2 23456 > >> AS4_PATH: 70000 70001 70002 > >> > > > > RFC 4893 has the following text in Sect. 4.2.3: > > > > If the number of AS numbers in the AS_PATH attribute is less than the > > number of AS numbers in the AS4_PATH attribute, then the AS4_PATH > > attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken > > as the AS path information. > > > > -------------------------------------------- > > > > I am wondering why this portion needed "interpretation" in your > > implementation. > > > > > >> 2. If the number of ASNs in AS_PATH attribute is greater than > >> number of > >> > >> ASNs in AS4_PATH attribute, then there must be a few > >> AS_TRANS numbers in AS_PATH. Reconstruct AS_PATH based on > >> the AS4_PATH items corresponding to AS_TRANS numbers > >> Examples: > >> AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456 > >> AS4_PATH: 65356, 77777 > >> > > > > So what exactly is the problem with following RFC 4893 in this case? > > The (AS_PATH, AS4_PATH) is > > not really consistent here -- that is, 65356 is not represented in > > AS_PATH, and there is an extra 23456 in the middle. Most likely this > > is a crafted, lab scenario in which there is no single "correct" > > answer. > > > >> 3. If the number of ASNs in AS_PATH and AS4_PATH attributes is same > >> then it most likely means that all the AS numbers are AS4-byte > >> unmappable numbers. Check the count of AS_TRANS numbers in AS_PATH > >> and count of AS numbers in AS4_PATH. If they are the same then > >> reconstruct AS information from AS4_PATH only (note this case is for > >> AS num == AS4 num). If number of AS_TRANS in AS_PATH is less than the > >> number in AS4_PATH values, then there is something wrong done by > >> previous speakers. However, take the non-AS_TRANS AS values from > >> AS_PATH and then prepend them with the AS4 values. Some examples > >> will clarify this case: > >> AS_PATH: 23456, 23456, 23456 > >> AS4_PATH: 777777, 66666, 88888 > >> > > > > So the merged as-path would consist of the valid AS numbers 777777, > > 66666, 88888 based on RFC 4893. > > This seems fine. Isn't it? > > > >> Or > >> AS_PATH: 2, 3, 4, 23456 > >> AS4_PATH: 88888, 99999, 70000, 80000 > >> > > > > This again is another inconsistent, artificially crafted scenario. > > Possibly there are more than one "correct" > > solutions, some more "correct" than others - depending on how the > > inconsistency was generated. As the as-path length must be maintained > > during the merge, no solution can possibly include all the valid AS > > numbers contained in AS_PATH / AS4_PATH. > > > > RFC 4893 would yield 88888, 99999, 70000, 80000 as the merged one. > > Why wouldn't it be good enough? > > > > Thanks. -- Enke > > > > From enkechen@cisco.com Fri Oct 9 18:22:50 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE7A3A69F4 for ; Fri, 9 Oct 2009 18:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ1Op6xWIGSi for ; Fri, 9 Oct 2009 18:22:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 22EB13A672E for ; Fri, 9 Oct 2009 18:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=7187; q=dns/txt; s=sjiport01001; t=1255137872; x=1256347472; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Enke=20Chen=20|Subject:=20Re :=20[Idr]=20Question=20about=20RFC4893|Date:=20Fri,=2009 =20Oct=202009=2018:24:31=20-0700|Message-ID:=20<4ACFE24F. 1080100@cisco.com>|To:=20Samita=20Chakrabarti=20|CC:=20ben_april@trendmicro.com,=20idr@iet f.org,=0D=0A=20=20=20=20=20=20=20=20"Enke=20Chen=20(enkec hen)"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<00ea01 ca4916$c3a09670$4ae1c350$@com>|References:=20<4ACF6B32.70 30209@trendmicro.com>=20<00d801ca490b$65507500$2ff15f00$@ com>=20<4ACF87C7.1090404@cisco.com>=20<4ACF8AA8.1050704@c isco.com>=20<00ea01ca4916$c3a09670$4ae1c350$@com>; bh=jDpi4Tc3eoYXwq+CUHkkWo0amnYR40v//9XGIFJXdo0=; b=qepcTqstbWlqd2FoPjyXdd0jOdwgDyUpJVUEWdu5qwCpUOLhDngzdJH+ VC+Y2gWP56PwfhZMHTMDhZ+nLFcQ2CEIKa9BTg2jdBDotBuIDY8YB0A90 v4UCju2swGHxGmkCDFpkcnIgRxIE5ffMXWKCJyy9ZS0kOB88jMdF3aEz9 E=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA5/z0qrRN+J/2dsb2JhbADCN5gwhCwEgVg X-IronPort-AV: E=Sophos;i="4.44,535,1249257600"; d="scan'208";a="253870325" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2009 01:24:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9A1OVDf004195; Sat, 10 Oct 2009 01:24: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.3959); Fri, 9 Oct 2009 18:24:31 -0700 Received: from [171.71.139.253] ([171.71.139.253]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 18:24:31 -0700 Message-ID: <4ACFE24F.1080100@cisco.com> Date: Fri, 09 Oct 2009 18:24:31 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Samita Chakrabarti References: <4ACF6B32.7030209@trendmicro.com> <00d801ca490b$65507500$2ff15f00$@com> <4ACF87C7.1090404@cisco.com> <4ACF8AA8.1050704@cisco.com> <00ea01ca4916$c3a09670$4ae1c350$@com> In-Reply-To: <00ea01ca4916$c3a09670$4ae1c350$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2009 01:24:31.0430 (UTC) FILETIME=[6AF38E60:01CA4948] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 01:22:50 -0000 Hi, Samita: Samita Chakrabarti wrote: > Hi Enke, > > You are right in pointing out that there is no change from RFC4893 merging > text into the bis versions . I replied too fast. It's been a long time since > we implemented this, but I remember it was not clear at that time and we had > to do some interpretation of the text in RFC. > > Below, you have discussed the merged AS-PATH examples with the sample > scenarios I provided. > Do you think you can include some of those examples in the text for > clarification? That might be helpful for the future implementations for > clarity. Just a suggestion... > If we agree that the merge algorithm described in the document is applicable for these examples (mostly with crafted, inconsistent data), then I am not sure if there is still value in including them in rfc4893bis. Regards, -- Enke > Thanks, > -Samita > > >> -----Original Message----- >> From: Enke Chen [mailto:enkechen@cisco.com] >> Sent: Friday, October 09, 2009 12:11 PM >> To: Samita Chakrabarti >> Cc: ben_april@trendmicro.com; idr@ietf.org; Enke Chen >> Subject: Re: [Idr] Question about RFC4893 >> >> BTW, based on the on-line IETF track tool, there has been no change in >> > the > >> merge algorithm (Sect 4.2.3) from RFC 4893 to rfc4893bis-00.txt and to >> rfc4893bis-01.txt: >> >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr- >> rfc4893bis-00.txt >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-idr- >> rfc4893bis-01.txt >> >> Regards, -- Enke >> >> Enke Chen wrote: >> >>> Samita: >>> >>> We can argue about the presentation style and other portions in >>> RFC4893. However, IMO the specific merge algorithm is complete, and >>> precise, as I pointed out to Ben. >>> >>> Please see my comments inlined. >>> >>> Samita Chakrabarti wrote: >>> >>>> Hi Ben, >>>> >>>> Please see below: >>>> >>>> >>>> >>>>> If the number of AS numbers in the AS_PATH attribute is larger than >>>>> or >>>>> >>>>> >>>> equal >>>> >>>> >>>>> to the number of AS numbers in the AS4_PATH attribute, then the AS >>>>> path information SHALL be constructed by taking as many AS numbers >>>>> and path segments as necessary from the leading part of the AS_PATH >>>>> attribute, and then prepending them to the AS4_PATH attribute so >>>>> that the AS path information has an identical number of AS numbers >>>>> as the AS_PATH >>>>> >>>>> >>>> attribute. >>>> >>>> >>>>> Forgive me, but this all sounds like an awful lot of hand-waving to >>>>> > me. > >>>> Has >>>> >>>> >>>>> anything been done since this RFC was published to better describe >>>>> in a >>>>> >>>>> >>>> more >>>> >>>> >>>>> formal way the procedure a BGP speaker should follow to re-construct >>>>> an accurate AS_PATH from the AS4_PATH and AS_PATH attributes? Based >>>>> on this description I can see more than one way to implement this. I >>>>> would like to do so correctly, but I need to know what is correct >>>>> first. >>>>> >>>>> Thanks >>>>> Ben >>>>> >>>>> >>>>> >>>> [SC>] >>>> I agree with you completely this handwaving portion in rfc 4893 is >>>> very problematic to the implementers who were not directly involved >>>> in the making of RFC 4893. I was not one of them. In 2008, I wrote a >>>> draft pointing out some of the problems we faced during >>>> implementation and to request an update of the RFC for future >>>> interoperability. Also presented the draft at WG in Spring 2008 IETF. >>>> Rfc4893-bis has considered some of the problems mentioned in the >>>> draft + others discussed in the working group alias. >>>> http://wattle.apnic.net/ietf/idref/draft-chakrabarti-idr-rfc4893-mod/ >>>> >>>> The following interpretation has been made in our implementation >>>> after talking with some other implementers. >>>> I believe rfc4893-bis now has the similar text: >>>> 1. If the number of ASNs in AS_PATH is less than the number of >>>> ASNs in >>>> AS4_PATH, then NBGP ignores AS4_PATH information. >>>> Example: >>>> AS_PATH: 2 23456 >>>> AS4_PATH: 70000 70001 70002 >>>> >>>> >>> RFC 4893 has the following text in Sect. 4.2.3: >>> >>> If the number of AS numbers in the AS_PATH attribute is less than the >>> number of AS numbers in the AS4_PATH attribute, then the AS4_PATH >>> attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken >>> as the AS path information. >>> >>> -------------------------------------------- >>> >>> I am wondering why this portion needed "interpretation" in your >>> implementation. >>> >>> >>> >>>> 2. If the number of ASNs in AS_PATH attribute is greater than >>>> number of >>>> >>>> ASNs in AS4_PATH attribute, then there must be a few >>>> AS_TRANS numbers in AS_PATH. Reconstruct AS_PATH based on >>>> the AS4_PATH items corresponding to AS_TRANS numbers >>>> Examples: >>>> AS_PATH: 2,3,6, 8, 23456, 10, 23, 23456 >>>> AS4_PATH: 65356, 77777 >>>> >>>> >>> So what exactly is the problem with following RFC 4893 in this case? >>> The (AS_PATH, AS4_PATH) is >>> not really consistent here -- that is, 65356 is not represented in >>> AS_PATH, and there is an extra 23456 in the middle. Most likely this >>> is a crafted, lab scenario in which there is no single "correct" >>> answer. >>> >>> >>>> 3. If the number of ASNs in AS_PATH and AS4_PATH attributes is same >>>> then it most likely means that all the AS numbers are AS4-byte >>>> unmappable numbers. Check the count of AS_TRANS numbers in AS_PATH >>>> and count of AS numbers in AS4_PATH. If they are the same then >>>> reconstruct AS information from AS4_PATH only (note this case is for >>>> AS num == AS4 num). If number of AS_TRANS in AS_PATH is less than the >>>> number in AS4_PATH values, then there is something wrong done by >>>> previous speakers. However, take the non-AS_TRANS AS values from >>>> AS_PATH and then prepend them with the AS4 values. Some examples >>>> will clarify this case: >>>> AS_PATH: 23456, 23456, 23456 >>>> AS4_PATH: 777777, 66666, 88888 >>>> >>>> >>> So the merged as-path would consist of the valid AS numbers 777777, >>> 66666, 88888 based on RFC 4893. >>> This seems fine. Isn't it? >>> >>> >>>> Or >>>> AS_PATH: 2, 3, 4, 23456 >>>> AS4_PATH: 88888, 99999, 70000, 80000 >>>> >>>> >>> This again is another inconsistent, artificially crafted scenario. >>> Possibly there are more than one "correct" >>> solutions, some more "correct" than others - depending on how the >>> inconsistency was generated. As the as-path length must be maintained >>> during the merge, no solution can possibly include all the valid AS >>> numbers contained in AS_PATH / AS4_PATH. >>> >>> RFC 4893 would yield 88888, 99999, 70000, 80000 as the merged one. >>> Why wouldn't it be good enough? >>> >>> Thanks. -- Enke >>> >>> >>> > > > > From john@jlc.net Sat Oct 10 04:51:17 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F419F3A6866 for ; Sat, 10 Oct 2009 04:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HosDmoehecA for ; Sat, 10 Oct 2009 04:51:16 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 3FE093A683D for ; Sat, 10 Oct 2009 04:51:16 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9027E33C6C; Sat, 10 Oct 2009 07:52:52 -0400 (EDT) Date: Sat, 10 Oct 2009 07:52:52 -0400 From: John Leslie To: Enke Chen Message-ID: <20091010115252.GM89616@verdi> References: <4ACF6B32.7030209@trendmicro.com> <00d801ca490b$65507500$2ff15f00$@com> <4ACF87C7.1090404@cisco.com> <4ACF8AA8.1050704@cisco.com> <00ea01ca4916$c3a09670$4ae1c350$@com> <4ACFE24F.1080100@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ACFE24F.1080100@cisco.com> User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 11:51:17 -0000 Enke Chen wrote: > > If we agree that the merge algorithm described in the document is > applicable for these examples (mostly with crafted, inconsistent > data), then I am not sure if there is still value in including them > in rfc4893bis. I see great value in including such examples in a Security Considerations section pointing out that such things could be observed due to "buggy" coding or less-than-trustworthy policy application, and that some implementors have attempted to mitigate the damage caused by such cases. -- John Leslie From ben_april@trendmicro.com Mon Oct 12 09:00:24 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0245228C227 for ; Mon, 12 Oct 2009 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-+ELZAatgQ3 for ; Mon, 12 Oct 2009 09:00:23 -0700 (PDT) Received: from SJDCISCAN04.udc.trendmicro.com (sjdciscan04.udc.trendmicro.com [216.99.131.153]) by core3.amsl.com (Postfix) with ESMTP id EE6043A63C9 for ; Mon, 12 Oct 2009 09:00:22 -0700 (PDT) Received: from SJDCISCAN04.udc.trendmicro.com (SJDCISCAN04 [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BA1A99A89F6; Mon, 12 Oct 2009 09:00:21 -0700 (PDT) Received: from sjdcexbh02.us.trendnet.org (sjdcexbh02.udc.trendmicro.com [216.99.131.187]) by SJDCISCAN04.udc.trendmicro.com (Postfix) with ESMTP id AF5F09A88CB; Mon, 12 Oct 2009 09:00:21 -0700 (PDT) Received: from SJDCEXMAIL01.us.trendnet.org ([10.30.240.41]) by sjdcexbh02.us.trendnet.org with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 09:00:23 -0700 Received: from ben-aprils-macbook-pro.local ([10.31.182.71]) by SJDCEXMAIL01.us.trendnet.org with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 09:00:22 -0700 Message-ID: <4AD35294.1040703@trendmicro.com> Date: Mon, 12 Oct 2009 12:00:20 -0400 From: Benjamin April Organization: TrendMicro - ATR User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Enke Chen References: <4ACF6B32.7030209@trendmicro.com> <4ACF6EF5.10405@cisco.com> In-Reply-To: <4ACF6EF5.10405@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2009 16:00:22.0801 (UTC) FILETIME=[1AD5E810:01CA4B55] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ben_april@trendmicro.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 16:00:24 -0000 Enke, Thanks for the quick reply. Enke Chen wrote: > Ben, > > 1) RFC 4893 has been revised by the following document: > > http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt As a member of the general public and not being connected to idr how am I supposed to know about this document? The first 3 pages of google results for "RFC4893" or "RFC 4893" say nothing about bis-01, also searching at IETF this link is likewise absent. > 2) Sect. 4.2.3 presents a complete, and precise algorithm for > constructing the as-path: > > ---------------------------------- > > A NEW BGP speaker should also be prepared to receive the > AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an > OLD BGP speaker. When both the attributes are received, if the AS > number in the AGGREGATOR attribute is not AS_TRANS, then: > > - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL > be ignored, > > - the AGGREGATOR attribute SHALL be taken as the information > about the aggregating node, and > > - the AS_PATH attribute SHALL be taken as the AS path > information. > > Otherwise, > > - the AGGREGATOR attribute SHALL be ignored, > > - the AS4_AGGREGATOR attribute SHALL be taken as the information > about the aggregating node, and > > - the AS path information would need to be constructed, as in all > other cases. Am I mistaken or does this fail to address the case where a non-NEW speaker aggregates routes advertised to it by a new speaker? In such a case you would not have an AS4_AGGREGATOR but you would have an AS4_PATH attribute. By using the AS4_AGGREGATOR as the decision trigger the AS4_AGGREGATOR and thus AS4_PATH gets ignored. > In order to construct the AS path information, it would be necessary > to first calculate the number of AS numbers in the AS_PATH and > AS4_PATH attributes using the method specified in Section 9.1.2.2 > [RFC4271] and [RFC5065] for route selection. > > If the number of AS numbers in the AS_PATH attribute is less than the > number of AS numbers in the AS4_PATH attribute, then the AS4_PATH > attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken > as the AS path information. Is there an expected causes for this case? Just dropping all of that nice AS4_PATH goodness on the floor seems to me a rather careless action. One would hope that such a structured protocol would complain about such oddities unless they originated from a known mostly-harmless source. > If the number of AS numbers in the AS_PATH attribute is larger than > or equal to the number of AS numbers in the AS4_PATH attribute, then > the AS path information SHALL be constructed by taking as many AS > numbers and path segments as necessary from the leading part of the > AS_PATH attribute, and then prepending them to the AS4_PATH attribute > so that the AS path information has an identical number of AS numbers > as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or > AS_CONFED_SET path segment SHALL be prepended if it is either the > leading path segment or adjacent to a path segment that is prepended. Sorry for the delayed reply. Busy weekend. Thanks Ben TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From enkechen@cisco.com Mon Oct 12 18:48:29 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5ECF3A6783 for ; Mon, 12 Oct 2009 18:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y74t6BkRED3H for ; Mon, 12 Oct 2009 18:48:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9830E3A69FC for ; Mon, 12 Oct 2009 18:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5019; q=dns/txt; s=sjiport01001; t=1255398509; x=1256608109; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Enke=20Chen=20|Subject:=20Re :=20[Idr]=20Question=20about=20RFC4893|Date:=20Mon,=2012 =20Oct=202009=2018:48:28=20-0700|Message-ID:=20<4AD3DC6C. 8080801@cisco.com>|To:=20ben_april@trendmicro.com|CC:=20i dr@ietf.org,=20"Enke=20Chen=20(enkechen)"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 7bit|In-Reply-To:=20<4AD35294.1040703@trendmicro.com> |References:=20<4ACF6B32.7030209@trendmicro.com>=20<4ACF6 EF5.10405@cisco.com>=20<4AD35294.1040703@trendmicro.com>; bh=0VvDmZOHgGbnY6ID/hHuw/Ih6WHYohEVlzbu7+q1TCs=; b=oN/ckXiYkPJ77Mwi2KCIdVrB4a9CmXzeHwRXz6zPyWd3/mOeoeX7otlN 3f5bsqHVWn9dQBUEh+3hgIa77f6MJ1pWJNcJldZTvq0tG6XY8rpqXc/2k O5EdCnEJl3cBtFrYFlcocFp62SVA/rUvq+FK4tDzxNLFEYcEM+/lfiyBj w=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKd500qrR7Hu/2dsb2JhbAC/TpdGhC0E X-IronPort-AV: E=Sophos;i="4.44,548,1249257600"; d="scan'208";a="254927877" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 01:48:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9D1mTVT017639; Tue, 13 Oct 2009 01:48:29 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.3959); Mon, 12 Oct 2009 18:48:29 -0700 Received: from [171.71.139.253] ([171.71.139.253]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 18:48:28 -0700 Message-ID: <4AD3DC6C.8080801@cisco.com> Date: Mon, 12 Oct 2009 18:48:28 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: ben_april@trendmicro.com References: <4ACF6B32.7030209@trendmicro.com> <4ACF6EF5.10405@cisco.com> <4AD35294.1040703@trendmicro.com> In-Reply-To: <4AD35294.1040703@trendmicro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2009 01:48:28.0875 (UTC) FILETIME=[42F981B0:01CA4BA7] Cc: idr@ietf.org Subject: Re: [Idr] Question about RFC4893 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 01:48:29 -0000 Ben, Benjamin April wrote: > Enke, > Thanks for the quick reply. > > Enke Chen wrote: > >> Ben, >> >> 1) RFC 4893 has been revised by the following document: >> >> http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt >> > > As a member of the general public and not being connected to idr how > am I supposed to know about this document? The first 3 pages of > google results for "RFC4893" or "RFC 4893" say nothing about bis-01, > also searching at IETF this link is likewise absent. > I would think that the introductory books on BGP should have pointers to IETF / ROUTING / IDR. > >> 2) Sect. 4.2.3 presents a complete, and precise algorithm for >> constructing the as-path: >> >> ---------------------------------- >> >> A NEW BGP speaker should also be prepared to receive the >> AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an >> OLD BGP speaker. When both the attributes are received, if the AS >> number in the AGGREGATOR attribute is not AS_TRANS, then: >> >> - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL >> be ignored, >> >> - the AGGREGATOR attribute SHALL be taken as the information >> about the aggregating node, and >> >> - the AS_PATH attribute SHALL be taken as the AS path >> information. >> >> Otherwise, >> >> - the AGGREGATOR attribute SHALL be ignored, >> >> - the AS4_AGGREGATOR attribute SHALL be taken as the information >> about the aggregating node, and >> >> - the AS path information would need to be constructed, as in all >> other cases. >> > > Am I mistaken or does this fail to address the case where a non-NEW > speaker aggregates routes advertised to it by a new speaker? In such > a case you would not have an AS4_AGGREGATOR but you would have an > AS4_PATH attribute. By using the AS4_AGGREGATOR as the decision > trigger the AS4_AGGREGATOR and thus AS4_PATH gets ignored. > In that case the AS4_PATH attribute would appear as an unrecognized, optional, transitive attribute to the aggregator (an OLD speaker). Certainly I am not aware of any implementation that would preserve such an attribute during aggregation. (Even if it were preserved, the AS_PATH and AS4_PATH would most likely inconsistent, and why bother with doing anything different?) BTW, irrespective of 4byte AS, it is pretty common for the as-path info to be truncated during aggregation. > >> In order to construct the AS path information, it would be necessary >> to first calculate the number of AS numbers in the AS_PATH and >> AS4_PATH attributes using the method specified in Section 9.1.2.2 >> [RFC4271] and [RFC5065] for route selection. >> >> If the number of AS numbers in the AS_PATH attribute is less than the >> number of AS numbers in the AS4_PATH attribute, then the AS4_PATH >> attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken >> as the AS path information. >> > > Is there an expected causes for this case? Just dropping all of that > nice AS4_PATH goodness on the floor seems to me a rather careless > action. One would hope that such a structured protocol would > complain about such oddities unless they originated from a known > mostly-harmless source. > It is not a realistic scenario. That paragraph in the spec is mainly for the sake of completeness. Sure, one could craft it in the lab. When AS_PATH and AS4_PATH are inconsistent, it is subject to debate whether we should favor the latest info (AS_PATH), or the oldest info (AS4_PATH). We have to specify one. Some of the discussions occurred several years ago on IDR. You might be able to dig them up in the IDR archives. Regards, -- Enke > >> If the number of AS numbers in the AS_PATH attribute is larger than >> or equal to the number of AS numbers in the AS4_PATH attribute, then >> the AS path information SHALL be constructed by taking as many AS >> numbers and path segments as necessary from the leading part of the >> AS_PATH attribute, and then prepending them to the AS4_PATH attribute >> so that the AS path information has an identical number of AS numbers >> as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or >> AS_CONFED_SET path segment SHALL be prepended if it is either the >> leading path segment or adjacent to a path segment that is prepended. >> > > Sorry for the delayed reply. Busy weekend. > > Thanks > Ben > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. > From jgs@juniper.net Thu Oct 15 12:00:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514643A6949 for ; Thu, 15 Oct 2009 12:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJTkUqbkulnc for ; Thu, 15 Oct 2009 12:00:52 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id C1E6E3A6947 for ; Thu, 15 Oct 2009 12:00:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKStdxX5/P8skK+zeE4EyRhCf8Ps3X/INV@postini.com; Thu, 15 Oct 2009 12:00:48 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 15 Oct 2009 11:53:58 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:53:58 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:53:57 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:53:57 -0700 Received: from [172.16.13.206] ([172.16.13.206]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9FIrvj60603 for ; Thu, 15 Oct 2009 11:53:57 -0700 (PDT) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 15 Oct 2009 14:53:56 -0400 Message-ID: <561949C3-A190-4283-8B59-6E8F24D011A2@juniper.net> To: idr List MIME-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-OriginalArrivalTime: 15 Oct 2009 18:53:57.0720 (UTC) FILETIME=[D9D9AD80:01CA4DC8] Subject: [Idr] IETF 76 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 19:00:53 -0000 Folks, We're planning to meet at IETF-76. Please forward any IDR agenda items you might have to Sue and myself. The deadline is October 27, 2009 by 13:00 U.S. Eastern Time. If you plan to make a presentation, please keep in mind the IDR tradition, "no Internet Draft - no time slot". --John & Sue From root@core3.amsl.com Sat Oct 17 06:00:02 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1AC053A6977; Sat, 17 Oct 2009 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091017130002.1AC053A6977@core3.amsl.com> Date: Sat, 17 Oct 2009 06:00:02 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-advisory-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 13:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Advisory Message Author(s) : T. Scholl, et al. Filename : draft-ietf-idr-advisory-00.txt Pages : 7 Date : 2009-10-16 The BGP routing protocol is used with external as well as internal neighbors to propagate route advertisements. In the case of external BGP sessions, there is typically a demarcation of administrative responsibility between the two entities. Provisioning, maintenance and administrative actions are communicated via off-line methods such as email or telephone calls. While these methods have been used for many years, it can be troublesome for an operator to correlate a BGP- related event in the network with a notice that was transmitted in email. This document proposes a new BGP message type, the Advisory message, which can be used to convey advisory information to a BGP speaker's peer. A capability is used to ensure that the recipient of the Advisory message is capable of supporting it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-advisory-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-advisory-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-17054910.I-D@ietf.org> --NextPart-- From pierre.francois@uclouvain.be Mon Oct 19 02:10:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E91228C0FC; Mon, 19 Oct 2009 02:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2datT2Xb046G; Mon, 19 Oct 2009 02:10:41 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 44D063A68F1; Mon, 19 Oct 2009 02:10:41 -0700 (PDT) Received: from nukuhiva.dhcp.info.ucl.ac.be (nukuhiva.dhcp.info.ucl.ac.be [130.104.228.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pifrancois@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id BE363E8D93; Mon, 19 Oct 2009 11:10:33 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp1.sgsi.ucl.ac.be BE363E8D93 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1255943433; bh=JHp2ksdl1IR/w7i8cFmlsM1MemQms/2yfu6xYWqxXoQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: Content-Type; b=tVAH2jIWsLOHGUkLBfPNDM6xwMXy3dr85ChicPiALRE962ffG59+joV8esZrr5N1K 0+JP2Q6czW1PDfpkA6IHEzV2G3HhBG74fb8abBZoFTJt7hLt7SPn7q7VkMjyMBBHH3 aKDtSI/BiOAbubUzpV27SVb+AgfIYmqONilRZpXg= Message-ID: <4ADC2D05.7010005@uclouvain.be> Date: Mon, 19 Oct 2009 11:10:29 +0200 From: Pierre Francois User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: idr , grow@ietf.org Content-Type: multipart/mixed; boundary="------------000604010004070007020802" X-Virus-Scanned: clamav-milter 0.95.2 at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: BE363E8D93.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: pierre.francois@uclouvain.be X-SGSI-Spam-Status: No Cc: DECRAENE Bruno RD-CORE-ISS Subject: [Idr] [Fwd: I-D Action:draft-decraene-idr-rfc4360-clarification-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pierre.francois@uclouvain.be List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 09:10:42 -0000 This is a multi-part message in MIME format. --------------000604010004070007020802 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, For your information, a draft describing a request for clarification on RFC 4360, regarding the handling of non-transitive extended communities, has been submitted. Please read and comment ! Regards, Pierre. -------- Original Message -------- Subject: I-D Action:draft-decraene-idr-rfc4360-clarification-00.txt Date: Mon, 19 Oct 2009 02:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RFC 4360 Clarification Request Author(s) : B. Decraene, et al. Filename : draft-decraene-idr-rfc4360-clarification-00.txt Pages : 5 Date : 2009-10-19 This draft describes a request for clarification of the Operations Section of [RFC4360], regarding the handling of non transitive extended communities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-decraene-idr-rfc4360-clarification-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------000604010004070007020802 Content-Type: Message/External-body; name="draft-decraene-idr-rfc4360-clarification-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-decraene-idr-rfc4360-clarification-00.txt" Content-Type: text/plain Content-ID: <2009-10-19015030.I-D@ietf.org> --------------000604010004070007020802 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000604010004070007020802-- From web-usrn@ISI.EDU Mon Oct 19 05:45:58 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4F528C1AF for ; Mon, 19 Oct 2009 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.09 X-Spam-Level: X-Spam-Status: No, score=-17.09 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRasuVNfiW99 for ; Mon, 19 Oct 2009 05:45:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 3EBAF28C192 for ; Mon, 19 Oct 2009 05:45:55 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9JCjSpN012721; Mon, 19 Oct 2009 05:45:28 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n9JCjRMw012716; Mon, 19 Oct 2009 05:45:27 -0700 (PDT) Date: Mon, 19 Oct 2009 05:45:27 -0700 (PDT) Message-Id: <200910191245.n9JCjRMw012716@boreas.isi.edu> To: rsrihari@cisco.com, tappan@cisco.com, yakov@juniper.net, rcallon@juniper.net, adrian.farrel@huawei.com, shares@ndzh.com, jgs@juniper.net From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 08:28:22 -0700 Cc: yakov@juniper.net, rfc-editor@rfc-editor.org, idr@ietf.org Subject: [Idr] [Editorial Errata Reported] RFC4360 (1917) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 12:45:58 -0000 The following errata report has been submitted for RFC4360, "BGP Extended Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4360&eid=1917 -------------------------------------- Type: Editorial Reported by: Yakov Rekhter Section: 6 Original Text ------------- If a route has a non-transitivity extended community, Corrected Text -------------- If a route has a non-transitive extended community, Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4360 (draft-ietf-idr-bgp-ext-communities-09) -------------------------------------- Title : BGP Extended Communities Attribute Publication Date : February 2006 Author(s) : S. Sangli, D. Tappan, Y. Rekhter Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From tony.li@tony.li Mon Oct 19 20:16:50 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA883A6765 for ; Mon, 19 Oct 2009 20:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9t6SQjoGcwt for ; Mon, 19 Oct 2009 20:16:49 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 2F1163A63C9 for ; Mon, 19 Oct 2009 20:16:49 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id uqYV1c00B0vp7WLAErGxud; Tue, 20 Oct 2009 03:16:57 +0000 Received: from [192.168.0.110] ([24.6.155.154]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id urGw1c0053L8a8Q8RrGwpN; Tue, 20 Oct 2009 03:16:57 +0000 Message-ID: <4ADD2BA6.8070103@tony.li> Date: Mon, 19 Oct 2009 20:16:54 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: RFC Errata System References: <200910191245.n9JCjRMw012716@boreas.isi.edu> In-Reply-To: <200910191245.n9JCjRMw012716@boreas.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, tappan@cisco.com, yakov@juniper.net, adrian.farrel@huawei.com, shares@ndzh.com Subject: Re: [Idr] [Editorial Errata Reported] RFC4360 (1917) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 03:16:50 -0000 Concur. Tony RFC Errata System wrote: > The following errata report has been submitted for RFC4360, > "BGP Extended Communities Attribute". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4360&eid=1917 > > -------------------------------------- > Type: Editorial > Reported by: Yakov Rekhter > > Section: 6 > > Original Text > ------------- > If a route has a non-transitivity extended community, > > Corrected Text > -------------- > If a route has a non-transitive extended community, > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4360 (draft-ietf-idr-bgp-ext-communities-09) > -------------------------------------- > Title : BGP Extended Communities Attribute > Publication Date : February 2006 > Author(s) : S. Sangli, D. Tappan, Y. Rekhter > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From Ilya.Varlashkin@de.easynet.net Tue Oct 20 00:26:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0B93A68DD for ; Tue, 20 Oct 2009 00:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7ccg4jfCkCc for ; Tue, 20 Oct 2009 00:26:14 -0700 (PDT) Received: from softy.de.easynet.net (softy.de.easynet.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 8DFCB3A68AB for ; Tue, 20 Oct 2009 00:26:14 -0700 (PDT) Received: from fe01kgham.de.easynet.net ([194.163.250.17] helo=fe01kgham.adoffice.local.de.easynet.net) by softy.de.easynet.net with esmtp (Exim 4.63) (envelope-from ) id 1N096q-0007Kh-Hq for idr@ietf.org; Tue, 20 Oct 2009 09:26:20 +0200 Received: from ex01kgham.adoffice.local.de.easynet.net ([10.43.3.3]) by fe01kgham.adoffice.local.de.easynet.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 09:26:20 +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, 20 Oct 2009 09:26:20 +0200 Message-ID: In-Reply-To: <20091017130002.1AC053A6977@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] I-D Action:draft-ietf-idr-advisory-00.txt Thread-Index: AcpPKev39x80cD89SM21HNz7HQIWEgCKfzcQ References: <20091017130002.1AC053A6977@core3.amsl.com> From: "Ilya Varlashkin" To: X-OriginalArrivalTime: 20 Oct 2009 07:26:20.0376 (UTC) FILETIME=[9E9F5580:01CA5156] Subject: Re: [Idr] I-D Action:draft-ietf-idr-advisory-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 07:26:15 -0000 Hello, > This document proposes a new BGP message type, the Advisory=20 > message, which can be used to convey advisory information to=20 > a BGP speaker's peer. A capability is used to ensure that=20 The document proposes two sub-types (1&2) which appear to be very similar in format but somewhat different in expected reaction of the router. Is there sufficient need to separate on protocol level such messages? From operator prospective I see value in making any message visible among other neighbor-related information (in some sort of 'show' command output) and any message may generate notification to caretaker (e.g. via syslog or snmp trap). Could both sub-types be combined into one and left upto operator to decide whether to log/trap them or not? As for "standard set of advisory messages", it's probably good idea to document them in a separate draft/rfc rather than leaving it up to implementations to come up each with their own set of "standard messages". The list could be settled by asking network operators to submit their proposals, then have vendors say what's feasible or not. Such list should not be too long, but should cover most typical scenarios where advisory messages would be helpful. Cheers, iLya From dongjie_dj@huawei.com Tue Oct 20 02:25:21 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0583A6A0E for ; Tue, 20 Oct 2009 02:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxVOlQYvnaY2 for ; Tue, 20 Oct 2009 02:25:20 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 504953A6A1C for ; Tue, 20 Oct 2009 02:25:13 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRT003LE3G08C@szxga03-in.huawei.com> for idr@ietf.org; Tue, 20 Oct 2009 17:24:00 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRT00MHC3G0IG@szxga03-in.huawei.com> for idr@ietf.org; Tue, 20 Oct 2009 17:24:00 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRT00DB83FZQD@szxml04-in.huawei.com> for idr@ietf.org; Tue, 20 Oct 2009 17:24:00 +0800 (CST) Date: Tue, 20 Oct 2009 17:23:59 +0800 From: Jie Dong To: idr@ietf.org Message-id: <006901ca5167$0e71f0b0$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpRZw2z+G+vEqgrTQK8cBcOM5+jDg== Subject: [Idr] New Draft Notification: draft-dong-idr-vpn-route-constrain-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:25:21 -0000 Dear all, I have just submitted a new draft draft-dong-idr-vpn-route-constrain-00 to the IDR WG. The abstract is as follows: This document defines generalized procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to precisely control the propagation of different kinds of Virtual Private Network (VPN) routing information. This method avoids unnecessary advertising of VPN routes when more than one kind of VPN is deployed in the network. For more details, please see: http://tools.ietf.org/id/draft-dong-idr-vpn-route-constrain-00.txt Comment are always welcomed. Best regards, Jie From jgs@juniper.net Mon Oct 26 13:23:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3029C3A67AA for ; Mon, 26 Oct 2009 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FoN7tAbf++c for ; Mon, 26 Oct 2009 13:23:18 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id A023528C1E6 for ; Mon, 26 Oct 2009 13:23:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSuYFQ4n/304RjMgQl0s6Rc8iGPmdl1SJ@postini.com; Mon, 26 Oct 2009 13:23:32 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 26 Oct 2009 13:19:15 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:19:15 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:19:14 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:19:14 -0700 Received: from [172.16.13.206] ([172.16.13.206]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9QKJEj16205 for ; Mon, 26 Oct 2009 13:19:14 -0700 (PDT) (envelope-from jgs@juniper.net) Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes MIME-Version: 1.0 (Apple Message framework v1076) From: "John G. Scudder" In-Reply-To: <561949C3-A190-4283-8B59-6E8F24D011A2@juniper.net> Date: Mon, 26 Oct 2009 16:19:13 -0400 Content-Transfer-Encoding: 7bit Message-ID: <2132952C-4E4B-4DDC-AFDE-1CE6B73FC484@juniper.net> References: <561949C3-A190-4283-8B59-6E8F24D011A2@juniper.net> To: idr List X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 26 Oct 2009 20:19:14.0712 (UTC) FILETIME=[965BF180:01CA5679] Subject: Re: [Idr] IETF 76 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:23:20 -0000 Reminder: If you would like to present at the upcoming IETF, please send your request within the next 21 hours. --John & Sue On Oct 15, 2009, at 2:53 PM, John Scudder wrote: > Folks, > > We're planning to meet at IETF-76. Please forward any IDR agenda > items you might have to Sue and myself. The deadline is October 27, > 2009 by 13:00 U.S. Eastern Time. > > If you plan to make a presentation, please keep in mind the IDR > tradition, "no Internet Draft - no time slot". > > --John & Sue From root@core3.amsl.com Mon Oct 26 14:45:02 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0D1B83A684C; Mon, 26 Oct 2009 14:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026214502.0D1B83A684C@core3.amsl.com> Date: Mon, 26 Oct 2009 14:45:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Generic Subtype for BGP Four-octet AS specific extended community Author(s) : D. Rao, et al. Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt Pages : 6 Date : 2009-10-26 Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26144147.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 16:45:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CE5A728C1B5; Mon, 26 Oct 2009 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026234501.CE5A728C1B5@core3.amsl.com> Date: Mon, 26 Oct 2009 16:45:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-optional-transitive-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 23:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Error Handling for Optional Transitive BGP Attributes Author(s) : J. Scudder, E. Chen Filename : draft-ietf-idr-optional-transitive-01.txt Pages : 8 Date : 2009-10-26 According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. It also revises the error handling procedures for several existing optional transitive attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-optional-transitive-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26164341.I-D@ietf.org> --NextPart-- From rjs@eng.gxn.net Tue Oct 27 12:36:52 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D89E28C13F for ; Tue, 27 Oct 2009 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e08L7felgyK4 for ; Tue, 27 Oct 2009 12:36:51 -0700 (PDT) Received: from mocha.rob.sh (mocha.rob.sh [193.239.32.250]) by core3.amsl.com (Postfix) with ESMTP id C002028C112 for ; Tue, 27 Oct 2009 12:36:50 -0700 (PDT) Received: from [193.47.147.84] (helo=84.kerrison.flarg.net) by mocha.rob.sh with esmtpa (Exim 4.66) (envelope-from ) id KS6UHS-000C9X-54; Tue, 27 Oct 2009 19:37:04 +0000 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rob Shakir In-Reply-To: Date: Tue, 27 Oct 2009 19:37:03 +0000 Content-Transfer-Encoding: 7bit Message-Id: <5188CE5E-7EE8-44CC-BD62-75E59C6DE024@eng.gxn.net> References: <20091017130002.1AC053A6977@core3.amsl.com> To: idr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [Idr] I-D Action:draft-ietf-idr-advisory-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 19:36:52 -0000 Hi, On 20 Oct 2009, at 08:26, Ilya Varlashkin wrote: > The document proposes two sub-types (1&2) which appear to be very > similar in format but somewhat different in expected reaction of the > router. Is there sufficient need to separate on protocol level such > messages? From operator prospective I see value in making any message > visible among other neighbor-related information (in some sort of > 'show' > command output) and any message may generate notification to caretaker > (e.g. via syslog or snmp trap). Could both sub-types be combined into > one and left upto operator to decide whether to log/trap them or not? I am unsure as to whether I agree with this point - the types that are defined seem to set a precedent that for each type that is defined under ADVISORY, there is a requirement to define two types - one of which is 'static' and the other is limited in lifetime. There is definitely operational value in my eyes of being able to have a message that can be seen for a neighbour in a 'show ip bgp neigh x.y.z.a' type output, but as to whether this should be defined in the standard I am undecided. Can the authors shed any light on the differentiation of these two messages, and why this detail should be defined in the standard, or require separate types, rather than some 'lifetime' flag that can be passed with the message? (I'm not sure I'd advocate this, but I am interested in why the current draft is as written). > As for "standard set of advisory messages", it's probably good idea to > document them in a separate draft/rfc rather than leaving it up to > implementations to come up each with their own set of "standard > messages". The list could be settled by asking network operators to > submit their proposals, then have vendors say what's feasible or not. > Such list should not be too long, but should cover most typical > scenarios where advisory messages would be helpful. I agree here -- it'd be good to have a separate draft that defined some common ADVISORY types that can be handled by an NMS system. This continues to look like a really useful draft, thanks for the work thus far on it! Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html