From idr-bounces@ietf.org Thu Feb 01 07:02:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCabY-0003J5-AV; Thu, 01 Feb 2007 06:59:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCabW-0003IF-RE for idr@ietf.org; Thu, 01 Feb 2007 06:59:50 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCabE-0007wf-CK for idr@ietf.org; Thu, 01 Feb 2007 06:59:50 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP for idr@ietf.org; Thu, 1 Feb 2007 12:59:28 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 12:59:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Feb 2007 12:54:38 +0100 Message-Id: <344CD127E0EB6342B2928D8988E021030122A62D@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Multiple Next-Hops Drafts thread-index: AcdF98AgNJgdfkdmSlmsvxmMS3P3cA== From: "Bamberg, Dan" To: X-OriginalArrivalTime: 01 Feb 2007 11:59:28.0083 (UTC) FILETIME=[6CACFA30:01C745F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Idr] Status of Multiple Next-Hops Drafts X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hello, After following the discussion about a multiple next-hop extension to BGP in August/September last year (draft-bhatia-bgp-multiple-next-hops <--> draft-walton-bgp-add-paths), I haven't seen any new on mailing list for a long time. Are there any activities on these drafts at the moment or new versions planed to publish in near future? Especially addressed to the guys from Cisco: How about an implementation of the add-paths draft in IOS, are there any plans? Regards. Dan Bamberg _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 02 15:54:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5ML-0002Xj-0e; Fri, 02 Feb 2007 15:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5MC-0002Vg-5y; Fri, 02 Feb 2007 15:50:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD5MB-00029n-Te; Fri, 02 Feb 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 69C9B26ECF; Fri, 2 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HD5MA-0002NL-4w; Fri, 02 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc3065bis-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --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 : Autonomous System Confederations for BGP Author(s) : P. Traina, et al. Filename : draft-ietf-idr-rfc3065bis-06.txt Pages : 17 Date : 2007-2-2 The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc3065bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-2135443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc3065bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc3065bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-2135443.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Fri Feb 02 17:46:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD77R-0007HI-8t; Fri, 02 Feb 2007 17:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD77P-0007Fk-Qk for idr@ietf.org; Fri, 02 Feb 2007 17:42:55 -0500 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD75H-0004G8-I8 for idr@ietf.org; Fri, 02 Feb 2007 17:40:44 -0500 Received: from rover.local (unknown [10.0.6.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 79BB4142C2 for ; Fri, 2 Feb 2007 17:40:11 -0500 (EST) Received: from [127.0.0.1] by rover.local (PGP Universal service); Fri, 02 Feb 2007 15:40:33 -0700 X-PGP-Universal: processed; by rover.local on Fri, 02 Feb 2007 15:40:33 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Message-Id: <5C6FC240-CE90-4D9C-B141-F4F1CA6C93B4@tcb.net> From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-rfc3065bis-06.txt Date: Fri, 2 Feb 2007 15:40:23 -0700 To: Inter-Domain List Routing X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, This update is meant to address comments from IDR and GEN-ART review feedback and all outstanding issues should be accommodated. A diff from -05 is available here: http://tools.ietf.org/wg/idr/draft-ietf-idr-rfc3065bis/draft-ietf-idr- rfc3065bis-06-from-05.diff.html Thanks to the GEN-ART team for their usual thorough review, and to the folks here for additional feedback. -danny On Feb 2, 2007, at 1:50 PM, Internet-Drafts@ietf.org wrote: > 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 : Autonomous System Confederations for BGP > Author(s) : P. Traina, et al. > Filename : draft-ietf-idr-rfc3065bis-06.txt > Pages : 17 > Date : 2007-2-2 > > The Border Gateway Protocol (BGP) is an inter-autonomous system > routing protocol designed for Transmission Control Protocol/ > Internet > Protocol (TCP/IP) networks. BGP requires that all BGP speakers > within a single autonomous system (AS) must be fully meshed. This > represents a serious scaling problem that has been well > documented in > a number of proposals. > > This document describes an extension to BGP which may be used to > create a confederation of autonomous systems that is represented > as a > single autonomous system to BGP peers external to the > confederation, > thereby removing the "full mesh" requirement. The intention of > this > extension is to aid in policy administration and reduce the > management complexity of maintaining a large autonomous system. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-idr-rfc3065bis-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idr-rfc3065bis-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-2-2135443.I-D@ietf.org> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 07 15:55:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtnU-0000Nc-H9; Wed, 07 Feb 2007 15:53:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkx-000583-Qs; Wed, 07 Feb 2007 15:51:08 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEtku-0002d1-Si; Wed, 07 Feb 2007 15:51:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 363CF2ACAC; Wed, 7 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001bb-VM; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --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-as4bytes-13.txt Pages : 10 Date : 2007-2-7 Currently the Autonomous System 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-as4bytes-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7113730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7113730.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Wed Feb 07 16:56:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEujN-0005JV-PG; Wed, 07 Feb 2007 16:53:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEujM-0005J6-8j for idr@ietf.org; Wed, 07 Feb 2007 16:53:32 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEujH-0003RC-QK for idr@ietf.org; Wed, 07 Feb 2007 16:53:32 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 07 Feb 2007 13:53:16 -0800 X-IronPort-AV: i="4.13,296,1167638400"; d="asc'?txt'208?scan'208,208"; a="762166338:sNHT2425180646" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l17LrBnf007032 for ; Wed, 7 Feb 2007 13:53:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l17LrFUw004256 for ; Wed, 7 Feb 2007 13:53:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 13:53:17 -0800 Received: from [128.107.130.57] ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Feb 2007 13:53:15 -0800 Message-ID: <45CA4A4B.4040108@cisco.com> Date: Wed, 07 Feb 2007 13:53:15 -0800 From: Enke Chen User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: idr@ietf.org Content-Type: multipart/mixed; boundary="------------060405070509010000070707" X-OriginalArrivalTime: 07 Feb 2007 21:53:15.0102 (UTC) FILETIME=[5E8327E0:01C74B02] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3632; t=1170885191; x=1171749191; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20[Fwd=3A=20I-D=20ACTION=3Adraft-ietf-idr-as4bytes-13.txt] |Sender:=20; bh=0UljDUZN4l3/pqR4sPutNG1y6SJh06dJmzBdBv7Dy0A=; b=CItZ3tpwYpRFxNHq6X9LH1b/ra3Hu0sbv1TLgEs5YeIZFKxt/TPMyXtaS64rxKiQXpVlLsLA M8nDxxH82BqvqtoFCHQPU3wttCzIKdfEZr0nv0OhHLE4IurZvQUXPMhb; Authentication-Results: sj-dkim-4; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --------------060405070509010000070707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, folks: The revised version addresses several comments from the IESG review, including: o IANA Considerations o Security Considerations o Attribute Naming Please note these changes to the attribute names (the type codes are unchanged): NEW_AS_PATH ---> AS4_PATH NEW_AGGREGATOR ---> AS4_AGGREGATOR Thanks. -- Enke -------- Original Message -------- Subject: I-D ACTION:draft-ietf-idr-as4bytes-13.txt Date: Wed, 07 Feb 2007 15:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: idr@ietf.org 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-as4bytes-13.txt Pages : 10 Date : 2007-2-7 Currently the Autonomous System 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-as4bytes-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------060405070509010000070707 Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-13.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-idr-as4bytes-13.txt" Content-Type: text/plain Content-ID: <2007-2-7113730.I-D@ietf.org> --------------060405070509010000070707 Content-Type: text/plain; name="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.asc" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------060405070509010000070707 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --------------060405070509010000070707-- From idr-bounces@ietf.org Wed Feb 07 19:30:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx8x-000181-H1; Wed, 07 Feb 2007 19:28:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx8v-00017w-Pr for idr@ietf.org; Wed, 07 Feb 2007 19:28:05 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEx8u-0001ed-CG for idr@ietf.org; Wed, 07 Feb 2007 19:28:05 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id D36F71CC1E; Wed, 7 Feb 2007 19:28:02 -0500 (EST) Date: Wed, 7 Feb 2007 19:28:02 -0500 From: John Leslie To: Enke Chen Subject: Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt] Message-ID: <20070208002802.GD2308@verdi> References: <45CA4A4B.4040108@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45CA4A4B.4040108@cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Enke Chen wrote: > > Please note these changes to the attribute names (the type codes are > unchanged): > > NEW_AS_PATH ---> AS4_PATH > NEW_AGGREGATOR ---> AS4_AGGREGATOR I attach an abbreviated diff with context for changes other than those. Note in Section 4.1 "MAY advertise" becomes "SHOULD advertise", and in Section 6 "SHOULD NOT use AS_TRANS" becomes "MUST NOT use AS_TRANS". Section 7 now includes actual assigned values, and explicitly disclaims any intent to modify allocation policies and procedures. Section 8 adds a Security Consideration, which deserves to be read carefully. -------------------------------- cut here -------------------------------- 3. Protocol Extensions attribute has the same semantics as the AGGREGATOR attribute, except < that it carries 4-octet AS numbers. --- attribute has the same semantics as the AGGREGATOR attribute, except > that it carries a 4-octet AS number. **** Currently assigned 2-octet Autonomous System numbers are converted < into 4-octet Autonomous System numbers by setting the high-order 2 octets of the 4-octet field to zero. Such a 4-octet AS number is said --- Currently assigned 2-octet Autonomous System numbers are converted > into 4-octet Autonomous System numbers by setting the two high-order octets of the 4-octet field to zero. Such a 4-octet AS number is said **** 4.1. Interaction Between NEW BGP Speakers < A BGP speaker that supports 4-octet Autonomous System numbers MAY advertise this to its peers using the BGP Capability Advertisements. --- > A BGP speaker that supports 4-octet Autonomous System numbers SHOULD advertise this to its peers using the BGP Capability Advertisements. **** 6. Transition < An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System number. --- > An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number. **** 7. IANA Considerations < This document makes the four-octet, unsigned integers larger than < 65535 available for allocation as AS numbers. These AS numbers need < to be managed by the IANA "Autonomous System Numbers" registry. --- > This document expands the pool for AS numbers from 0 - 65535 to 0 - > 4294967295. The AS numbers are managed by the IANA "Autonomous > System Numbers" registry. Other than expanding the AS number pool, > this document does not propose any modifications to the existing > policies and procedures pertaining to the AS number allocation. **** This document uses a BGP Capability code to indicate that a BGP < speaker supports the 4-octet AS numbers. The Capability code has been assigned by IANA per RFC 2842. --- This document uses a BGP Capability code to indicate that a BGP > speaker supports the 4-octet AS numbers. The Capability Code 65 has been assigned by IANA per RFC 2842. **** In addition, this document introduces two new BGP optional transitive < attributes. The first is the NEW_AS_PATH attribute, which preserves < the AS path information with 4-octet AS numbers across old BGP < speakers. The second is the NEW_AGGREGATOR attribute, which is < similar in use to the current AGGREGATOR attribute but it carries < 4-octet AS numbers. The Type Codes for these attributes have been < assigned by IANA. --- In addition, this document introduces two new BGP optional transitive > attributes, and their type codes have been assigned by the IANA. The > first one is the AS4_PATH attribute, value 17, which preserves the AS > path information with 4-octet AS numbers across old BGP speakers. The > second one is the AS4_AGGREGATOR attribute, value 18, which is > similar in use to the current AGGREGATOR attribute but it carries a > 4-octet AS number. **** Finally, this document introduces a reserved 2-octet AS number - < AS_TRANS. The AS number for AS_TRANS has been assigned by the IANA. --- Finally, this document introduces a reserved 2-octet AS number - > AS_TRANS. The AS number 23456 has been assigned by the IANA for > AS_TRANS. **** 8. Security Considerations This extension to BGP does not change the underlying security issues < inherent in the existing BGP. --- This extension to BGP does not change the underlying security issues > inherent in the existing BGP, except for the following: > > The inconsistency between the AS_PATH attribute and the AS4_PATH > attribute can create loss of the AS path information, and potential > routing loops in certain cases as discussed in the document. This > coule be exploited by an attacker. **** 9. Acknowledgments The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the numerous discussions which went into the < making of this draft. --- The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the numerous discussions which went into the > making of this document. **** 10. Normative References [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol < 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. --- [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol > 4 (BGP-4)", RFC 4271, January 2006. **** 12. Authors' Information Quaizar Vohra < Juniper Networks < 1194 N. Mathilda Ave < Sunnyvale, CA 94089 < < Email: qv@juniper.net --- Quaizar Vohra > Nuova Systems > 2600 San Tomas Expressway > Santa Clara, CA 95051 > > Email: qv@nuovasystems.com -------------------------------- cut here -------------------------------- -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 08 20:50:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKqm-0002nB-GW; Thu, 08 Feb 2007 20:46:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKqi-0002mP-Si; Thu, 08 Feb 2007 20:46:52 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFKqh-0005HJ-G6; Thu, 08 Feb 2007 20:46:52 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l191kotH010932; Thu, 8 Feb 2007 17:46:50 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l191ko80010931; Thu, 8 Feb 2007 17:46:50 -0800 Date: Thu, 8 Feb 2007 17:46:50 -0800 Message-Id: <200702090146.l191ko80010931@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 4798 on Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4798 Title: Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) Author: J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur Status: Standards Track Date: February 2007 Mailbox: jeremy.de_clercq@alcatel-lucent.be, dirk@onesparrow.com, stuart.prevost@bt.com, flefauch@cisco.com Pages: 14 Characters: 31381 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ooms-v6ops-bgp-tunnel-07.txt URL: http://www.rfc-editor.org/rfc/rfc4798.txt This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 09 10:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXCW-00053l-Dz; Fri, 09 Feb 2007 09:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXCV-00053f-Uf for idr@ietf.org; Fri, 09 Feb 2007 09:58:11 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXCS-0005mt-KS for idr@ietf.org; Fri, 09 Feb 2007 09:58:11 -0500 Received: by postman.ripe.net (Postfix, from userid 4008) id 0708B2401F; Fri, 9 Feb 2007 15:58:06 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 15C4C23F5F; Fri, 9 Feb 2007 15:58:05 +0100 (CET) Received: from x37.ripe.net (x37.ripe.net [193.0.1.37]) by herring.ripe.net (Postfix) with SMTP id 1232C2F5AD; Fri, 9 Feb 2007 15:58:04 +0100 (CET) Received: by x37.ripe.net (sSMTP sendmail emulation); Fri, 9 Feb 2007 15:58:04 +0100 From: "Erik Romijn" Date: Fri, 9 Feb 2007 15:58:04 +0100 To: John Leslie Subject: Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt] Message-ID: <20070209145803.GF13343@ripe.net> References: <45CA4A4B.4040108@cisco.com> <20070208002802.GD2308@verdi> MIME-Version: 1.0 In-Reply-To: <20070208002802.GD2308@verdi> X-PGP-Key: http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0xC1AB2068 User-Agent: Mutt/1.5.13 (2006-08-11) X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.142110 / -4.4 X-RIPE-Signature: 6ff828a60c4c962dd39b8241d829127f X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313677321==" Errors-To: idr-bounces@ietf.org --===============1313677321== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oGy11dVowAZA6eXT" Content-Disposition: inline --oGy11dVowAZA6eXT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 07, 2007 at 07:28:02PM -0500, John Leslie wrote: > Enke Chen wrote: > >=20 > > Please note these changes to the attribute names (the type codes are=20 > > unchanged): > >=20 > > NEW_AS_PATH ---> AS4_PATH > > NEW_AGGREGATOR ---> AS4_AGGREGATOR Perhaps a stupid question, but why not go for "AS4 speaker" and "AS2 speaker" too instread of "NEW/OLD speaker"? cheers, --=20 Erik Romijn RIPE NCC jr. software engineer http://www.ripe.net/ Information Services dept. --oGy11dVowAZA6eXT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFzIv7R3CMYMGrIGgRAnKXAKCqG8AWdbs8BlJa5fRtK6JAkczl4QCgm4Fi PaxLkCNlNSORAhiR7CNYvEA= =YTPy -----END PGP SIGNATURE----- --oGy11dVowAZA6eXT-- --===============1313677321== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============1313677321==-- From idr-bounces@ietf.org Fri Feb 09 21:11:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhd2-0000bI-CN; Fri, 09 Feb 2007 21:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhd1-0000bB-3T for idr@ietf.org; Fri, 09 Feb 2007 21:06:15 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFhcx-0000pB-OT for idr@ietf.org; Fri, 09 Feb 2007 21:06:15 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2007 18:06:11 -0800 X-IronPort-AV: i="4.13,308,1167638400"; d="scan'208"; a="111032482:sNHT43107093" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1A26B11004100; Fri, 9 Feb 2007 18:06:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1A25HGq001902; Fri, 9 Feb 2007 18:06:11 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 18:05:27 -0800 Received: from [128.107.130.57] ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 18:05:26 -0800 Message-ID: <45CD2866.3060403@cisco.com> Date: Fri, 09 Feb 2007 18:05:26 -0800 From: Enke Chen User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Erik Romijn Subject: Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt] References: <45CA4A4B.4040108@cisco.com> <20070208002802.GD2308@verdi> <20070209145803.GF13343@ripe.net> In-Reply-To: <20070209145803.GF13343@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2007 02:05:26.0456 (UTC) FILETIME=[EE540B80:01C74CB7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=718; t=1171073171; x=1171937171; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20[Fwd=3A=20I-D=20ACTION=3Adraft-ietf-idr-as4by tes-13.txt] |Sender:=20; bh=2hUy1pRtiagzb1DRU6o0vhzzF5fRPv3ntlvHOT/T+BY=; b=hEe3eYr22nuAeNGA6P+ngMvJ6KUJ6XtmymwSw+rYsLlOxC7kQKVikQ8Gu4HNNQJIxiWqKvL+ wW0y3VzuwePtF9vQt9RaKIWMHhjNuZaTruvNAmv7T0ud96GI6m6uX0Kt; Authentication-Results: sj-dkim-3; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi, Erik: Erik Romijn wrote: > On Wed, Feb 07, 2007 at 07:28:02PM -0500, John Leslie wrote: > >> Enke Chen wrote: >> >>> Please note these changes to the attribute names (the type codes are >>> unchanged): >>> >>> NEW_AS_PATH ---> AS4_PATH >>> NEW_AGGREGATOR ---> AS4_AGGREGATOR >>> > > Perhaps a stupid question, but why not go for "AS4 speaker" and "AS2 > speaker" too instread of "NEW/OLD speaker"? > > Because the terminologies "NEW/OLD speaker" do not refer to protocol code points . They are used in the document only for the sake of presentation, and they seem to be a good fit for the intended purpose. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Feb 12 07:04:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGZrQ-0007AZ-02; Mon, 12 Feb 2007 07:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGZrP-0007AU-1w for idr@ietf.org; Mon, 12 Feb 2007 07:00:43 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGZrM-0001Qy-AE for idr@ietf.org; Mon, 12 Feb 2007 07:00:43 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDC005YSMNWBL@szxga02-in.huawei.com> for idr@ietf.org; Mon, 12 Feb 2007 19:59:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JDC00FZ0MNWR3@szxga02-in.huawei.com> for idr@ietf.org; Mon, 12 Feb 2007 19:59:56 +0800 (CST) Received: from s197451 ([10.111.64.34]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDC0004FMNOLR@szxml03-in.huawei.com> for idr@ietf.org; Mon, 12 Feb 2007 19:59:56 +0800 (CST) Date: Mon, 12 Feb 2007 19:59:48 +0800 From: shengcheng To: idr@ietf.org Message-id: <000001c74e9d$4b815e70$22406f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdOnUrQFiGDiawmRZOJMDmU6Se2+w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Idr] about bgp label routes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0795922083==" Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0795922083== Content-type: multipart/alternative; boundary="Boundary_(ID_oDSCi7bXnvKKWI1KkZIwwQ)" This is a multi-part message in MIME format. --Boundary_(ID_oDSCi7bXnvKKWI1KkZIwwQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Folks, As per RFC3107, which define label route, I have a doubt listed as follows: When one router receive a label route(suppose it is prefix: 10.1.1.0/24, label: 200, nexthop: 1.1.1.1), how does the router understand this routes? Does it means two routes, one of which is a label route and the other is ipv4 ordinary route of 10.1.1.0/24 with 1.1.1.1 as nexthop ? Or it means it is just one label route ? Thanks Cheng --Boundary_(ID_oDSCi7bXnvKKWI1KkZIwwQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Folks,

As per RFC3107, which define label route, I have a doubt listed as follows:

When one router receive a label route(suppose it is prefix: 10.1.1.0/24, label: 200, nexthop: 1.1.1.1), how does the

router understand this routes? Does it means two routes, one of which is a label route and the other is ipv4 ordinary route of

10.1.1.0/24 with 1.1.1.1 as nexthop ? Or it means it is just one label route ?  

 

Thanks

Cheng

--Boundary_(ID_oDSCi7bXnvKKWI1KkZIwwQ)-- --===============0795922083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0795922083==-- From idr-bounces@ietf.org Mon Feb 12 08:09:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGau2-0007aC-A8; Mon, 12 Feb 2007 08:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGau1-0007a6-FT for idr@ietf.org; Mon, 12 Feb 2007 08:07:29 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGaty-0007Vf-G7 for idr@ietf.org; Mon, 12 Feb 2007 08:07:29 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1CD7CdA003349; Mon, 12 Feb 2007 07:07:21 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 07:07:16 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.20]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 18:37:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] about bgp label routes Date: Mon, 12 Feb 2007 18:36:45 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196536971C@INEXC1U01.in.lucent.com> In-Reply-To: <000001c74e9d$4b815e70$22406f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] about bgp label routes thread-index: AcdOnUrQFiGDiawmRZOJMDmU6Se2+wACUEMQ From: "Bhatia, Manav \(Manav\)" To: "shengcheng" , X-OriginalArrivalTime: 12 Feb 2007 13:07:12.0660 (UTC) FILETIME=[B5E57540:01C74EA6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Cheng, =20 A labeled route is advertised as label:prefix.=20 =20 Router is able to parse the incoming (labeled) prefix based on the SAFI of the route. In your example, it is just one labeled route. =20 Cheers, Manav ________________________________ From: shengcheng [mailto:shengc@huawei.com]=20 Sent: Monday, February 12, 2007 5:30 PM To: idr@ietf.org Subject: [Idr] about bgp label routes =09 =09 Folks,=20 As per RFC3107, which define label route, I have a doubt listed as follows: When one router receive a label route(suppose it is prefix: 10.1.1.0/24, label: 200, nexthop: 1.1.1.1), how does the=20 router understand this routes? Does it means two routes, one of which is a label route and the other is ipv4 ordinary route of 10.1.1.0/24 with 1.1.1.1 as nexthop ? Or it means it is just one label route ? =20 =20 Thanks Cheng _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 13 00:01:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpk8-0007Uw-N9; Mon, 12 Feb 2007 23:58:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpk7-0007Qq-CM for idr@ietf.org; Mon, 12 Feb 2007 23:58:15 -0500 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGpk0-0005KL-70 for idr@ietf.org; Mon, 12 Feb 2007 23:58:15 -0500 Received: from vaioz1.apnic.net (geoff.telstra.net [203.50.0.18]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l1D4vwhr098110; Tue, 13 Feb 2007 15:57:58 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070213155251.042689b0@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 13 Feb 2007 15:58:08 +1100 To: "Erik Romijn" , John Leslie From: Geoff Huston Subject: Re: [Idr] [Fwd: I-D ACTION:draft-ietf-idr-as4bytes-13.txt] In-Reply-To: <20070209145803.GF13343@ripe.net> References: <45CA4A4B.4040108@cisco.com> <20070208002802.GD2308@verdi> <20070209145803.GF13343@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org At 01:58 AM 10/02/2007, Erik Romijn wrote: >On Wed, Feb 07, 2007 at 07:28:02PM -0500, John Leslie wrote: > > Enke Chen wrote: > > > > > > Please note these changes to the attribute names (the type codes are > > > unchanged): > > > > > > NEW_AS_PATH ---> AS4_PATH > > > NEW_AGGREGATOR ---> AS4_AGGREGATOR > >Perhaps a stupid question, but why not go for "AS4 speaker" and "AS2 >speaker" too instread of "NEW/OLD speaker"? And that would change the code to support for these larger AS numbers in a BGP implementation in what way? At some point its time to stop polishing documents in all kinds of wonderful and inventive ways and make the pragmatic judgement that its good enough to support running inter-operable code. I suspect that this particular draft got to that state of adequacy at least 4 revs ago, and probably more. Lets face it, nothing in the 12 - 13 rev changes the code (and yes, I've implemented this spec, so I speak with some experience here). So why are we doing this document polishing? (no, please don't tell me - sadly, I already know the answer!) regards, Geoff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 16 13:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI86K-0001Gx-F3; Fri, 16 Feb 2007 13:46:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI86I-0001DE-Tt for idr@ietf.org; Fri, 16 Feb 2007 13:46:31 -0500 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI86H-0005h8-Fx for idr@ietf.org; Fri, 16 Feb 2007 13:46:30 -0500 Received: by manos.scc.mi.org (Postfix, from userid 1025) id F41434E7DD; Fri, 16 Feb 2007 13:46:26 -0500 (EST) Date: Fri, 16 Feb 2007 13:46:26 -0500 From: Jeffrey Haas To: idr@ietf.org Subject: Beating the ATOMIC_AGGREGGATE horse (was Re: [Idr] draft-ietf-as-pathlimit-02) Message-ID: <20070216184626.GA28120@scc.mi.org> References: <0B252636-ED28-4197-B58F-89A0F1EF91F6@cisco.com> <200612231925.kBNJPjxT053660@workhorse.brookfield.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612231925.kBNJPjxT053660@workhorse.brookfield.occnc.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I'm not actively following IDR at the moment, but I'd like to chime in for the archives. It should be noted we had similar churn around ATOMIC_AGGREGATE during some of the earlier drafts that lead up to RFC 4271. The current RFC text reflects some of that. My personal opinion is that if your implementation is going to attach ATOMIC_AGGREGATE to routes as the result of filtering more specific routes, do so when you filter for AS_PATHLIMIT. If you don't do this generally, then your sin is no greater for AS_PATHLIMIT. The most important point is raised below in Curtis's reply: Don't de-aggregate. For posterity, consider the following cases: 1. If you learned a less and a more specific route from a peer and you choose to install only the less specific route, the installed less specific route should have ATOMIC_AGGREGATE added to it. Note that you can get away with not attaching ATOMIC_AGGREGATE if the AS_PATHs are identical. Arguably, the other path attributes should also be identical, but I won't assert this is provable. 1 is our base case. It's what 1771 more or less said. In practice, we only worry about attaching ATOMIC_AGGREGATE when we're truncating the AS_PATH as part of the process of creating an explicit aggregate, i.e. a "new route". 1 is a form of "implicit aggregation". 2. RFC 1771 also noted that we care about this when considering routes from a given peer. In the case where one peer gives us the less specific route and another peer gives us a more specific route, we must trust that we have received the less specific route correctly tagged (or not) with ATOMIC_AGGREGATE. If it isn't so marked, the presumption is that we can get to the more specific network via the less specific peer. I suspect we'd find plenty of examples where this isn't the case in practice. I.e. ATOMIC_AGGREGATE should be present, but isn't. There are other cases where implicit aggregation could occur. 3. If you have installed a more and a less specific route in your LocRib and choose to advertise only the less specific route via policy to a peer, you should probably mark the less specific route you advertise with ATOMIC_AGGREGATE - see 1. for possible exceptions. This means that anyone who filters more specific routes should be generating ATOMIC_AGGREGATE everywhere. Given that we know that filtering of more specifics is common operational practice and we see very little in the way of ATOMIC_AGGREGATE in the Internet routing table, implements commonly don't do this. Additionally, we're creating extentions to allow such filtering to be pushed - see ORFs. 4. Go back to 1. If we receive a more specific and a less specific route, but only install the less specific route in our Adj-Rib-In (ingress filtering), we have a scneario where we might have to add ATOMIC_AGGREGATE depending on the results of route selection. However, by filtering, we've lost state. Without requiring that all routes be retained (even if ineligible for route selection by policy), we can't properly do step 1. Common practice is to discard ineligible routes - see route refresh. Even if we keep all routes (see 4), "properly" doing ATOMIC_AGGREGATE imposes a large amount of additional overhead: - For 1, after you've completed route selection, you must walk your more specific routes in the selected route's adj-rib-in and see if we've failed to select any more specific route as well. Similarly, upon updating a route that might be more specific, we must walk all less specific routes and see if we need to change the marking. - For 3, when choosing to place your route in the adj-rib-out, you have to see if you're also going to be putting more specifics in the adj-rib-out and mark routes appropriately. Consequently, if you are incrementally "updating your adj-rib-out" you may need to change whether the route is marked or not - i.e. it can flap depending on the particulars of your implementation. This sort of thing isn't always atomic. - For 4, we don't want to keep all of our ineligible routes around. We've actually gone to a lot of effort to provide mechanisms to throw them away and be able to deal with that. Summary: We have a number of test cases we could apply to verify conformance with properly (at least within my understanding) attaching ATOMIC_AGGREGATE. I suspect if you take any given implementation and try those cases, they'll not pass. The case that's known to pass is explicit aggregation with path truncation. Conclusion: ATOMIC_AGGREGATE has never quite worked in our specs. At best, you can mark a route with it and disallow deaggregation. I'm not aware of implementations that have policy that allows for this sort of de-aggregation today, although that may simply be my ignorance. Presuming the lack of de-aggregation tools, this has been a non-issue. We could thus include text about ATOMIC_AGGREGATE in AS_PATHLIMIT or any other spec. Personally, I think it's better to not mention it. On Sat, Dec 23, 2006 at 02:25:45PM -0500, Curtis Villamizar wrote: > Not quite strong enough. IMHO. > > You should put ATOMIC_AGGREGATE on any prefix that has AS_PATHLIMIT so > that any downstream aggregator is forced to form an aggregate with > ATOMIC_AGGREGATE by virtue of the rule in BGP that if a component of > the aggregate has ATOMIC_AGGREGATE then any less specific aggregate > formed using it must have ATOMIC_AGGREGATE. > > I suppose the reason for using SHOULD is that eventually aggregators > that don't understand AS_PATHLIMIT should go away and with it the need > for these extra ATOMIC_AGGREGATE. > > We're being a bit pedantic about this whole topic if we look at this > from a practical standpoint since a long time ago we concluded that > providers were all using ATOMIC_AGGREGATE and tossing the entire > AS_PATH when forming an aggregate. Since ATOMIC_AGGREGATE is > informational in the absense of de-aggregation this is not terribly > important. > > The only thing that people were doing that was potentially dangerous > was combining a /x and /y where x the AS_PATH and adding ATOMIC_AGGREGATE. That was safe in some > topologies but generally a vary bad practice. > > Do you agree with that? > > Curtis > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Feb 19 14:18:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJDzW-0003Ht-Nv; Mon, 19 Feb 2007 14:16:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJDzV-0003Hl-0h for idr@ietf.org; Mon, 19 Feb 2007 14:16:01 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJDzT-0005Xf-MG for idr@ietf.org; Mon, 19 Feb 2007 14:16:01 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id l1JJFxif092201 for ; Mon, 19 Feb 2007 11:15:59 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l1JJFxB93209 for ; Mon, 19 Feb 2007 11:15:59 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200702191915.l1JJFxB93209@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4897.1171912559.1@juniper.net> Date: Mon, 19 Feb 2007 11:15:59 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Idr] IDR WG agenda X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, So far we did not receive any requests for agenda items for the upcoming IDR WG meeting. The deadline is March 11, 2007. And if you plan to make a presentation, please also keep in mind the rule "no Internet Draft - no time slot". Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 22 13:06:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKIIU-0000kU-8f; Thu, 22 Feb 2007 13:04:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKIIS-0000ja-Tm for idr@ietf.org; Thu, 22 Feb 2007 13:04:00 -0500 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKIIP-0001zb-N6 for idr@ietf.org; Thu, 22 Feb 2007 13:04:00 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 0B204147AF4 for ; Thu, 22 Feb 2007 13:03:39 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l1MI3cLG019561; Thu, 22 Feb 2007 10:03:38 -0800 From: Bill Fenner Message-Id: <200702221803.l1MI3cLG019561@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idr@ietf.org Date: Thu, 22 Feb 2007 10:03:38 -0800 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Idr] AFI IANA Considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org http://www.iana.org/assignments/address-family-numbers Address families 1-25 have been defined; 26-65534 are available. My take of the feeling in the room was to reserve some, definitely have some FCFS, and possibly have some other. Here's a proposal: 26-32767: Standards Action (standards-track RFC required) 32768-65534: FCFS This allows a fairly large FCFS range, but still reserves a fairly large range for standards-track items and keeps the standards-track numbers with the already-assigned values. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Feb 24 12:24:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0XM-0002Os-1j; Sat, 24 Feb 2007 12:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0XL-0002L7-AH for idr@ietf.org; Sat, 24 Feb 2007 12:18:19 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL0XH-0003Z5-UH for idr@ietf.org; Sat, 24 Feb 2007 12:18:19 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l1OHEETh045312; Sat, 24 Feb 2007 12:14:14 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l1OHEETh045312 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1172337254; bh=aCqRi+R9yAhd02xEmKJI3meNWkQ=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=Rin5QvXXYYqmZQ/F48NR4kiaw/5VpPPCHN jmh7RVIPJZw796QY3UULXZD6rQLsY0itzb3BhQo59Fl13L/v1KAg== Message-Id: <200702241714.l1OHEETh045312@workhorse.brookfield.occnc.com> To: Bill Fenner From: Curtis Villamizar Subject: Re: [Idr] AFI IANA Considerations In-reply-to: Your message of "Thu, 22 Feb 2007 10:03:38 PST." <200702221803.l1MI3cLG019561@bright.research.att.com> Date: Sat, 24 Feb 2007 12:14:14 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <200702221803.l1MI3cLG019561@bright.research.att.com> Bill Fenner writes: > > > http://www.iana.org/assignments/address-family-numbers > > Address families 1-25 have been defined; 26-65534 are available. My take > of the feeling in the room was to reserve some, definitely have some FCFS, > and possibly have some other. > > Here's a proposal: > > 26-32767: Standards Action (standards-track RFC required) > 32768-65534: FCFS > > This allows a fairly large FCFS range, but still reserves a fairly > large range for standards-track items and keeps the standards-track > numbers with the already-assigned values. > > Bill Bill, It might be worthwhile to indicate that FCFS is intended to be temporary until sufficient implementation and deployment existed to justify standards-track (with the possibility of "large values of temporary"). Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Feb 24 12:28:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0hF-0003NO-7M; Sat, 24 Feb 2007 12:28:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0hD-0003NG-ML for idr@ietf.org; Sat, 24 Feb 2007 12:28:31 -0500 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL0hC-00063k-GO for idr@ietf.org; Sat, 24 Feb 2007 12:28:31 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id C6F00147B43; Sat, 24 Feb 2007 12:28:11 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l1OHSBAg012347; Sat, 24 Feb 2007 09:28:11 -0800 From: Bill Fenner Message-Id: <200702241728.l1OHSBAg012347@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: curtis@occnc.com Subject: Re: [Idr] AFI IANA Considerations Date: Sat, 24 Feb 2007 09:28:11 -0800 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org >It might be worthwhile to indicate that FCFS is intended to be >temporary until sufficient implementation and deployment existed to >justify standards-track (with the possibility of "large values of >temporary"). One of the big problems that we've run into with having different classes of numbers is that it introduces interoperatbility problems when there are two different numbers to indicate the same thing. RFC 4020 describes a procedure which gets the WG involved in allowing Standards Action code points to be assigned to a document that is progressing in the WG. This is the procedure that got AS_PATHLIMIT a path attribute while it's still an I-D. If it's valuable to limit assignments to "things that will eventually be published as standards track", as I think you're advocating, then I think "Standards Action + RFC4020 Early Assignment" for the whole range would be more appropriate. Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Feb 24 13:42:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL1ma-0000C6-Az; Sat, 24 Feb 2007 13:38:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL1mY-0000Bz-Tp for idr@ietf.org; Sat, 24 Feb 2007 13:38:06 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL1mW-0002WM-F7 for idr@ietf.org; Sat, 24 Feb 2007 13:38:06 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l1OIY2Bq045966; Sat, 24 Feb 2007 13:34:02 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l1OIY2Bq045966 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1172342042; bh=6Uz7Z/fN3YhFKK56RnT5toIPkK4=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=AcJyXSvkKAr5KDxeqfQR8nUH4N9v7RlrpS PmB4ATUnYt1bYvQUbiJoJcJjgB2bhZ3G/gtwvb0VQ0JYmTwDuSEg== Message-Id: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> To: Bill Fenner From: Curtis Villamizar Subject: Re: [Idr] AFI IANA Considerations In-reply-to: Your message of "Sat, 24 Feb 2007 09:28:11 PST." <200702241728.l1OHSBAg012347@bright.research.att.com> Date: Sat, 24 Feb 2007 13:34:02 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org In message <200702241728.l1OHSBAg012347@bright.research.att.com> Bill Fenner writes: > > > >It might be worthwhile to indicate that FCFS is intended to be > >temporary until sufficient implementation and deployment existed to > >justify standards-track (with the possibility of "large values of > >temporary"). > > One of the big problems that we've run into with having different > classes of numbers is that it introduces interoperatbility problems when > there are two different numbers to indicate the same thing. Its a transition issue. 1. Send and recv temporary value only. 2. Send temporary value and recv either one. 3. Send standards track value and recv either one. 4. Send and recv standards track value only. An incentive to get on standards track sooner rather than later is that the transition is less painful. > RFC 4020 describes a procedure which gets the WG involved in allowing > Standards Action code points to be assigned to a document that is > progressing in the WG. This is the procedure that got AS_PATHLIMIT > a path attribute while it's still an I-D. > > If it's valuable to limit assignments to "things that will eventually > be published as standards track", as I think you're advocating, then > I think "Standards Action + RFC4020 Early Assignment" for the whole > range would be more appropriate. Right. But for limited experimentation if you are going to do anything, allowing FCFS on a temporary basis would be good. Allowing permanent FCFS allocation is inviting a free for all. > Bill Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Feb 25 12:38:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNC0-0007fW-Er; Sun, 25 Feb 2007 12:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLNBz-0007fJ-K9 for idr@ietf.org; Sun, 25 Feb 2007 12:29:47 -0500 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLNBp-0006Vo-HF for idr@ietf.org; Sun, 25 Feb 2007 12:29:47 -0500 Received: from melandri.lan ([62.6.163.68]) (authenticated bits=0) by hibernia.jakma.org (8.13.8/8.13.8) with ESMTP id l1PHTHwv010726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Feb 2007 17:29:30 GMT Date: Sun, 25 Feb 2007 17:29:08 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Curtis Villamizar Subject: Re: [Idr] AFI IANA Considerations In-Reply-To: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> Message-ID: References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.1.12 (hibernia.jakma.org [212.17.55.49]); Sun, 25 Feb 2007 17:29:33 +0000 (GMT) X-Virus-Scanned: ClamAV 0.88.7/2647/Sun Feb 25 00:13:21 2007 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 2.5 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Sat, 24 Feb 2007, Curtis Villamizar wrote: > Its a transition issue. > > 1. Send and recv temporary value only. > 2. Send temporary value and recv either one. > 3. Send standards track value and recv either one. > 4. Send and recv standards track value only. > An incentive to get on standards track sooner rather than later is > that the transition is less painful. Why bother? If a code-point is assigned, why change it just because the standard describing its use matures to standards track? Who cares if a number was assigned by an FCFS process? It's assigned... regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: First Rule of History: History doesn't repeat itself -- historians merely repeat each other. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Feb 26 15:17:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmEp-0000O8-9j; Mon, 26 Feb 2007 15:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmEn-0000Nv-VU; Mon, 26 Feb 2007 15:14:21 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmEc-0007jX-Gz; Mon, 26 Feb 2007 15:14:21 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 665E526ED8; Mon, 26 Feb 2007 20:14:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLmEc-0002Z4-9u; Mon, 26 Feb 2007 15:14:10 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 26 Feb 2007 15:14:10 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr@ietf.org Subject: [Idr] Last Call: draft-ietf-idr-avoid-transition (Avoid BGP Best Path Transitions from One External to Another) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Avoid BGP Best Path Transitions from One External to Another ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11821&rfc_flag=0 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 27 09:13:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM32T-0003q0-UN; Tue, 27 Feb 2007 09:10:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM32S-0003ka-Fe for idr@ietf.org; Tue, 27 Feb 2007 09:10:44 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM32N-0003Sp-TZ for idr@ietf.org; Tue, 27 Feb 2007 09:10:44 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id A0BA653E1B5; Tue, 27 Feb 2007 09:10:30 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id XBGxy-CcLH+g; Tue, 27 Feb 2007 09:10:23 -0500 (EST) Received: from [124.81.250.36] (unknown [124.81.250.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 997BC53E072; Tue, 27 Feb 2007 09:10:22 -0500 (EST) In-Reply-To: <200702221803.l1MI3cLG019561@bright.research.att.com> References: <200702221803.l1MI3cLG019561@bright.research.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [Idr] AFI IANA Considerations Date: Tue, 27 Feb 2007 22:10:18 +0800 To: Bill Fenner X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Works for me. --John On Feb 23, 2007, at 2:03 AM, Bill Fenner wrote: > > http://www.iana.org/assignments/address-family-numbers > > Address families 1-25 have been defined; 26-65534 are available. > My take > of the feeling in the room was to reserve some, definitely have > some FCFS, > and possibly have some other. > > Here's a proposal: > > 26-32767: Standards Action (standards-track RFC required) > 32768-65534: FCFS > > This allows a fairly large FCFS range, but still reserves a fairly > large range for standards-track items and keeps the standards-track > numbers with the already-assigned values. > > Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 27 11:07:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4qB-00046H-QW; Tue, 27 Feb 2007 11:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4qA-000434-S5; Tue, 27 Feb 2007 11:06:10 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4qA-0007hM-Fq; Tue, 27 Feb 2007 11:06:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1FE9426EE5; Tue, 27 Feb 2007 16:06:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HM4qA-00082U-0f; Tue, 27 Feb 2007 11:06:10 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 27 Feb 2007 11:06:10 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'Autonomous System Confederations for BGP' to Draft Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'Autonomous System Confederations for BGP ' as a Draft Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-06.txt Technical Summary The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. Working Group Summary Working Group Last Call resulted in some issues which were addressed in an update to the draft. Protocol Quality Bill Fenner reviewed this spec for the IESG. The Implementation Report is available at http://www.ietf.org/IESG/Implementations/implem_RFC3065bis.txt Note to RFC Editor This document obsoletes RFC 3065. Please make the following changes: Header: OLD: INTERNET-DRAFT Paul Traina Blissfully Retired Danny McPherson Arbor Networks John Scudder Juniper Networks Expires: August 2007 February 2007 NEW: INTERNET-DRAFT Paul Traina Blissfully Retired Danny McPherson Arbor Networks John Scudder Juniper Networks Expires: August 2007 February 2007 Obsoletes: RFC 3065 Abstract: Add as the final paragraph: This document obsoletes RFC 3065. Introduction: OLD: As currently defined, BGP requires that all BGP speakers within a NEW: As originally defined, BGP requires that all BGP speakers within a OLD: This document is a revision of [RFC 3065], which is itself a revision NEW: This document is a revision of, and obsoletes, [RFC 3065], which is itself a revision REFERENCES Please update references to RFC 2796 throughout to refer to RFC 4456 instead. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 27 11:53:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5Y8-0001dq-Vk; Tue, 27 Feb 2007 11:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5Y7-0001dk-KY for idr@ietf.org; Tue, 27 Feb 2007 11:51:35 -0500 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM5Y6-00066z-EI for idr@ietf.org; Tue, 27 Feb 2007 11:51:35 -0500 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 505D64E7E0; Tue, 27 Feb 2007 11:51:25 -0500 (EST) Date: Tue, 27 Feb 2007 11:51:25 -0500 From: Jeffrey Haas To: Paul Jakma Subject: Re: [Idr] AFI IANA Considerations Message-ID: <20070227165125.GA27970@scc.mi.org> References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Bill Fenner , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Sun, Feb 25, 2007 at 05:29:08PM +0000, Paul Jakma wrote: > Why bother? If a code-point is assigned, why change it just because > the standard describing its use matures to standards track? Who cares > if a number was assigned by an FCFS process? It's assigned... To echo Paul's point from a different perspective, People Don't Move. It's why we had the issues with SAFI numbering in the first place. Personally, I'd rather see them move but insert your cat-herding comment of choice here. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 27 12:43:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6Ku-0001Ev-6s; Tue, 27 Feb 2007 12:42:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6Ks-0001Em-ME for idr@ietf.org; Tue, 27 Feb 2007 12:41:58 -0500 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6Kr-00047I-GX for idr@ietf.org; Tue, 27 Feb 2007 12:41:58 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id CDFB1147CD6; Tue, 27 Feb 2007 12:41:38 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l1RHfcAD020331; Tue, 27 Feb 2007 09:41:38 -0800 From: Bill Fenner Message-Id: <200702271741.l1RHfcAD020331@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Jeffrey Haas Subject: Re: [Idr] AFI IANA Considerations References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> <20070227165125.GA27970@scc.mi.org> Date: Tue, 27 Feb 2007 09:41:38 -0800 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org I agree there's no motivation to move. The barrier to moving isn't technical, it's simply motivation. Why waste time imlementing transition code that doesn't increase the utility of the implementation? I would reject any proposal of forcing moves as unreasonable, so let's take that off the table. I think there are now 2 options: A. 25-32767: Standards Action + Early Assignment 32768-65534: FCFS (permanent) B. 25-65534: Standards Action + Early Assignment There was a general feeling in the room in San Diego that FCFS was useful, but I can't remember if we talked about Early Assignment as a placeholder. Curtis suggested that experimentation might be a reason to have FCFS, but instead how about B'. 25-64999: Standards Action + Early Assignment 65000-65535: Private Use Bill _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 27 12:49:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6RS-0005UO-SY; Tue, 27 Feb 2007 12:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6RS-0005UJ-3T for idr@ietf.org; Tue, 27 Feb 2007 12:48:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6RQ-0004wL-Mu for idr@ietf.org; Tue, 27 Feb 2007 12:48:46 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2007 09:48:34 -0800 X-IronPort-AV: i="4.14,226,1170662400"; d="scan'208"; a="394293297:sNHT2925935876" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1RHmWm7023096; Tue, 27 Feb 2007 09:48:32 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1RHmWUw028012; Tue, 27 Feb 2007 09:48:32 -0800 (PST) Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA04426; Tue, 27 Feb 2007 09:48:03 -0800 (PST) Date: Tue, 27 Feb 2007 09:48:03 -0800 From: Chandrashekhar Appanna To: Bill Fenner Subject: Re: [Idr] AFI IANA Considerations Message-ID: <20070227174803.GK12135@cisco.com> References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> <20070227165125.GA27970@scc.mi.org> <200702271741.l1RHfcAD020331@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702271741.l1RHfcAD020331@bright.research.att.com> User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1182; t=1172598512; x=1173462512; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[Idr]=20AFI=20IANA=20Considerations |Sender:=20; bh=GPvNdKet82vOI12C/wJ6DJ8RD0rWfs3BRwT34ygQ3Kg=; b=TqA6cyVEQ3W4a2HxanECYxH6Tdg+GuGf1fmBjOx0JijSiDVnLlJkIHV84V7SHeWyDAjW7ZSO fmASc+ssrHofYRTOzvyO2k0ify+1BuuibNd0pvotx/1tIsqvPVczaOre; Authentication-Results: sj-dkim-2; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org On Tue, Feb 27, 2007 at 09:41:38AM -0800, Bill Fenner wrote: > > I agree there's no motivation to move. The barrier to > moving isn't technical, it's simply motivation. > Why waste time imlementing transition code that > doesn't increase the utility of the implementation? > > I would reject any proposal of forcing moves as > unreasonable, so let's take that off the table. > I think there are now 2 options: > > A. 25-32767: Standards Action + Early Assignment > 32768-65534: FCFS (permanent) > > B. 25-65534: Standards Action + Early Assignment > > There was a general feeling in the room in San > Diego that FCFS was useful, but I can't remember Yes.. that was my impression too. I too still feel that A. is the way to go. Rgds, Chandra. > if we talked about Early Assignment as a placeholder. > Curtis suggested that experimentation might be a > reason to have FCFS, but instead how about > > B'. 25-64999: Standards Action + Early Assignment > 65000-65535: Private Use > > Bill > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 28 19:24:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMZ2v-0003S3-CV; Wed, 28 Feb 2007 19:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMZ2u-0003Rw-Bp for idr@ietf.org; Wed, 28 Feb 2007 19:21:20 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMZ2t-0007iK-1e for idr@ietf.org; Wed, 28 Feb 2007 19:21:20 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 28BFB53E1B5; Wed, 28 Feb 2007 19:21:08 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id fJHa+05LNtwK; Wed, 28 Feb 2007 19:21:01 -0500 (EST) Received: from [172.23.10.228] (nat-service4.juniper.net [66.129.225.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 1EFB053E072; Wed, 28 Feb 2007 19:20:59 -0500 (EST) In-Reply-To: <200702271741.l1RHfcAD020331@bright.research.att.com> References: <200702241834.l1OIY2Bq045966@workhorse.brookfield.occnc.com> <20070227165125.GA27970@scc.mi.org> <200702271741.l1RHfcAD020331@bright.research.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32C55AD1-79D1-46E8-B14D-9CDF6096C70B@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [Idr] AFI IANA Considerations Date: Thu, 1 Mar 2007 08:20:52 +0800 To: Bill Fenner X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: idr@ietf.org, Paul Jakma X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Now that I come to think of it, here's Yet Another Variant which I may have mentioned at the meeting where we discussed this: 25-16383: Standards Action + Early Assignment 16384-32767: FCFS 32768-65535: Reserved The point being, even the ranges given above for SA+EA and FCFS are absurdly large. If there is actually a run on the bank as Curtis describes (at least that's what I assume "free for all" means) then the damage that can be done is bounded and there's still a large reserved range kept fallow for future needs. On the other hand I confidently predict that we will never need to break into the reserved range because exhausting the given ranges is inconceivable [1]. I'm fine with the proposal as written, but if folks need a security blanket, maybe the variant above will be sufficient. --John [1] With apologies to Inigo Montoya. Also, we will never need more than 640k of memory. On Feb 28, 2007, at 1:41 AM, Bill Fenner wrote: > > I agree there's no motivation to move. The barrier to > moving isn't technical, it's simply motivation. > Why waste time imlementing transition code that > doesn't increase the utility of the implementation? > > I would reject any proposal of forcing moves as > unreasonable, so let's take that off the table. > I think there are now 2 options: > > A. 25-32767: Standards Action + Early Assignment > 32768-65534: FCFS (permanent) > > B. 25-65534: Standards Action + Early Assignment > > There was a general feeling in the room in San > Diego that FCFS was useful, but I can't remember > if we talked about Early Assignment as a placeholder. > Curtis suggested that experimentation might be a > reason to have FCFS, but instead how about > > B'. 25-64999: Standards Action + Early Assignment > 65000-65535: Private Use > > Bill > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 28 19:31:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMZCE-0006zz-Hd; Wed, 28 Feb 2007 19:30:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZj-0002Dj-GD; Wed, 28 Feb 2007 18:51:12 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYZd-0008L0-FS; Wed, 28 Feb 2007 18:51:11 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 285F12AD42; Wed, 28 Feb 2007 23:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYc-00044b-T9; Wed, 28 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --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 : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-09.txt Pages : 4 Date : 2007-2-28 This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-28161322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28161322.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart--