From ietfc@btconnect.com Fri Jan 7 10:34:33 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5513A68D5 for ; Fri, 7 Jan 2011 10:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzh6IH11LH0k for ; Fri, 7 Jan 2011 10:34:32 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 673823A67A1 for ; Fri, 7 Jan 2011 10:34:31 -0800 (PST) Received: from host81-156-207-254.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.254]) by c2beaomr06.btconnect.com with SMTP id BMU76424; Fri, 07 Jan 2011 18:36:36 +0000 (GMT) Message-ID: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: Date: Fri, 7 Jan 2011 18:33:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D275D34.0037, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4D275D35.0078,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: idr Subject: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:34:33 -0000 Warren A propos draft-ietf-idr-deprecate-as-sets-00 Deprecate seems to be getting quite an airing at present - there is a netconf implementor who is questioning it as well - but I am with Adrian, that what we have works, and is well enough defined and understood. Tom Petch ----- Original Message ----- From: "Andrew Sullivan" To: Sent: Friday, January 07, 2011 3:15 PM Subject: Re: Old transport-layer protocols to Historic? > I'm not keen to start a language war, but. . . > > On Fri, Jan 07, 2011 at 08:39:37AM +0200, Mykyta Yevstifeyev wrote: > > > Moreover, 'obsoleted' means the same as 'deprecated' or 'non-current' > > (see http://www.synonym.com/synonyms/obsolete/ or > > http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So it is a > > problem in RFC2026. > > . . .I fully disagree with that, regardless of what those claims of > synonymy say. To deprecate something is to express disapproval. To > mark something as obsolete doesn't do that; it merely says that the > marked thing is outdated. There is a useful distinction here worth > maintaining. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From jakob.heitz@ericsson.com Fri Jan 7 10:56:28 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF4A3A68EA for ; Fri, 7 Jan 2011 10:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GB3nqL5QBnv for ; Fri, 7 Jan 2011 10:56:27 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 346433A67A1 for ; Fri, 7 Jan 2011 10:56:27 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p07JZ0mr007294; Fri, 7 Jan 2011 13:35:03 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 7 Jan 2011 13:58:28 -0500 From: Jakob Heitz To: "t.petch" , "warren@kumari.net" Date: Fri, 7 Jan 2011 13:58:27 -0500 Thread-Topic: [Idr] Fw: Old transport-layer protocols to Historic? Thread-Index: Acuumd7QhjqFW7YgQhSNNZcpiM+L/AAAl8sQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> In-Reply-To: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:56:28 -0000 "deprecate" is too wussy. It does nothing. We need a recommendation of what to do when we receive one. Suggestions: 1. Replace the AS-SET with the AS number of the sending speaker 2. Replace the AS-SET with a special ASN that means "there was an AS-SET he= re" 3. drop the AS-SET 4. drop the route I don't like 3 and 4. The recommended action could be knobbed (optional). -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of t.petch > Sent: Friday, January 07, 2011 9:33 AM > To: warren@kumari.net > Cc: idr > Subject: [Idr] Fw: Old transport-layer protocols to Historic? >=20 > Warren >=20 > A propos draft-ietf-idr-deprecate-as-sets-00 >=20 > Deprecate seems to be getting quite an airing at present - there > is a netconf implementor who is questioning it as well - but I am with > Adrian, that what we have works, and is well enough defined and=20 > understood. >=20 > Tom Petch >=20 > ----- Original Message -----=20 > From: "Andrew Sullivan" > To: > Sent: Friday, January 07, 2011 3:15 PM > Subject: Re: Old transport-layer protocols to Historic? >=20 >=20 > > I'm not keen to start a language war, but. . . > >=20 > > On Fri, Jan 07, 2011 at 08:39:37AM +0200, Mykyta Yevstifeyev wrote: > >=20 > > > Moreover, 'obsoleted' means the same as 'deprecated' or=20 > 'non-current' =20 > > > (see http://www.synonym.com/synonyms/obsolete/ or =20 > > >=20 > http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So=20 > it is a =20 > > > problem in RFC2026. > >=20 > > . . .I fully disagree with that, regardless of what those claims of > > synonymy say. To deprecate something is to express disapproval. To > > mark something as obsolete doesn't do that; it merely says that the > > marked thing is outdated. There is a useful distinction here worth > > maintaining. > >=20 > > A > >=20 > > --=20 > > Andrew Sullivan > > ajs@shinkuro.com > > Shinkuro, Inc. > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From ilya@nobulus.com Fri Jan 7 11:42:53 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3953A6908 for ; Fri, 7 Jan 2011 11:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktl-Z0K27KDU for ; Fri, 7 Jan 2011 11:42:52 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 364103A6825 for ; Fri, 7 Jan 2011 11:42:51 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 0B508170B1; Fri, 7 Jan 2011 20:44:56 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f9T1nj2zCWku; Fri, 7 Jan 2011 20:44:53 +0100 (CET) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 5059F170AF; Fri, 7 Jan 2011 20:44:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> Date: Fri, 7 Jan 2011 20:44:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D07CAF7-27E1-4463-BF0A-306CAC1FB74E@nobulus.com> References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1082) Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 19:42:53 -0000 Jakob, very valid points. Please see comments below. > "deprecate" is too wussy. It does nothing. > We need a recommendation of what to do when we receive one. > Suggestions: > 1. Replace the AS-SET with the AS number of the sending speaker what if AS-SET is not the last element of the AS-PATH? e.g. an = announcement went through some routers which don't yet know that AS-SET = has been depricated? doesn't sound like a good idea > 2. Replace the AS-SET with a special ASN that means "there was an = AS-SET here" this appeals to me as the best possible solution. While removing AS-SET = we should probably also remove AGGREGATOR and ATOMIC_AGGREGATE. IANA = section should be updated then and we need early allocation ASAP. > 3. drop the AS-SET > 4. drop the route >=20 > I don't like 3 and 4. me neither > The recommended action could be knobbed (optional). >=20 and what to do by default? Kind regards, iLya= From david.freedman@uk.clara.net Mon Jan 10 03:28:49 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095F528C13B for ; Mon, 10 Jan 2011 03:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKRNzF3EqP3Z for ; Mon, 10 Jan 2011 03:28:47 -0800 (PST) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 99EDB28C134 for ; Mon, 10 Jan 2011 03:28:47 -0800 (PST) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1PcFxW-0000GG-TC for idr@ietf.org; Mon, 10 Jan 2011 11:30:46 +0000 Message-ID: <4D2AEDE6.9060802@uk.clara.net> Date: Mon, 10 Jan 2011 11:30:46 +0000 From: David Freedman Organization: Claranet Limited User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: idr X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACL-Warn: Message has been frozen because it contains sensitive words (ietf.org), please unfreeze it manually Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 11:28:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (apologies in advance for duplicates) Ilya Varlashkin wrote: > > Jakob, > > > > very valid points. Please see comments below. > > >> >> "deprecate" is too wussy. It does nothing. >> >> We need a recommendation of what to do when we receive one. >> >> Suggestions: >> >> 1. Replace the AS-SET with the AS number of the sending speaker > > > > what if AS-SET is not the last element of the AS-PATH? e.g. an announcement went through some routers which don't yet know that AS-SET has been depricated? doesn't sound like a good idea > > >> >> 2. Replace the AS-SET with a special ASN that means "there was an AS-SET here" > > > > this appeals to me as the best possible solution. While removing AS-SET we should probably also remove AGGREGATOR and ATOMIC_AGGREGATE. IANA section should be updated then and we need early allocation ASAP. > > >> >> 3. drop the AS-SET Well, just thinking about dropping it, its used heavily in aggregation, meaning we should probably remove at least ATOMIC_AGGREGATE in this case (any valid use cases these days?) Also the tie breaking algorithm (4271 9.1.2.2), "Remove from consideration all routes that are not tied for having the smallest number of AS numbers present in their AS_PATH attributes. Note that when counting this number, an AS_SET counts as 1, no matter how many ASes are in the set." So in this case, we need something in its place else we change tie-breaking behaviour. In short, (2) seems to cause the least disruption, though it is annoying we have to carry this for backward compatibility, even more annoying we have to reserve something for it... Dave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0q7eYACgkQtFWeqpgEZrLuhwCeMO8AenAMAsK1KCuandeYrUQL YyAAn0kBzHugljTZ2HA9j2MtdhDExiGo =IoXq -----END PGP SIGNATURE----- From jakob.heitz@ericsson.com Mon Jan 10 04:32:49 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4E528C134 for ; Mon, 10 Jan 2011 04:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrNc2+2Jw2JT for ; Mon, 10 Jan 2011 04:32:48 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 7373E28C133 for ; Mon, 10 Jan 2011 04:32:48 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0ADBxE5030328; Mon, 10 Jan 2011 07:12:01 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.168]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 10 Jan 2011 07:34:46 -0500 From: Jakob Heitz To: Ilya Varlashkin Date: Mon, 10 Jan 2011 07:34:44 -0500 Thread-Topic: [Idr] Fw: Old transport-layer protocols to Historic? Thread-Index: Acuuo13tOHKNbdOZTPG6ja1+5cqCvwCHcr3g Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B8941A07@EUSAACMS0701.eamcs.ericsson.se> References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> <1D07CAF7-27E1-4463-BF0A-306CAC1FB74E@nobulus.com> In-Reply-To: <1D07CAF7-27E1-4463-BF0A-306CAC1FB74E@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 12:32:49 -0000 For option 1, if AS-SET is not the last element, replace it with the adjacent AS number, the AS number of the AS that created the AS-SET. Anyway, I also like option 2 the best. (I proposed it on 9/21). Reserve a number. It conveys the most information. Default action is normally to retain old behaviour. Adoption of new behaviour should be a concious decision, in case side effects need to be fixed. If there will be no side effects to fix, then the default could be the new behaviour. -- Jakob Heitz. =20 > -----Original Message----- > From: Ilya Varlashkin [mailto:ilya@nobulus.com]=20 > Sent: Friday, January 07, 2011 11:45 AM > To: Jakob Heitz > Cc: t.petch; warren@kumari.net; idr > Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? >=20 > Jakob, >=20 > very valid points. Please see comments below. >=20 > > "deprecate" is too wussy. It does nothing. > > We need a recommendation of what to do when we receive one. > > Suggestions: > > 1. Replace the AS-SET with the AS number of the sending speaker >=20 > what if AS-SET is not the last element of the AS-PATH? e.g.=20 > an announcement went through some routers which don't yet=20 > know that AS-SET has been depricated? doesn't sound like a good idea >=20 > > 2. Replace the AS-SET with a special ASN that means "there=20 > was an AS-SET here" >=20 > this appeals to me as the best possible solution. While=20 > removing AS-SET we should probably also remove AGGREGATOR and=20 > ATOMIC_AGGREGATE. IANA section should be updated then and we=20 > need early allocation ASAP. >=20 > > 3. drop the AS-SET > > 4. drop the route > >=20 > > I don't like 3 and 4. >=20 > me neither >=20 > > The recommended action could be knobbed (optional). > >=20 > and what to do by default? >=20 > Kind regards, > iLya > = From ietfc@btconnect.com Mon Jan 10 07:44:17 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C92C3A67FC for ; Mon, 10 Jan 2011 07:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C29kLeFWc8S for ; Mon, 10 Jan 2011 07:44:16 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 8E55D3A67ED for ; Mon, 10 Jan 2011 07:44:14 -0800 (PST) Received: from host217-44-202-158.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.158]) by c2beaomr10.btconnect.com with SMTP id BGQ26802; Mon, 10 Jan 2011 15:46:25 +0000 (GMT) Message-ID: <01c501cbb0d4$b21ea820$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Jakob Heitz" , References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> Date: Mon, 10 Jan 2011 15:43:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D2B29D0.0112, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4D2B29D2.025D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:44:17 -0000 ----- Original Message ----- From: "Jakob Heitz" To: "t.petch" ; Cc: "idr" Sent: Friday, January 07, 2011 7:58 PM "deprecate" is too wussy. It does nothing. Agree which is why I am pressing for the total removal of section three and will go on pressing for as long as it takes. It is totally, utterly and completely wrong to attempt to redefine deprecate. We need precise specific actions, such as Do not generate any new AS_SET Get rid of those that exist as soon as practicable. I do not think that we should come up with processing different to RFC4271 at this stage, I think that that comes later when the above has been approved. Tom Petch We need a recommendation of what to do when we receive one. Suggestions: 1. Replace the AS-SET with the AS number of the sending speaker 2. Replace the AS-SET with a special ASN that means "there was an AS-SET here" 3. drop the AS-SET 4. drop the route I don't like 3 and 4. The recommended action could be knobbed (optional). -- Jakob Heitz. > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > Behalf Of t.petch > Sent: Friday, January 07, 2011 9:33 AM > To: warren@kumari.net > Cc: idr > Subject: [Idr] Fw: Old transport-layer protocols to Historic? > > Warren > > A propos draft-ietf-idr-deprecate-as-sets-00 > > Deprecate seems to be getting quite an airing at present - there > is a netconf implementor who is questioning it as well - but I am with > Adrian, that what we have works, and is well enough defined and > understood. > > Tom Petch > > ----- Original Message ----- > From: "Andrew Sullivan" > To: > Sent: Friday, January 07, 2011 3:15 PM > Subject: Re: Old transport-layer protocols to Historic? > > > > I'm not keen to start a language war, but. . . > > > > On Fri, Jan 07, 2011 at 08:39:37AM +0200, Mykyta Yevstifeyev wrote: > > > > > Moreover, 'obsoleted' means the same as 'deprecated' or > 'non-current' > > > (see http://www.synonym.com/synonyms/obsolete/ or > > > > http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So > it is a > > > problem in RFC2026. > > > > . . .I fully disagree with that, regardless of what those claims of > > synonymy say. To deprecate something is to express disapproval. To > > mark something as obsolete doesn't do that; it merely says that the > > marked thing is outdated. There is a useful distinction here worth > > maintaining. > > > > A > > > > -- > > Andrew Sullivan > > ajs@shinkuro.com > > Shinkuro, Inc. > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From jgs@juniper.net Mon Jan 10 09:18:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EE33A67FA for ; Mon, 10 Jan 2011 09:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4ZeXqpdQkzs for ; Mon, 10 Jan 2011 09:18:22 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 98C283A67ED for ; Mon, 10 Jan 2011 09:18:22 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTSs/5CjZV37bc4M3zuEl69e0fai2rP6L@postini.com; Mon, 10 Jan 2011 09:20:37 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 10 Jan 2011 09:18:52 -0800 From: John Scudder To: Yakov Rekhter Date: Mon, 10 Jan 2011 09:18:50 -0800 Thread-Topic: [Idr] draft-rekhter-rfc4760bis-01 Thread-Index: Acuw6kMufrLGFkTmSlOr53chwmWTZw== Message-ID: References: <201010061600.o96G0xU80178@magenta.juniper.net> In-Reply-To: <201010061600.o96G0xU80178@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-rekhter-rfc4760bis-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:18:23 -0000 The draft is accepted as a WG item; sorry for the delay in announcing. Ple= ase republish as draft-ietf-idr-rfc4760bis. Thanks. --John On Oct 6, 2010, at 9:00 AM, Yakov Rekhter wrote: > Folks, >=20 > I'd like to ask the IDR WG to accept draft-rekhter-rfc4760bis-01 as > an IDR WG item. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Wed, 06 Oct 2010 08:46:52 -0700 > From: IETF I-D Submission Tool > To: yakov@juniper.net > cc: tbates@cisco.com, rchandra@sonoasystems.com, dkatz@juniper.net > Subject: New Version Notification for draft-rekhter-rfc4760bis-01=20 >=20 >=20 > A new version of I-D, draft-rekhter-rfc4760bis-01.txt has been successful= ly sub > mitted by Yakov Rekhter and posted to the IETF repository. >=20 > Filename: draft-rekhter-rfc4760bis > Revision: 01 > Title: Multiprotocol Extensions for BGP-4 > Creation_date: 2010-10-06 > WG ID: Independent Submission > Number_of_pages: 12 >=20 > Abstract: > This document defines extensions to BGP-4 to enable it to carry > routing information for multiple Network Layer protocols (e.g., IPv6, > IPX, L3VPN, etc...). The extensions are backward compatible - a > router that supports the extensions can interoperate with a router > that doesn't support the extensions. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From Internet-Drafts@ietf.org Mon Jan 10 09:45:07 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52EA3A6AFC; Mon, 10 Jan 2011 09:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+yeCRDcpcXO; Mon, 10 Jan 2011 09:45:06 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9281D3A6B06; Mon, 10 Jan 2011 09:45:06 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110174506.3308.66220.idtracker@localhost> Date: Mon, 10 Jan 2011 09:45:06 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : R. Chandra, et al. Filename : draft-ietf-idr-rfc4760bis-00.txt Pages : 12 Date : 2011-01-10 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-rfc4760bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10093328.I-D@ietf.org> --NextPart-- From ilya@nobulus.com Mon Jan 10 12:07:21 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5BC3A6B39 for ; Mon, 10 Jan 2011 12:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5JcZ3njeu4W for ; Mon, 10 Jan 2011 12:07:21 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id ADB273A6B2E for ; Mon, 10 Jan 2011 12:07:20 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 6472C170EF for ; Mon, 10 Jan 2011 21:09:34 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SksNfFUUHHcm for ; Mon, 10 Jan 2011 21:09:31 +0100 (CET) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 7E4D8170B1 for ; Mon, 10 Jan 2011 21:09:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ilya Varlashkin In-Reply-To: <20110110174506.3308.66220.idtracker@localhost> Date: Mon, 10 Jan 2011 21:09:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AB58CEC-F7F3-427C-A1EC-55B8902BAD16@nobulus.com> References: <20110110174506.3308.66220.idtracker@localhost> To: IETF IDR X-Mailer: Apple Mail (2.1082) Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:07:21 -0000 As I've previously mentioned in private conversation, this draft seem = like a perfect place to address an issue of intermixing various SAFI of = the same AFI. The problem has been discussed here at IDR = ("interoperability of 6PE and native-IPv6 within same network" - = http://www.ietf.org/mail-archive/web/idr/current/msg04364.html). What's = group view on adding something along following line to the draft: if a = route has been learned from AFI=3Dx SAFI=3Dy1, then BGP speaker MAY NOT = advertise it over a SAFI=3Dy2 session unless speaker sets itself as = NEXT_HOP? Kind regards, iLya =20 On Jan 10, 2011, at 18:45 , 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. >=20 >=20 > Title : Multiprotocol Extensions for BGP-4 > Author(s) : R. Chandra, et al. > Filename : draft-ietf-idr-rfc4760bis-00.txt > Pages : 12 > Date : 2011-01-10 >=20 > This document defines extensions to BGP-4 to enable it to carry > routing information for multiple Network Layer protocols (e.g., IPv6, > IPX, L3VPN, etc...). The extensions are backward compatible - a > router that supports the extensions can interoperate with a router > that doesn't support the extensions. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr /iLya From aretana@cisco.com Tue Jan 11 11:14:43 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B633A6A93 for ; Tue, 11 Jan 2011 11:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1MYr84gdPvT for ; Tue, 11 Jan 2011 11:14:41 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8160E3A6AB4 for ; Tue, 11 Jan 2011 11:14:08 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEGALY7LE2tJXHB/2dsb2JhbACWKI4Rc6NtmGiFTASEaIlMggQ Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2011 19:16:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p0BJGPXF012784; Tue, 11 Jan 2011 19:16:25 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jan 2011 13:16:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2011 13:16:20 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F6432042244C0@XMB-RCD-206.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Deprecation of BGP AS_SET, AS_CONFED_SET" MAY nit. Thread-Index: AcuxxAc8bnnp/8vaQ4aY0SJX363fRg== From: "Alvaro Retana (aretana)" To: X-OriginalArrivalTime: 11 Jan 2011 19:16:25.0120 (UTC) FILETIME=[0A175A00:01CBB1C4] Cc: idr@ietf.org Subject: [Idr] "Deprecation of BGP AS_SET, AS_CONFED_SET" MAY nit. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:14:43 -0000 Warren: Hi! How are you? I was just looking at the -01 version of your ID, and I have a small nit. Section 4 (Deplyoment) reads: It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) MAY not support routes with AS_SETs / AS_CONFED_SETs in them, and MAY treat as infeasible routes containing them. "MAY" should be written in lower case. That's it! As I said, small nit. :-) Thanks! Alvaro. From zengqing@huawei.com Wed Jan 12 18:01:10 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE943A67B1 for ; Wed, 12 Jan 2011 18:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+ThPWkb62ZX for ; Wed, 12 Jan 2011 18:01:09 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BAF653A6801 for ; Wed, 12 Jan 2011 18:01:09 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00HIKV1KDW@szxga05-in.huawei.com> for idr@ietf.org; Thu, 13 Jan 2011 10:03:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00HDWV1J2O@szxga05-in.huawei.com> for idr@ietf.org; Thu, 13 Jan 2011 10:03:20 +0800 (CST) Received: from z00129659 ([10.110.98.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX000EPV1JAM@szxml04-in.huawei.com> for idr@ietf.org; Thu, 13 Jan 2011 10:03:19 +0800 (CST) Date: Thu, 13 Jan 2011 10:03:19 +0800 From: zengqing In-reply-to: <20110110174506.3308.66220.idtracker@localhost> To: rchandra@cisco.com, dkatz@juniper.net, yakov@juniper.net Message-id: <002701cbb2c6$0ca04590$25e0d0b0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acuw7p4EOw9xvpL6Q121y5vLclp+bAB0skEw References: <20110110174506.3308.66220.idtracker@localhost> Cc: idr@ietf.org Subject: [Idr] A question about no NLRI. RE: I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 02:01:10 -0000 Hi Tony & Ravi & Dave & Yakov, I have one question about section 10, 10. Comparison with RFC4760 This document explicitly spells out that receiving an UPDATE message that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, with the attribute carrying no NLRI, must not be treated as an error. NLRI is equal to the index of Update information. If no NLRI, should the info be global or network wide? Would you like to tell us what is possible scenarios? Thanks and Regards Qing > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, January 11, 2011 1:45 AM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt > > 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 : Multiprotocol Extensions for BGP-4 > Author(s) : R. Chandra, et al. > Filename : draft-ietf-idr-rfc4760bis-00.txt > Pages : 12 > Date : 2011-01-10 > > This document defines extensions to BGP-4 to enable it to carry routing > information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). > The extensions are backward compatible - a router that supports the > extensions can interoperate with a router that doesn't support the extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From enkechen@cisco.com Wed Jan 12 18:27:38 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B853A680F for ; Wed, 12 Jan 2011 18:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VyEenKc1hrK for ; Wed, 12 Jan 2011 18:27:37 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 656DC3A6801 for ; Wed, 12 Jan 2011 18:27:37 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2011 02:29:58 +0000 Received: from dhcp-171-70-244-144.cisco.com (dhcp-171-70-244-144.cisco.com [171.70.244.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0D2TwAi002583; Thu, 13 Jan 2011 02:29:58 GMT Message-ID: <4D2E63CE.7000608@cisco.com> Date: Wed, 12 Jan 2011 18:30:38 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 MIME-Version: 1.0 To: zengqing References: <20110110174506.3308.66220.idtracker@localhost> <002701cbb2c6$0ca04590$25e0d0b0$@com> In-Reply-To: <002701cbb2c6$0ca04590$25e0d0b0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yakov@juniper.net, rchandra@cisco.com, dkatz@juniper.net, idr@ietf.org Subject: Re: [Idr] A question about no NLRI. RE: I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 02:27:38 -0000 Hi, Qing: Here is an application described in RFC 4724 (Graceful Restart for BGP): ------------------------- 2. Marker for End-of-RIB An UPDATE message with no reachable Network Layer Reachability Information (NLRI) and empty withdrawn NLRI is specified as the End- of-RIB marker that can be used by a BGP speaker to indicate to its peer the completion of the initial routing update after the session is established. For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message with the minimum length [BGP-4]. For any other address family, it is an UPDATE message that contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no withdrawn routes for that . -------------------------- -- Enke On 1/12/11 6:03 PM, zengqing wrote: > Hi Tony& Ravi& Dave& Yakov, > > I have one question about section 10, > 10. Comparison with RFC4760 > This document explicitly spells out that receiving an UPDATE message > that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, with the > attribute carrying no NLRI, must not be treated as an error. > NLRI is equal to the index of Update information. > If no NLRI, should the info be global or network wide? > Would you like to tell us what is possible scenarios? > > Thanks and Regards > Qing > > > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Tuesday, January 11, 2011 1:45 AM >> To: i-d-announce@ietf.org >> Cc: idr@ietf.org >> Subject: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt >> >> 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 : Multiprotocol Extensions for BGP-4 >> Author(s) : R. Chandra, et al. >> Filename : draft-ietf-idr-rfc4760bis-00.txt >> Pages : 12 >> Date : 2011-01-10 >> >> This document defines extensions to BGP-4 to enable it to carry routing >> information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). >> The extensions are backward compatible - a router that supports the >> extensions can interoperate with a router that doesn't support the extensions. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From zengqing@huawei.com Wed Jan 12 19:01:45 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647DD3A6825 for ; Wed, 12 Jan 2011 19:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGKJra98zAMv for ; Wed, 12 Jan 2011 19:01:44 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 081D73A6802 for ; Wed, 12 Jan 2011 19:01:44 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00JFWXUDOX@szxga04-in.huawei.com> for idr@ietf.org; Thu, 13 Jan 2011 11:03:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX001GQXUDM5@szxga04-in.huawei.com> for idr@ietf.org; Thu, 13 Jan 2011 11:03:49 +0800 (CST) Received: from z00129659 ([10.110.98.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00LXLXU9YX@szxml04-in.huawei.com> for idr@ietf.org; Thu, 13 Jan 2011 11:03:49 +0800 (CST) Date: Thu, 13 Jan 2011 11:03:45 +0800 From: zengqing In-reply-to: <4D2E63CE.7000608@cisco.com> To: 'Enke Chen' Message-id: <002801cbb2ce$7f65b490$7e311db0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuyycyKHvvz1mM7Q+GsJU2+ygAN6wAASgng References: <20110110174506.3308.66220.idtracker@localhost> <002701cbb2c6$0ca04590$25e0d0b0$@com> <4D2E63CE.7000608@cisco.com> Cc: yakov@juniper.net, rchandra@cisco.com, dkatz@juniper.net, idr@ietf.org Subject: Re: [Idr] A question about no NLRI. RE: I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 03:01:45 -0000 Hi, Enke: Thanks for your reply, I had known the case of End-of-RIB, and is it the only one possible scenarios? Regards Qing > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Thursday, January 13, 2011 10:31 AM > To: zengqing > Cc: rchandra@cisco.com; dkatz@juniper.net; yakov@juniper.net; idr@ietf.org > Subject: Re: [Idr] A question about no NLRI. RE: I-D > Action:draft-ietf-idr-rfc4760bis-00.txt > > Hi, Qing: > > Here is an application described in RFC 4724 (Graceful Restart for BGP): > > ------------------------- > > 2. Marker for End-of-RIB > > An UPDATE message with no reachable Network Layer Reachability > Information (NLRI) and empty withdrawn NLRI is specified as the End- > of-RIB marker that can be used by a BGP speaker to indicate to its > peer the completion of the initial routing update after the session > is established. For the IPv4 unicast address family, the End-of-RIB > marker is an UPDATE message with the minimum length [BGP-4]. For > any > other address family, it is an UPDATE message that contains only the > MP_UNREACH_NLRI attribute [BGP-MP] with no withdrawn routes for > that > . > -------------------------- > > -- Enke > > > On 1/12/11 6:03 PM, zengqing wrote: > > Hi Tony& Ravi& Dave& Yakov, > > > > I have one question about section 10, > > 10. Comparison with RFC4760 > > This document explicitly spells out that receiving an UPDATE > message > > that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, > with the > > attribute carrying no NLRI, must not be treated as an error. > > NLRI is equal to the index of Update information. > > If no NLRI, should the info be global or network wide? > > Would you like to tell us what is possible scenarios? > > > > Thanks and Regards > > Qing > > > > > > > >> -----Original Message----- > >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > >> Internet-Drafts@ietf.org > >> Sent: Tuesday, January 11, 2011 1:45 AM > >> To: i-d-announce@ietf.org > >> Cc: idr@ietf.org > >> Subject: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt > >> > >> 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 : Multiprotocol Extensions for BGP-4 > >> Author(s) : R. Chandra, et al. > >> Filename : draft-ietf-idr-rfc4760bis-00.txt > >> Pages : 12 > >> Date : 2011-01-10 > >> > >> This document defines extensions to BGP-4 to enable it to carry routing > >> information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, > etc...). > >> The extensions are backward compatible - a router that supports the > >> extensions can interoperate with a router that doesn't support the > extensions. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > From paul@jakma.org Sun Jan 16 04:23:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0AF3A6D3D for ; Sun, 16 Jan 2011 04:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F9If3AMGZ06 for ; Sun, 16 Jan 2011 04:23:01 -0800 (PST) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 0E46A3A6BB0 for ; Sun, 16 Jan 2011 04:23:00 -0800 (PST) Received: from stoner.jakma.org (stoner.jakma.org [81.168.24.42]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p0GCOuEp008517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jan 2011 12:25:02 GMT Date: Sun, 16 Jan 2011 12:24:51 +0000 (GMT) From: Paul Jakma To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) 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 Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 12:23:02 -0000 On Fri, 7 Jan 2011, Jakob Heitz wrote: > "deprecate" is too wussy. It does nothing. > We need a recommendation of what to do when we receive one. > Suggestions: > 1. Replace the AS-SET with the AS number of the sending speaker > 2. Replace the AS-SET with a special ASN that means "there was an AS-SET here" > 3. drop the AS-SET > 4. drop the route Why do any of these? What is the practical good in this, other than satisfying some internal dislike of AS_SETs? If AS_SETs interfere with some other new extension to BGP, let that extension mandate what to do. BGP speakers will vote with their firmware updates, according to the utility of AS_SETs (or lack of) versus that new extension. Let economics and natural progress decide, not artificial prescript to break people's routing. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: If it's worth hacking on well, it's worth hacking on for money. From warren@kumari.net Sun Jan 16 07:25:41 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D883A6D51 for ; Sun, 16 Jan 2011 07:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OqOV95cLuNl for ; Sun, 16 Jan 2011 07:25:39 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 86E3B3A6BD7 for ; Sun, 16 Jan 2011 07:25:39 -0800 (PST) Received: from [192.168.0.150] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 99C812284A11; Sun, 16 Jan 2011 10:28:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari X-Priority: 3 In-Reply-To: <00b301cba848$3490af00$4001a8c0@gateway.2wire.net> Date: Sun, 16 Jan 2011 10:28:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net> References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net> <008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net> <00b301cba848$3490af00$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1081) Cc: idr Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:25:41 -0000 On Dec 30, 2010, at 12:37 PM, t.petch wrote: > Warren >=20 > Top posting on deprecate since that seems the fuzzy issue. >=20 > I also work in network management, and so take for granted statements = such as > " The value "current" means that the definition is current and valid. > The value "obsolete" means the definition is obsolete and should not > be implemented and/or can be removed if previously implemented. > While the value "deprecated" also indicates an obsolete definition, > it permits new/continued implementation in order to foster > interoperability with older/existing implementations." >=20 > from SMIv2 [RFC2578] and which is almost unchanged in YANG [RFC6020] >=20 > "The "status" statement takes as an argument one of the strings > "current", "deprecated", or "obsolete". >=20 > o "current" means that the definition is current and valid. >=20 > o "deprecated" indicates an obsolete definition, but it permits = new/ > continued implementation in order to foster interoperability with > older/existing implementations. >=20 > o "obsolete" means the definition is obsolete and SHOULD NOT be > implemented and/or can be removed from implementations." >=20 > I have always taken this to be IETF-wide so that when RFC4271 uses > 'deprecated' without explanation, everyone knows what is meant. As > such, I would suggest not including any definition thereof. If it is = good enough > for RFC4271, ..... Cool, done! >=20 > But I would still include explicit sentences along the lines of 'do = not generate > any new ones, and stop using existing ones as soon as you can' Version -01 included some strengthened text, but I've just posted -02. Please have a look and let me know if you think this is the correct = strength -- it's basically what you provided, but reworded slightly to = be a little more "formal". W >=20 > Tom Petch >=20 > ps you could include a reference to maidens praying, but that is = probably > too much an SNMP in-joke. >=20 > ----- Original Message ----- > From: "Warren Kumari" > To: "t.petch" > Cc: "Warren Kumari" ; > Sent: Wednesday, December 29, 2010 11:08 PM > Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >=20 >=20 >=20 > On Dec 8, 2010, at 4:16 AM, t.petch wrote: >=20 >> ----- Original Message ----- >> From: "Warren Kumari" >> To: "Warren Kumari" >> Cc: >> Sent: Tuesday, December 07, 2010 6:10 PM >> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >>=20 >>=20 >>> =46rom the lack of slings and arrows, I'm going to have to assume = that this >> document is just *perfect* and cannot be improved at all.... >>>=20 >>> Go, prove me wrong (please?) >>=20 >> Easy peasy >=20 > Doh. I said that I'd get to soon, but, well, I didn't.... Sorry. >=20 >>=20 >> "The reductions ... is outweighed " >=20 > Good catch. Done. >=20 >>=20 >> "Deprecate: To mark ... as obsolete" >> **disagree obsolete and deprecate are quite different and I think = deprecate >> correct here (but see below). >>=20 >=20 > Yes, I agree. This is horrid, but I wasn't able to find a better = definition of > "deprecate" anywhere... > I have spent a while looking at various definitions and have munged a = few of > them together into one :-) > Hopefully this is a reasonable, otherwise, if you happen to be able to = wordsmith > a better one I'd really appreciate it. >=20 >=20 >> "RPKI" >> ** not expanded, explained or referenced, nor mentioned in the = introduction. >=20 > Bah! I didn't want to have the document held up while waiting for > draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed in = "RPKI", > intending to find a good reference before posting it, but then = forgot... >=20 > I have reworded things to avoid using the term RPKI, hopefully this is = still > specific enough. >=20 >> For me, RPKI is the driving force for this I-D - I know of no other = reason for >> it to exist so more is needed here. >=20 > While RPKI is the reason closest to my heart as well, it is not the = only > reason -- AS_SETs have caused both confusion and issues, for example: > http://www.merit.edu/mail.archives/nanog/msg14479.html >=20 > This is (IMO) both because the code is not well exercised and because = the > relevant bits of the RFC are, um, confusing. AS_SETs also seem to = cause > confusion to many operators -- if I see: > *> 192.0.2.0/24 1 12 22 9 6 i > I know exactly who to talk to about issues with 192.0.2.0. If I see: > *> 192.0.2.0/24 1 12 {22 9 6} i > who should I talk to? AS12? AS6? All of them, none of them? >=20 > And what exactly does AS_PATH 3561 3356 9031 {35821,35821,35821,35821} = i mean? > = (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=3Dpost_view_thr= eaded_ >=20 >>=20 >> "simplified.. " >=20 > Done. >=20 >>=20 >> Is there an exposure from systems that will refuse to process AS-SET = when >> receiving one, eg a black hole? I don't know, but think it needs = exploring. >=20 >=20 > If someone is announcing an aggregate containing an AS_SET, and is not > announcing the more specifics as well, then yes, this could happen -- = I have not > been able to find any cases of this though. I guess it is also = possible that a > more specific could go away, and the aggregator may have some backdoor = route to > a contributor, but a: this is getting into the pathological and b: we = are > advising folk to stop generating these anyway :-P >=20 >=20 >>=20 >> And, just what is being recommended? Deprecate is a weasel word and = I think >> needs elucidating ie spell out whatever it is we are recommending. I = take it > as >> do not generate any new AS_SET and look to eliminate any that are = currently >> being generated, but think that that needs saying explicitly. >=20 > Yup, that is it exactly. I have attempted to demustelate it -- I would = like to > make it even stronger[0], but think that this is now explicit enough, = you? >=20 > W >=20 > [0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. Please = stop > announcing them or some chappie with a big bat will come knocking..." >=20 >>=20 >> Tom Petch >>=20 >>>=20 >>> W >>>=20 >>> On Nov 19, 2010, at 11:26 AM, Warren Kumari wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> Now that the submission window has reopened, I have posted >> draft-ietf-idr-deprecate-as-sets-00 (nee = draft-wkumari-deprecate-as_sets). >>>>=20 >>>> This draft already has comment from multiple folk incorporated, but = could >> still do with some work, and hopefully a bit of strengthening of the = language > / >> recommendation. >>>>=20 >>>> Anyway, please take another look (because I'm sure that, having = just gotten >> back from Beijing, reading yet another draft sounds like a barrel of = fun) and >> send comments, or better yet, text :-p >>>>=20 >>>> W >>>>=20 >>>>=20 >>>> ------ >>>> A new version of I-D, draft-ietf-idr-deprecate-as-sets-00.txt has = been >> successfully submitted by Warren Kumari and posted to the IETF = repository. >>>>=20 >>>> Filename: draft-ietf-idr-deprecate-as-sets >>>> Revision: 00 >>>> Title: Deprecation of BGP AS_SET, AS_CONFED_SET. >>>> Creation_date: 2010-11-18 >>>> WG ID: idr >>>> Number_of_pages: 5 >>>>=20 >>>> Abstract: >>>> This document deprecates the use of the AS_SET and AS_CONFED_SET >>>> types of the AS_PATH in BGPv4. This is done to simplify the design >>>> and implementation of the BGP protocol and to make the semantics of >>>> the originator of a route more clear. >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 From warren@kumari.net Sun Jan 16 07:25:41 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36E03A6BD7 for ; Sun, 16 Jan 2011 07:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2xjPW6h-ZJC for ; Sun, 16 Jan 2011 07:25:41 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 1DFF63A6D4C for ; Sun, 16 Jan 2011 07:25:41 -0800 (PST) Received: from [192.168.0.150] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 0D4312284AAE; Sun, 16 Jan 2011 10:28:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <1D23749D4168CC4D8B8652397B5F6432042244C0@XMB-RCD-206.cisco.com> Date: Sun, 16 Jan 2011 10:28:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6C7E300E-104F-405C-ACF5-4C5F71437D06@kumari.net> References: <1D23749D4168CC4D8B8652397B5F6432042244C0@XMB-RCD-206.cisco.com> To: Alvaro Retana (aretana) X-Mailer: Apple Mail (2.1081) Cc: idr@ietf.org Subject: Re: [Idr] "Deprecation of BGP AS_SET, AS_CONFED_SET" MAY nit. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:25:41 -0000 On Jan 11, 2011, at 2:16 PM, Alvaro Retana (aretana) wrote: > Warren: >=20 > Hi! How are you? >=20 > I was just looking at the -01 version of your ID, and I have a small > nit. >=20 > Section 4 (Deplyoment) reads: >=20 > It is worth noting that new technologies (such as those that take > advantage of the "X.509 Extensions for IP Addresses and AS > Identifiers" ([RFC3779]) MAY not support routes with AS_SETs / > AS_CONFED_SETs in them, and MAY treat as infeasible routes = containing > them. >=20 >=20 > "MAY" should be written in lower case. I'm assuming you meant the first "MAY", I *think* the second one is / = should be a big MAY... Thoughts? >=20 > That's it! As I said, small nit. :-) >=20 > Thanks! Nah, thank *you*, W >=20 > Alvaro. From Internet-Drafts@ietf.org Sun Jan 16 07:30:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432753A6D4C; Sun, 16 Jan 2011 07:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHN1A4LyGxqn; Sun, 16 Jan 2011 07:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817353A6D3F; Sun, 16 Jan 2011 07:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110116153001.2372.23828.idtracker@localhost> Date: Sun, 16 Jan 2011 07:30:01 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-deprecate-as-sets-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Deprecation of BGP AS_SET, AS_CONFED_SET. Author(s) : W. Kumari Filename : draft-ietf-idr-deprecate-as-sets-02.txt Pages : 5 Date : 2011-01-16 This document deprecates the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of the BGP protocol and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation and deployment of bonging work in the Secure Inter-Domain Routing Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-deprecate-as-sets-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-16072552.I-D@ietf.org> --NextPart-- From tony.li@tony.li Sun Jan 16 10:31:32 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C533A6DED for ; Sun, 16 Jan 2011 10:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD6mO7-rJcnv for ; Sun, 16 Jan 2011 10:31:31 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id AFA8F3A6DCE for ; Sun, 16 Jan 2011 10:31:31 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id wJTY1f00317dt5G5CJa4uW; Sun, 16 Jan 2011 18:34:04 +0000 Received: from [10.21.79.178] ([128.107.239.233]) by omta13.westchester.pa.mail.comcast.net with comcast id wJZp1f00J52qHCY3ZJZtGv; Sun, 16 Jan 2011 18:34:02 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Sun, 16 Jan 2011 10:33:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> To: Paul Jakma X-Mailer: Apple Mail (2.1082) Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 18:31:32 -0000 On Jan 16, 2011, at 4:24 AM, Paul Jakma wrote: > Let economics and natural progress decide, not artificial prescript to = break people's routing. +1 It seems to me that 'deprecate' suffices. This convince others to stop = adding more AS_SETs. Since we can't reasonably remove the uses that are = in the field, this is the best thing that we can do. Tony From aretana@cisco.com Sun Jan 16 11:06:06 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4D73A6E5D for ; Sun, 16 Jan 2011 11:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z3Jc1BLgpZs for ; Sun, 16 Jan 2011 11:06:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BBCC83A6E06 for ; Sun, 16 Jan 2011 11:06:05 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABrRMk2tJV2c/2dsb2JhbACkanOkMJgIhVAEhHCJWYIG Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 16 Jan 2011 19:08:37 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p0GJ8bVS007018; Sun, 16 Jan 2011 19:08:37 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 13:08:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Jan 2011 13:08:33 -0600 Message-ID: <1D23749D4168CC4D8B8652397B5F6432042CE65D@XMB-RCD-206.cisco.com> In-Reply-To: <6C7E300E-104F-405C-ACF5-4C5F71437D06@kumari.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] "Deprecation of BGP AS_SET, AS_CONFED_SET" MAY nit. Thread-Index: Acu1kgha8stdevh5QCyB0dUZFyIIXgAHe9MQ References: <1D23749D4168CC4D8B8652397B5F6432042244C0@XMB-RCD-206.cisco.com> <6C7E300E-104F-405C-ACF5-4C5F71437D06@kumari.net> From: "Alvaro Retana (aretana)" To: "Warren Kumari" X-OriginalArrivalTime: 16 Jan 2011 19:08:37.0029 (UTC) FILETIME=[C7271550:01CBB5B0] Cc: idr@ietf.org Subject: Re: [Idr] "Deprecation of BGP AS_SET, AS_CONFED_SET" MAY nit. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 19:06:06 -0000 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Sunday, January 16, 2011 10:28 AM Warren: ... > > Section 4 (Deplyoment) reads: > > > > It is worth noting that new technologies (such as those that take > > advantage of the "X.509 Extensions for IP Addresses and AS > > Identifiers" ([RFC3779]) MAY not support routes with AS_SETs / > > AS_CONFED_SETs in them, and MAY treat as infeasible routes > > containing them. > > > > "MAY" should be written in lower case. >=20 > I'm assuming you meant the first "MAY", I *think* the second one is / > should be a big MAY... >=20 > Thoughts? I meant both. The draft is not specifying any requirements for the "new technologies", just an opinion on what may happen...so "MAY" should not be anywhere (even though it's true that those systems *may* threat the routes as unfeasible). Thanks! Alvaro. From ietfc@btconnect.com Mon Jan 17 07:06:36 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E57C28C0EF for ; Mon, 17 Jan 2011 07:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=-1.195, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ebx7w85944kQ for ; Mon, 17 Jan 2011 07:06:35 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id DF5DC28C0D7 for ; Mon, 17 Jan 2011 07:06:33 -0800 (PST) Received: from host86-134-205-117.range86-134.btcentralplus.com (HELO pc6) ([86.134.205.117]) by c2beaomr06.btconnect.com with SMTP id BPN19915; Mon, 17 Jan 2011 15:09:03 +0000 (GMT) Message-ID: <009101cbb64f$9ce954c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Warren Kumari" References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net> <008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net> <00b301cba848$3490af00$4001a8c0@gateway.2wire.net> <9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net> Date: Mon, 17 Jan 2011 14:50:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D345B8E.0008, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4D345B92.012F,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: idr Subject: [Idr] draft-ietf-idr-deprecate-as-sets-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:06:36 -0000 Should this I-D update RFC4271? I first thought 'Yes it does' but then thought some more, that RFC4271 is the protocol and this is how to use the protocol, operations, a grow-ey sort of thing, so it should not. But then I thought, how will anyone know it exists? Having it as an update to RFC4271 would flag to any user of the rfc-index that this is something they should read, so for political rather than technical reasons, it would be good to have it update RFC4271. But then this is Informational so perhaps it can't. Thoughts? Tom Petch From ietfc@btconnect.com Mon Jan 17 07:06:36 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29A728C0D7 for ; Mon, 17 Jan 2011 07:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqv-f-sgxxqz for ; Mon, 17 Jan 2011 07:06:35 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id DF72A28C0DF for ; Mon, 17 Jan 2011 07:06:34 -0800 (PST) Received: from host86-134-205-117.range86-134.btcentralplus.com (HELO pc6) ([86.134.205.117]) by c2beaomr06.btconnect.com with SMTP id BPN19921; Mon, 17 Jan 2011 15:09:03 +0000 (GMT) Message-ID: <009201cbb64f$9da1f660$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Warren Kumari" References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net> <008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net> <00b301cba848$3490af00$4001a8c0@gateway.2wire.net> <9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net> Date: Mon, 17 Jan 2011 14:55:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D345B8E.0008, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D345B93.01F7,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: idr Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:06:37 -0000 Looks good to me. I thought briefly that the language ought to be SHOULD or MUST but then realised that this I-D is INFORMATIONAL so that those would not really be appropriate. Tom Petch ----- Original Message ----- From: "Warren Kumari" To: "t.petch" Cc: "Warren Kumari" ; "idr" Sent: Sunday, January 16, 2011 4:28 PM Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 On Dec 30, 2010, at 12:37 PM, t.petch wrote: > Warren > > Top posting on deprecate since that seems the fuzzy issue. > > I also work in network management, and so take for granted statements such as > " The value "current" means that the definition is current and valid. > The value "obsolete" means the definition is obsolete and should not > be implemented and/or can be removed if previously implemented. > While the value "deprecated" also indicates an obsolete definition, > it permits new/continued implementation in order to foster > interoperability with older/existing implementations." > > from SMIv2 [RFC2578] and which is almost unchanged in YANG [RFC6020] > > "The "status" statement takes as an argument one of the strings > "current", "deprecated", or "obsolete". > > o "current" means that the definition is current and valid. > > o "deprecated" indicates an obsolete definition, but it permits new/ > continued implementation in order to foster interoperability with > older/existing implementations. > > o "obsolete" means the definition is obsolete and SHOULD NOT be > implemented and/or can be removed from implementations." > > I have always taken this to be IETF-wide so that when RFC4271 uses > 'deprecated' without explanation, everyone knows what is meant. As > such, I would suggest not including any definition thereof. If it is good enough > for RFC4271, ..... Cool, done! > > But I would still include explicit sentences along the lines of 'do not generate > any new ones, and stop using existing ones as soon as you can' Version -01 included some strengthened text, but I've just posted -02. Please have a look and let me know if you think this is the correct strength -- it's basically what you provided, but reworded slightly to be a little more "formal". W > > Tom Petch > > ps you could include a reference to maidens praying, but that is probably > too much an SNMP in-joke. > > ----- Original Message ----- > From: "Warren Kumari" > To: "t.petch" > Cc: "Warren Kumari" ; > Sent: Wednesday, December 29, 2010 11:08 PM > Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > > On Dec 8, 2010, at 4:16 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Warren Kumari" >> To: "Warren Kumari" >> Cc: >> Sent: Tuesday, December 07, 2010 6:10 PM >> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >> >> >>> From the lack of slings and arrows, I'm going to have to assume that this >> document is just *perfect* and cannot be improved at all.... >>> >>> Go, prove me wrong (please?) >> >> Easy peasy > > Doh. I said that I'd get to soon, but, well, I didn't.... Sorry. >> >> "The reductions ... is outweighed " > > Good catch. Done. >> >> "Deprecate: To mark ... as obsolete" >> **disagree obsolete and deprecate are quite different and I think deprecate >> correct here (but see below). >> > > Yes, I agree. This is horrid, but I wasn't able to find a better definition of > "deprecate" anywhere... > I have spent a while looking at various definitions and have munged a few of > them together into one :-) > Hopefully this is a reasonable, otherwise, if you happen to be able to wordsmith > a better one I'd really appreciate it. > > >> "RPKI" >> ** not expanded, explained or referenced, nor mentioned in the introduction. > > Bah! I didn't want to have the document held up while waiting for > draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed in "RPKI", > intending to find a good reference before posting it, but then forgot... > > I have reworded things to avoid using the term RPKI, hopefully this is still > specific enough. > >> For me, RPKI is the driving force for this I-D - I know of no other reason for >> it to exist so more is needed here. > > While RPKI is the reason closest to my heart as well, it is not the only > reason -- AS_SETs have caused both confusion and issues, for example: > http://www.merit.edu/mail.archives/nanog/msg14479.html > > This is (IMO) both because the code is not well exercised and because the > relevant bits of the RFC are, um, confusing. AS_SETs also seem to cause > confusion to many operators -- if I see: > *> 192.0.2.0/24 1 12 22 9 6 i > I know exactly who to talk to about issues with 192.0.2.0. If I see: > *> 192.0.2.0/24 1 12 {22 9 6} i > who should I talk to? AS12? AS6? All of them, none of them? > > And what exactly does AS_PATH 3561 3356 9031 {35821,35821,35821,35821} i mean? > (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_ > >> >> "simplified.. " > > Done. > >> >> Is there an exposure from systems that will refuse to process AS-SET when >> receiving one, eg a black hole? I don't know, but think it needs exploring. > > > If someone is announcing an aggregate containing an AS_SET, and is not > announcing the more specifics as well, then yes, this could happen -- I have not > been able to find any cases of this though. I guess it is also possible that a > more specific could go away, and the aggregator may have some backdoor route to > a contributor, but a: this is getting into the pathological and b: we are > advising folk to stop generating these anyway :-P > > >> >> And, just what is being recommended? Deprecate is a weasel word and I think >> needs elucidating ie spell out whatever it is we are recommending. I take it > as >> do not generate any new AS_SET and look to eliminate any that are currently >> being generated, but think that that needs saying explicitly. > > Yup, that is it exactly. I have attempted to demustelate it -- I would like to > make it even stronger[0], but think that this is now explicit enough, you? > > W > > [0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. Please stop > announcing them or some chappie with a big bat will come knocking..." > >> Tom Petch From Internet-Drafts@ietf.org Mon Jan 17 13:15:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1AC28C162; Mon, 17 Jan 2011 13:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XocImKmIOnS; Mon, 17 Jan 2011 13:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC8A3A6EDA; Mon, 17 Jan 2011 13:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110117211501.4069.16020.idtracker@localhost> Date: Mon, 17 Jan 2011 13:15:01 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp4-mibv2-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version Author(s) : J. Haas Filename : draft-ietf-idr-bgp4-mibv2-11.txt Pages : 45 Date : 2011-01-17 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mibv2-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-17130921.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Jan 17 13:15:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824B63A6E15; Mon, 17 Jan 2011 13:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.209 X-Spam-Level: X-Spam-Status: No, score=-102.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ec0Zk7hL8y7; Mon, 17 Jan 2011 13:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DAA3A6EF5; Mon, 17 Jan 2011 13:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110117211501.4069.67474.idtracker@localhost> Date: Mon, 17 Jan 2011 13:15:01 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp4-mibv2-tc-mib-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-02.txt Pages : 6 Date : 2011-01-17 This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mibv2-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-17130927.I-D@ietf.org> --NextPart-- From jhaas@slice.pfrc.org Mon Jan 17 13:41:38 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9A53A6F61 for ; Mon, 17 Jan 2011 13:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgTkWZxOqTyc for ; Mon, 17 Jan 2011 13:41:38 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id E923C3A6DBA for ; Mon, 17 Jan 2011 13:41:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2E1A4224111; Mon, 17 Jan 2011 21:44:13 +0000 (UTC) Date: Mon, 17 Jan 2011 21:44:13 +0000 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20110117214413.GA15770@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Idr] BGP MIB refreshes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:41:38 -0000 I've refreshed the BGPv2 MIBs. The only changes are: - Updated the TC MIB to address new nits pointed out by the tool. This included updating RFC 3410 to be Informative rather than Normative. - Update my affiliation. - And of course the random changes that upgrading from one version of xml2rfc will give you. -- Jeff ----- Forwarded message from Internet-Drafts@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 : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version Author(s) : J. Haas Filename : draft-ietf-idr-bgp4-mibv2-11.txt Pages : 45 Date : 2011-01-17 --- 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 : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-02.txt Pages : 6 Date : 2011-01-17 -- Jeff From paul@jakma.org Tue Jan 18 01:37:09 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192C53A6DAA for ; Tue, 18 Jan 2011 01:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5flh7EH0wF3 for ; Tue, 18 Jan 2011 01:37:07 -0800 (PST) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id 58C323A6E7C for ; Tue, 18 Jan 2011 01:37:07 -0800 (PST) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p0I9d6Cs006413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 09:39:14 GMT Date: Tue, 18 Jan 2011 09:39:03 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Tony Li In-Reply-To: Message-ID: References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) 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 Cc: idr Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 09:37:09 -0000 On Sun, 16 Jan 2011, Tony Li wrote: > stop adding more AS_SETs. Since we can't reasonably remove the > uses that are in the field, this is the best thing that we can do. Also, AS_SET may still be useful in the future to allow future routing schemes to provide a transitional compatibility-interface to (then) legacy BGP-4 speakers. E.g. hierarchical routing schemes. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Misfortune, n.: The kind of fortune that never misses. -- Ambrose Bierce, "The Devil's Dictionary" From ilya@nobulus.com Tue Jan 18 11:42:37 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D00A3A6F05 for ; Tue, 18 Jan 2011 11:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0-PYgEcAg2i for ; Tue, 18 Jan 2011 11:42:36 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 7AD193A6E98 for ; Tue, 18 Jan 2011 11:42:35 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 8719B17173; Tue, 18 Jan 2011 20:45:12 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LDhgo7s81GwJ; Tue, 18 Jan 2011 20:45:10 +0100 (CET) Received: from [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684] (unknown [IPv6:2001:6f8:893:ffff:225:4bff:fea6:3684]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 740C617133; Tue, 18 Jan 2011 20:45:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ilya Varlashkin In-Reply-To: Date: Tue, 18 Jan 2011 20:45:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E97A131-D4AB-48F4-84FD-3B2E77A89290@nobulus.com> References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> To: Paul Jakma X-Mailer: Apple Mail (2.1082) Cc: idr , Tony Li Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:42:37 -0000 On Jan 18, 2011, at 10:39 , Paul Jakma wrote: > On Sun, 16 Jan 2011, Tony Li wrote: >=20 >> stop adding more AS_SETs. Since we can't reasonably remove the uses = that are in the field, this is the best thing that we can do. >=20 > Also, AS_SET may still be useful in the future to allow future routing = schemes to provide a transitional compatibility-interface to (then) = legacy BGP-4 speakers. E.g. hierarchical routing schemes. >=20 isn't current discussion exactly about how to interact with legacy BGP = speakers? if our idea is to move towards verified (signed) routes, which = do not support AS_SET then I believe it's appropriate to discuss what to = do with existing AS_SETs that eventually will reach a router that wants = to use route verification. And since it's important to fit new = functionality into BGP best path selection process, then options = suggested by Jakob are possible ways to go. As regards to whether AS_SETs will find use in the future. If they = haven't found much use in the past, then either problem was not very = severe one or AS_SETs were wrong solution. And keeping them as a = solution for a problem we haven't yet found doesn't seem to be proper. = Somewhere in the beginning of this thread there was a post regarding = presence of AS_SETs in the current global table and it looked like = AS_SET's can go. So we're back to the question what new BGP speakers = should do when they encounter AS_SET. Kind regards, iLya From john@jlc.net Tue Jan 18 13:24:50 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643843A6BFC for ; Tue, 18 Jan 2011 13:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2XTyoFC8uYJ for ; Tue, 18 Jan 2011 13:24:49 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id C18823A6F51 for ; Tue, 18 Jan 2011 13:24:43 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4418233C46; Tue, 18 Jan 2011 16:27:22 -0500 (EST) Date: Tue, 18 Jan 2011 16:27:22 -0500 From: John Leslie To: Ilya Varlashkin Message-ID: <20110118212722.GD68297@verdi> References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> <7E97A131-D4AB-48F4-84FD-3B2E77A89290@nobulus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E97A131-D4AB-48F4-84FD-3B2E77A89290@nobulus.com> User-Agent: Mutt/1.4.1i Cc: idr , Paul Jakma Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:24:50 -0000 Ilya Varlashkin wrote: > On Jan 18, 2011, at 10:39 , Paul Jakma wrote: >> On Sun, 16 Jan 2011, Tony Li wrote: >> >>> stop adding more AS_SETs. Since we can't reasonably remove the uses >>> that are in the field, this is the best thing that we can do. >> >> Also, AS_SET may still be useful in the future to allow future routing >> schemes to provide a transitional compatibility-interface to (then) >> legacy BGP-4 speakers. E.g. hierarchical routing schemes. Hierarchical Routing is considered essential to IPv6 -- we just keep claiming it will "happen automatically". I wouldn't mind keeping some options alive... > isn't current discussion exactly about how to interact with legacy > BGP speakers? I'm not sure I understand where everyone is coming from... Clearly we're having a discussion about what to do when we receive NLRI containing AS_SET and want to be sure we don't propagate anything with AS_SET. This is a good discussion; but not everybody worries about whether they propagate an AS_SET. > if our idea is to move towards verified (signed) routes, which do not > support AS_SET then I believe it's appropriate to discuss what to do > with existing AS_SETs that eventually will reach a router that wants > to use route verification. With that "eventually" in there, I don't think I want to do anything. Perhaps if I were signing something, I would, but most of us operators aren't worrying about "signing", just worrying about "verifying". > And since it's important to fit new functionality into BGP best path > selection process, then options suggested by Jakob are possible ways > to go. Hmm... I really should bite my tongue instead of saying this... BGP, IMHO, has suffered long from defining algorithms instead of defining meaning of bits on the wire. That horse has long left the barn: not all BGP speakers use exactly the same algorithms. :^( IMHO, verification is doomed unless we define _meaning_ rather than pretend everyone's running identical best-path-selection algorithms. > As regards to whether AS_SETs will find use in the future. If they > haven't found much use in the past, then either problem was not very > severe one or AS_SETs were wrong solution. This is a relatively convincing argument; but I'm not certain that the problems we encounter next year will be the same problems we faced ten years ago. (In particular, hierarchical routing is a new animal.) > And keeping them as a solution for a problem we haven't yet found > doesn't seem to be proper. "Deprecate", to me, pretty much excludes "keeping them as a solution." > Somewhere in the beginning of this thread there was a post regarding > presence of AS_SETs in the current global table and it looked like > AS_SET's can go. Indeed, it looks as if signing/verifying can safely exclude them. > So we're back to the question what new BGP speakers should do when > they encounter AS_SET. What means "new BGP speakers"? Terms like that make me nervous... (I gag whenever the phrase "Flag Day" threatens to surface...) -- John Leslie From Internet-Drafts@ietf.org Tue Jan 18 14:45:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5913D28C116; Tue, 18 Jan 2011 14:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47VxslYp7mVO; Tue, 18 Jan 2011 14:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CADD28C11D; Tue, 18 Jan 2011 14:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118224501.27820.85779.idtracker@localhost> Date: Tue, 18 Jan 2011 14:45:01 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-identifier-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : AS-wide Unique BGP Identifier for BGP-4 Author(s) : E. Chen, J. Yuan Filename : draft-ietf-idr-bgp-identifier-13.txt Pages : 5 Date : 2011-01-18 To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp-identifier-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18144014.I-D@ietf.org> --NextPart-- From jhaas@slice.pfrc.org Wed Jan 19 08:08:44 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF4E28C0EE for ; Wed, 19 Jan 2011 08:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.033 X-Spam-Level: X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyhQn7Fu2OVI for ; Wed, 19 Jan 2011 08:08:43 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 20A4528B56A for ; Wed, 19 Jan 2011 08:08:43 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6DE9B134001; Wed, 19 Jan 2011 16:11:23 +0000 (UTC) Date: Wed, 19 Jan 2011 16:11:23 +0000 From: Jeffrey Haas To: John Leslie Message-ID: <20110119161123.GD15770@slice> References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> <7E97A131-D4AB-48F4-84FD-3B2E77A89290@nobulus.com> <20110118212722.GD68297@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110118212722.GD68297@verdi> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: idr , Paul Jakma Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 16:08:44 -0000 On Tue, Jan 18, 2011 at 04:27:22PM -0500, John Leslie wrote: > Hmm... I really should bite my tongue instead of saying this... > > BGP, IMHO, has suffered long from defining algorithms instead of > defining meaning of bits on the wire. > > That horse has long left the barn: not all BGP speakers use exactly > the same algorithms. :^( > > IMHO, verification is doomed unless we define _meaning_ rather than > pretend everyone's running identical best-path-selection algorithms. If people weren't running compatible enough best path selection, their networks would be doomed to inconsistent forwarding. It's the very fact that consistent route selection is needed throughout an AS that's kept intra-AS features in a certain level of stalemate over the years. The same is true to a lesser extent in inter-domain BGP. Incremental deployment of a feature requires consistent enough routing between ASes that use a feature in order to not introduce routing inconsistencies on an inter-AS basis. Lest we spend too much time arguing about this, you might want to go back and review any given new feature du jour and note where it was killed by the incremental deployment issue. :-) FWIW, I have pretty much always been of the opinion that BGP is all about *policy*. At best, you get default useful route selection from the base path selection mechanism. To get something operationally useful, you spend most of your time tweaking policies. If you're lucky, those policies do something useful. Also FWIW, with regard to SIDR style route validation, it should just leave AS_SET alone if it wants to. I made the observation on the SIDR list and at the Maastricht IETF that if we want *origin* validation to work, we can still accommodate that with the documented hack presented at that IETF *or* through the use of complex aggregation should sets prove to be necessary. Thus if you care about origin validation, you can just ignore that reachability. Providers sending you those routes would not care if you send them that traffic anyway. If they did, they wouldn't use sets. Problem solved - people voted with their route selection as they always do. For *path* validation, sets are doomed from the start. > This is a relatively convincing argument; but I'm not certain that > the problems we encounter next year will be the same problems we faced > ten years ago. (In particular, hierarchical routing is a new animal.) Also a non-issue if you consider the AS4 space. In cases where you need a set of providers to be represented as an aggregate forwarding entity, just assign a given equivalence class set of such providers a new ASN from the AS4 space. The feature roughly looks like confederations. Protocol problem solved - implementation spec, not so much. :-) (And the implementation would probably look like an AS_SET or the confederation version of the same. Much like when confederations go to advertise their confed ASes, the set is stripped and replaced by the equivalence class ASN. Within this super-confederation, validation isn't done on the local components.) -- Jeff From paul@jakma.org Fri Jan 21 01:48:05 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFB63A6906 for ; Fri, 21 Jan 2011 01:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFLCGT3ZYHOB for ; Fri, 21 Jan 2011 01:48:04 -0800 (PST) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by core3.amsl.com (Postfix) with ESMTP id F3CBA3A68F0 for ; Fri, 21 Jan 2011 01:48:03 -0800 (PST) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk [130.209.244.4]) (authenticated bits=0) by hibernia.jakma.org (8.14.4/8.14.3) with ESMTP id p0L9oBQq007148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 09:50:19 GMT Date: Fri, 21 Jan 2011 09:50:07 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Ilya Varlashkin In-Reply-To: <7E97A131-D4AB-48F4-84FD-3B2E77A89290@nobulus.com> Message-ID: References: <020801cbae90$fc2507c0$4001a8c0@gateway.2wire.net> <7309FCBCAE981B43ABBE69B31C8D213909B89416DE@EUSAACMS0701.eamcs.ericsson.se> <7E97A131-D4AB-48F4-84FD-3B2E77A89290@nobulus.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) 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 Cc: idr , Tony Li Subject: Re: [Idr] Fw: Old transport-layer protocols to Historic? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 09:48:05 -0000 On Tue, 18 Jan 2011, Ilya Varlashkin wrote: > As regards to whether AS_SETs will find use in the future. If they > haven't found much use in the past, then either problem was not > very severe one or AS_SETs were wrong solution. There are two aspects here: 1. Generation of AS_SETs. Deprecating AS_SETS to as to discourage generation is grand, as aggregation has proven impractical in the current scheme of things and is generally little used. Plus it simplifies SIDR, which is trying to find a way to secure the current scheme of things. 2. Comprehension of AS_SETs This, I argue, should be retained. Retaining comprehension need not undermine extensions to BGP that do not wish to support AS_SETs - those extensions will need to specify what to do for AS_SETs anyway, for the foreseeable future (e.g. drop the UPDATE, whatever). If speakers want to run those extensions and ignore AS_SETs as part of that, that's perfectly fine. Retaining comprehension may be useful in the future. AS_SETs remain the only way to communicate "the path goes through these ASes" in BGP without affecting the routing metric. This is, completely independent of BGP aggregation, a potentially useful comprehension ability to retain in BGP speakers. For one day we may wish to interface some new routing scheme (potentially quite different from BGP, or an extension of it) with older routers in some transition period. I.e. the ability for BGP speakers to disable extensions and return to understanding some universal base language for exchanging routing information is important. It's an important feature for compatibility, which is important to allow incremental progress. Lobotomising speakers and reducing or, worse, risking the fragmention of that base, universal language they collectively understand could bite us in the future, is my worry. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: "Have you lived here all your life?" "Oh, twice that long." From david.freedman@uk.clara.net Mon Jan 24 07:55:01 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA873A6AF0 for ; Mon, 24 Jan 2011 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHcqNTI4oWJM for ; Mon, 24 Jan 2011 07:55:00 -0800 (PST) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 207AF3A6AC3 for ; Mon, 24 Jan 2011 07:54:59 -0800 (PST) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1PhOnJ-0005QN-Mw for idr@ietf.org; Mon, 24 Jan 2011 15:57:29 +0000 Message-ID: <4D3DA169.5050809@uk.clara.net> Date: Mon, 24 Jan 2011 15:57:29 +0000 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: idr References: <20110118224501.27820.85779.idtracker@localhost> In-Reply-To: <20110118224501.27820.85779.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACL-Warn: Message has been frozen because it contains sensitive words (ietf.org), please unfreeze it manually Subject: Re: [Idr] I-D Action:draft-ietf-idr-bgp-identifier-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:55:01 -0000 Has any thought been given to how confusing a duplicate originator could look in an implementation's cli output when the identifier of the originator is printed in a prefix's diganostic output? Perhaps advise implementers to use combination of the AS number and identifier for display? -- David Freedman Group Network Engineering Claranet Group From ilya@nobulus.com Mon Jan 24 08:08:29 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCCC3A6AC3 for ; Mon, 24 Jan 2011 08:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWfCW7PNwGr3 for ; Mon, 24 Jan 2011 08:08:28 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 2C7C53A6AFA for ; Mon, 24 Jan 2011 08:08:28 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 6616817133 for ; Mon, 24 Jan 2011 17:11:22 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gxRdtb1MDKag for ; Mon, 24 Jan 2011 17:11:19 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:61c0:353d:98d:fbf4]) by nobulus.com (Postfix) with ESMTPA id 79CE4170C1 for ; Mon, 24 Jan 2011 17:11:19 +0100 (CET) Message-ID: <8976B80F40354A008CB7CE38F34F6BCA@hnivarlas1> From: "iLya" To: Date: Mon, 24 Jan 2011 17:11:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Subject: [Idr] Fw: New Version Notification for draft-varlashkin-bgp-nh-cost-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 16:08:29 -0000 Hello, at IETF-79 presentation of "Optimal Route Reflection" (by Robert) also included couple slides on exchanging next-hop cost information within BGP itself. Due to submission freeze those bits of info were not included in the draft. Now we have published it separately. Your comments will be appreciated. Kind regards, iLya -------------------------------------------------- From: "IETF I-D Submission Tool" Sent: Monday, January 24, 2011 2:14 PM To: Cc: Subject: New Version Notification for draft-varlashkin-bgp-nh-cost-00 > > A new version of I-D, draft-varlashkin-bgp-nh-cost-00.txt has been > successfully submitted by Ilya Varlashkin and posted to the IETF > repository. > > Filename: draft-varlashkin-bgp-nh-cost > Revision: 00 > Title: Carrying next-hop cost information in BGP > Creation_date: 2011-01-24 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > This document describes new BGP SAFI to exchange cost information to > next-hops for the purpose of calculating best path from a peer > perspective rather than local BGP speaker own perspective. > > > > The IETF Secretariat. > > > From jyy_99@yahoo.com Sun Jan 30 08:12:38 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB853A6AE4 for ; Sun, 30 Jan 2011 08:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.22 X-Spam-Level: ** X-Spam-Status: No, score=2.22 tagged_above=-999 required=5 tests=[BAYES_50=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eft4DFNmMQjT for ; Sun, 30 Jan 2011 08:12:38 -0800 (PST) Received: from web121805.mail.ne1.yahoo.com (web121805.mail.ne1.yahoo.com [98.138.90.135]) by core3.amsl.com (Postfix) with SMTP id EF9F83A6AAA for ; Sun, 30 Jan 2011 08:12:37 -0800 (PST) Received: (qmail 44811 invoked by uid 60001); 30 Jan 2011 16:15:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296404146; bh=Ln9vdO3aJXHXm7YAsh7MvK4KkXfggTWcKwvxlKx279w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=vuLahKnBHEL+0I4YihjmipLOxCUIe8MqZSP5gk1b5jXPrDrPn1xiO0EFUovDPobJz7DdMUr6Yq+k6unvroI1hf3S4VkaqRVrIMiLW6KnUn9CE2ISR0Q03BcuYgl//eJcIKBTMbJ6YzUgoyjYsaPTJAWZ1yvH/Hfeuf01vh532eg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=hGiNHA/LH36LEFtwka+Z64oRNMDUR/Ah4KEjf1u7+zPVSJAx5REVZFSpYKVbsctwF7EfuWL8ABXfrwgbeaLmK2/tsWyygM2SK2a9GyC9BcVjA9s+PnW8/NFch5+KqIAZ6XFnMcug7BhfZTIBIx9SpDBdc4lMJ5ZFVJfZDJshRjc=; Message-ID: <652565.44720.qm@web121805.mail.ne1.yahoo.com> X-YMail-OSG: 3wN85_AVM1mMWOV.5PKovfZqSMT3RASrHBrOI8M34AAKH.M AugEMlkW2jwlCU2bQz8IoS1ajDA4lyu2oJiPaZrBnOqDLAiSRc5QlWzrW7JQ PR2198sauFDnmoNLsSkav9MHFpc8.LuKfq5N2E1vwnIKw_hJsDGLfYdaTnJJ XsjU5akSgalD9q41eRGPDAtvhO2nrVa_cYF6j6xcVC9GoWhhHw3.M0ypScn. GfdAXkbTb1TC8J8JubU.R18MReTajYkbNDmv_DqwmLAKX3ddMIirnKD4zyf8 8mKvAtZOP86HOPoQdDeUVUh2jTgzgrX5qxKi8NX6MquGf58o.Y7MTrsWcM_k .x_T6.im9g9ZFz19biPBh3fhC_2DBVUkN5.avIlOClfFHK7uUCs6RATwKVdS L1.fepU3Vwdvb6Cau1HE8R6Fydn_.9Yeq3RhyuX0bGaTMXIboFO7JC8Yh9cb K6ArtgA1wllsZ8lB6Lpgx4Q3dbvQ5H.wL_1cHL91Dqd.3oH_1 Received: from [74.243.21.39] by web121805.mail.ne1.yahoo.com via HTTP; Sun, 30 Jan 2011 08:15:46 PST X-Mailer: YahooMailWebService/0.8.107.285259 Date: Sun, 30 Jan 2011 08:15:46 -0800 (PST) From: Jessica Yu To: huanliu@asu.edu, huan.liu@asu.edu, huichen1823@yahoo.com, ymhui@scmp.com, hyang@uci.edu, iab@ietf.org, idezyn@cox.net, idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Idr] holla X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 16:12:38 -0000 you need medication? http://antorchaplanet.com/sales.html