From shane@castlepoint.net Sat Dec 1 08:38:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8771821F8BE5 for ; Sat, 1 Dec 2012 08:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFFqV1box37X for ; Sat, 1 Dec 2012 08:38:55 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id ADD8B21F8640 for ; Sat, 1 Dec 2012 08:38:34 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 625BF2399 for ; Sat, 1 Dec 2012 16:38:34 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B67E62387; Sat, 1 Dec 2012 09:38:33 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Sat, 1 Dec 2012 09:38:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17B0E950-A275-401A-BD05-D1DEC05845D5@castlepoint.net> References: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> To: John G. Scudder X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Dec 1 09:38:34 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50ba328a199633310621106 X-DSPAM-Factors: 27, Extended+#+#+#+forcing, 0.40000, if+#+have, 0.40000, especially+#+in, 0.40000, palatable+#+me, 0.40000, Obviously+#+#+#+would, 0.40000, The+#+hacks, 0.40000, if+#+#+an, 0.40000, if+#+#+an, 0.40000, really+#+#+If, 0.40000, X+year, 0.40000, draft+Not, 0.40000, Chandra+#+chandra, 0.40000, draft+#+#+#+this, 0.40000, appear+#+#+#+not, 0.40000, if+#+became, 0.40000, have+#+#+#+the, 0.40000, even+#+private, 0.40000, The+#+#+to, 0.40000, speaking+#+#+#+encourage, 0.40000, justification+#+#+by, 0.40000, an+#+#+the, 0.40000, figure+the, 0.40000, of+#+bottle, 0.40000, Private+#+#+squat, 0.40000, of+#+anycast, 0.40000, the+#+I, 0.40000, I+#+#+private, 0.40000 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 16:38:55 -0000 On Nov 30, 2012, at 12:22 PM, John G. Scudder wrote: > On Nov 30, 2012, at 12:34 PM, Chandra Appanna = wrote: >=20 >> I figure the chairs might want to hear from some of us who are = reading but silent so far.. >=20 > Indeed. Thanks for speaking up and I encourage others to do the same = if you have an opinion on the subject. FWIW, I support advancing/publishing this document. While I personally find private ASN's distasteful and I try to avoid = them whenever possible (especially/even in private network contexts), = the facts of the matter are: 1) The genie is already out of the bottle with the existing range of = private ASN's (64512 - 65534). 2) The, , "hacks" to deal with them are already in code and would, = hopefully, just need a trivial modification to recognize the new range. 3) We operators already have methods of filtering private ASN's and = those filters should also require trivial _one-time_ modifications, = shortly after this is published. And, at the end of the day, I would much rather see that the IETF adopt = a standard range of "Extended, Private ASN's" than forcing operators who = need a large set of Private ASN's to squat on legitimate space. That = would that create a mess. -shane P.S. -- Frankly, for folks who don't support this proposal I'd say this = is really about economics. If RIR's supported a model of leasing ASN's = in bulk, e.g.: N x 10,000 4-Byte ASN's for $X/year, (where $X was an = extremely small fraction of: N ASN's x $500/ASN) for the whole block. = Obviously such bulk allocations would require needs based justification, = as defined by RIR policies. If such a proposal were to be adopted, it = would /potentially/ *also* make it more palatable to anycast operators = on the Internet to use a globally unique ASN per anycast instance/node, = for reasons outlined in this draft: http://tools.ietf.org/html/draft-mcpherson-unique-origin-as-00 (Not sure if this became an RFC). IMO, this course of action would be a = much more palatable to me, because it would address the needs of both = anycast operators and DataCenters/Enterprises. =20 All this really begs the question: when will we recognize that = numbers are not a precious commodity, especially ASN's that only appear = in the RIB, not the FIB?= From gih@apnic.net Sat Dec 1 12:40:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357EE21F8673 for ; Sat, 1 Dec 2012 12:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asH8JeK+jaLU for ; Sat, 1 Dec 2012 12:40:00 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 813FD21F85B1 for ; Sat, 1 Dec 2012 12:40:00 -0800 (PST) Received: from dhcp148.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1C3C8B6745; Sun, 2 Dec 2012 06:39:58 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> Date: Sun, 2 Dec 2012 07:39:56 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1499) Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 20:40:01 -0000 On 01/12/2012, at 2:50 AM, Tony Li wrote: >=20 > On Nov 30, 2012, at 7:36 AM, Christopher Morrow = wrote: >=20 >> On Fri, Nov 30, 2012 at 3:58 AM, Robert Raszuk = wrote: >>> Adding new #define range to check when some filtering policy is >>> enabled seems to me like not even in the white noise level as = compared >>> with things which BGP is carrying today and perhaps will carry >>> tomorrow. >>=20 >> by all means, once the floodgates are open, why not drive the valdez >> through the shoals. >=20 >=20 > Come now. This is not a reasonable comparison in so many ways. The = floodgates are not open and this hardly a large issue. >=20 > The exception is already in the code for one range. The issue here is = simply adding another range. >=20 > There is ample demand for doing this, Oh please. Such unquantified assertions are about as much help as: "There is more than ample demand for not doing this" > The remaining question is whether you want it standardized or not. no Geoff From tony.li@tony.li Sat Dec 1 20:36:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABB621F8567 for ; Sat, 1 Dec 2012 20:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmsmY1J4Hfi7 for ; Sat, 1 Dec 2012 20:36:43 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id BF21521F8562 for ; Sat, 1 Dec 2012 20:36:43 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id WUSG1k0011vN32cA7Ucjlm; Sun, 02 Dec 2012 04:36:43 +0000 Received: from sjc-vpn3-709.cisco.com ([128.107.239.233]) by omta22.emeryville.ca.mail.comcast.net with comcast id WUaY1k00452qHCY8iUaa58; Sun, 02 Dec 2012 04:34:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> Date: Sat, 1 Dec 2012 20:34:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354423003; bh=0L4Ag1NyOfmKm3TKd1c+gM95hDGftFXY25IZN9JF848=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=mtwdEb+9Nf3zkA03wybPoqifD8hD6dSfPcEfnvCFi8vNbUda92yrBtuJB7rIMR8bA N0+VCK4Ju3ImGoPiyLlWyBE7+x1xzWbDyPi0zLLUPVQ2HeTstc7cm+d2ufeHnnrWh+ sWZXaWfTFr828kXKcqiuX9T3x7J4Zc+TCxvxMRRN3BpAJDbtOo3xJ0+zFC1qh+XpeI xJEBMnUXWOM1ZLeObSYCwoTkglpKZDCmt4eqHOUAnOPhMnQdFYK4t8ly6l33c82kHM ml5vyvIRdntrzV80mJxdksrdo2rPsaBXkKyaGgT92wOAR01Cai62NGiNXOf06RqVoO VVZXiBTPooJ1g== Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 04:36:44 -0000 >> There is ample demand for doing this, >=20 >=20 > Oh please. Such unquantified assertions are about as much help as: >=20 > "There is more than ample demand for not doing this" Well, sorry. It's the best that I can do within the bounds of customer = confidentiality. Tony From jakob.heitz@ericsson.com Sat Dec 1 21:57:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1921F8D01 for ; Sat, 1 Dec 2012 21:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpHp460nX5hs for ; Sat, 1 Dec 2012 21:57:32 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2D221F8CFE for ; Sat, 1 Dec 2012 21:57:32 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qB25vU40021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 1 Dec 2012 23:57:31 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 2 Dec 2012 00:57:30 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 00:57:30 -0500 From: Jakob Heitz To: idr wg Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHNza+EffMIynRi20WhRXYHBAltwZgBWM6AgAADxQCAAAv5gIAABAIAgAADCICAAAUCAIAAEXyAgACdr4CAAEZsAIAAbzmAgAAD64CAAeMrAIAAhJmA///BRtA= Date: Sun, 2 Dec 2012 05:57:29 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0FE288@eusaamb109.ericsson.se> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> In-Reply-To: <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 05:57:33 -0000 I support the proposal. The private numbers are used by consenting adults in the privacy of their own AS. I say, let them if they want. It's not like there is a scarcity of numbers. It makes sidr a bit more difficult, but it's up to the consenting adults to make their choices. On , Tony Li <> wrote: >>> There is ample demand for doing this, >>=20 >>=20 >> Oh please. Such unquantified assertions are about as much help as: >>=20 >> "There is more than ample demand for not doing this" >=20 >=20 > Well, sorry. It's the best that I can do within the bounds of > customer confidentiality.=20 >=20 > Tony --=20 Jakob Heitz. From randy@psg.com Sat Dec 1 23:14:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1549E21F8FD0 for ; Sat, 1 Dec 2012 23:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj-MN9EbfsOd for ; Sat, 1 Dec 2012 23:14:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9E21F8FCE for ; Sat, 1 Dec 2012 23:14:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tf3kw-0004gh-7Q; Sun, 02 Dec 2012 07:14:26 +0000 Date: Sun, 02 Dec 2012 16:14:25 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E0FE288@eusaamb109.ericsson.se> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> <2F3EBB88EC3A454AAB08915FBF0B8C7E0FE288@eusaamb109.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 07:14:29 -0000 > It makes sidr a bit more difficult not really. rfc 1918 and similar diseases are already addressed by draft-ietf-sidr-ltamgmt randy From randy@psg.com Sat Dec 1 23:18:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4437821F8EB4 for ; Sat, 1 Dec 2012 23:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU+xXOPmoXSd for ; Sat, 1 Dec 2012 23:18:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C34E721F8EB0 for ; Sat, 1 Dec 2012 23:18:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tf3oP-0004h4-Fq; Sun, 02 Dec 2012 07:18:01 +0000 Date: Sun, 02 Dec 2012 16:18:00 +0900 Message-ID: From: Randy Bush To: Tony Li In-Reply-To: <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 07:18:03 -0000 sorry to pick on you, tli. but this is a really bad vendor habit that has to stop. and i did recant and say i conditionally support the draft. >> Oh please. Such unquantified assertions are about as much help as: >> "There is more than ample demand for not doing this" > It's the best that I can do within the bounds of customer > confidentiality. thank you senator mccarthy if your large isp and datacenter customers want something, then they can speak for themselves. i try not to speak for cisco. randy From tony.li@tony.li Sat Dec 1 23:53:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883E821F8EB4 for ; Sat, 1 Dec 2012 23:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+-FOlQv43wU for ; Sat, 1 Dec 2012 23:53:11 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB3321F8EAE for ; Sat, 1 Dec 2012 23:53:11 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta01.emeryville.ca.mail.comcast.net with comcast id WXs81k0040vp7WLA1XtBAx; Sun, 02 Dec 2012 07:53:11 +0000 Received: from sjc-vpn3-709.cisco.com ([128.107.239.233]) by omta05.emeryville.ca.mail.comcast.net with comcast id WXqz1k00C52qHCY8RXr2W1; Sun, 02 Dec 2012 07:51:08 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Sat, 1 Dec 2012 23:50:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> To: Randy Bush X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354434791; bh=o2+lN1+SOgusa1c8qgC30Ozl0EsQpdkG312atgfbCpo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=pjU7Gcvc0wkpHgfwfGbyK2DRjOzTEB169wQ5D+k2+Y06GrUWMTrExU0+2ggdrCrKs NSL3HbQsQyWT4T5X+6nvCnwCH7jqFBgeceLutTWn6NL5OKvOnrqGRuOEsyYsxWS/1Q XLuKd8XLfcVFMvqCnPye3FYK5LMrQMQOEooCh1kOTKt1+w7khsdhFiBRLZF2ze5fQW CBz/++nCPNwffBJIiZfPG1l6Wq3wQPwLcRrWOBHdvDJSZBf6nP56P7OkFo9aawq/8l 02M2qRPYdmk+a6mnDNDYC3Ak/vakQZSxg26yakqanT3ac1X0IhpxXAkbQFsEv8i/AA YipqDQyYpIVBg== Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 07:53:11 -0000 > thank you senator mccarthy Aren't we above name calling? > if your large isp and datacenter customers want something, then they = can > speak for themselves. i try not to speak for cisco. I wish they would too, but the fact of the matter is that not all of the = operational folks attend or participate in IETF. As you well know, many = of the former participants pulled out long ago as a cost saving measure = and they ask their vendors to step up in their stead. =20 I'm trying to be reasonable here and share my perspective. If you = choose to disagree, that's fine, but let's stop with the bickering and = agree to disagree. Tony p.s. cisco is dead, long long ago. I try not to speak = for/to/with/at/in/onto/near Cisco either. From randy@psg.com Sun Dec 2 01:14:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410E321F887E for ; Sun, 2 Dec 2012 01:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8AeRbqvCftB for ; Sun, 2 Dec 2012 01:14:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0DE21F887D for ; Sun, 2 Dec 2012 01:14:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tf5ci-0004t8-DW; Sun, 02 Dec 2012 09:14:04 +0000 Date: Sun, 02 Dec 2012 18:14:03 +0900 Message-ID: From: Randy Bush To: Tony Li In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 09:14:07 -0000 >> thank you senator mccarthy > Aren't we above name calling? with all due respect, and even a little extra, as i said, i did not mean to pick on you. i am merely reminding you and others of the iconic case (in the us culture) of speaking for or about non-present others. > I'm trying to be reasonable here and share my perspective. If you > choose to disagree, that's fine, but let's stop with the bickering and > agree to disagree. i agreed (with conditions) with your point. i disagreed with your argument. i would not persist did i not feel strongly that the disease of speaking for those not present is pernicious. and it is particularly frequent in this wg. randy From mkorourke@gmail.com Sun Dec 2 04:14:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14D121F8D3F for ; Sun, 2 Dec 2012 04:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUcrGEAJVp3D for ; Sun, 2 Dec 2012 04:14:40 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D029521F879D for ; Sun, 2 Dec 2012 04:14:35 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so765078wey.31 for ; Sun, 02 Dec 2012 04:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jc6tytTMO/1km5Ew6/W17cEHH3jMPdHzyMtvmjHe5r4=; b=rcVuWaDM2rvUhoxHcbCsXoRMpli1T5POqkr3Gazbkr1A0QU9dvcT+RvMbk7ic2rCcc Mpb9R8+4+RwhrZl8Xuvu0WxhQ/sov5nOQnAdzzV/8S+RTduIJ4uudJ+UKqqUs1McE5lN 439vvKVTZj8yhDPmrd9prcSn4QkGe7+e+rzbQ9POzzVt5afjTfEToyTkMzmQUpRJTine vlWSut3/kJajs07Oj2z/xawSDiMtnGSHKMDSZ7Yec47RIx4RycdoB1meT20/IgF+q1Lv Ov4P5c1ky9uUk7s6J6vkt5UaP5ep4c+7oRZj3sJynwOwN0aKxlqqjGbXyG7kvMGKP8EO 8vdQ== Received: by 10.180.88.99 with SMTP id bf3mr4807068wib.22.1354443511596; Sun, 02 Dec 2012 02:18:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.154.2 with HTTP; Sun, 2 Dec 2012 02:18:11 -0800 (PST) In-Reply-To: References: From: "Mick O'Rourke" Date: Sun, 2 Dec 2012 21:18:11 +1100 Message-ID: To: John Scudder Content-Type: multipart/alternative; boundary=f46d04428eae60868704cfdbf4d9 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 12:14:44 -0000 --f46d04428eae60868704cfdbf4d9 Content-Type: text/plain; charset=UTF-8 +1 support. A valid problem in large enterprise where eBGP is now widely in use. Perhaps some review of IR membership costs could allow for a better middle ground. There is a case for non-support given the flat nature of IPv6 Internets\internets as to not seeing this draft move ahead. That said could a large enterprise or sp for instance request at the present point in time a block of 2000 ASNs? On Thu, Nov 29, 2012 at 8:26 AM, John Scudder wrote: > Folks, > > We have received a request for a working group last call on > draft-ietf-idr-as-private-reservation-00. A URL for the draft is > http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > > Please send comments to the list by December 14. [*] > > Thanks, > > --John > > [*] Unless the world ends on December 12, in which case send them by > December 12. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d04428eae60868704cfdbf4d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support. A valid problem in large enterprise where eBGP is now=C2=A0wide= ly in use.=C2=A0

Perhaps some review of IR membership co= sts could allow for a better middle ground. There is a case for non-support= given the flat=C2=A0nature=C2=A0of=C2=A0IPv6 Internets\internets as to not= seeing this draft move ahead. That said could a large enterprise or sp for= instance request at the present point in time a block of 2000 ASNs?=C2=A0<= /div>


On Thu, Nov 2= 9, 2012 at 8:26 AM, John Scudder <jgs@juniper.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Folks,

We have received a request for a working group last call on draft-ietf-idr-= as-private-reservation-00. A URL for the draft is ht= tp://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00

Please send comments to the list by December 14. [*]

Thanks,

--John

[*] Unless the world ends on December 12, in which case send them by Decemb= er 12.
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--f46d04428eae60868704cfdbf4d9-- From farmer@umn.edu Mon Dec 3 19:34:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9321E8039 for ; Mon, 3 Dec 2012 19:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9hwcWheMwiO for ; Mon, 3 Dec 2012 19:34:39 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3B21E8034 for ; Mon, 3 Dec 2012 19:34:39 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 3 Dec 2012 21:34:29 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id c10so16647271ieb.1 for ; Mon, 03 Dec 2012 19:34:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=exvjmE6ECEweZ1gdxzdFtXNwxTG2FWUY+aDlBgyJqCM=; b=S27rRbkwF9iGwTqnrrkGsF2SFXzkk7+3fcxRk0U7X7BP2FWsO3TXPih1Cjrx1tf2ZU 3a+p8mQhLavvh1NTHJx6ZYDSFFiU08MDCd+ya5wHX2jn/91m+PgCVaLfqty/BsrI7qt2 FEjFmFBI4buYBEk7BnboTbllG3x4wfDy16GtzXmatFI8b+pcNy0FEH5BmFP+h4dgzCe1 SG6wp6A+pAHRWHJRqeMBAcf2XV8TEzktQHFPIT6TZztvhzDJxUXYdCAIgTwPjaFmNonK MSFN50hiOS1kQDu+o1/x/vHyPPawBDaurpONnneR4/Vnsgw7GI2O5Fym047XwYU4N9y3 dHVQ== Received: by 10.50.42.169 with SMTP id p9mr1324943igl.17.1354592069263; Mon, 03 Dec 2012 19:34:29 -0800 (PST) Received: by 10.50.42.169 with SMTP id p9mr1324937igl.17.1354592069174; Mon, 03 Dec 2012 19:34:29 -0800 (PST) Received: from x-128-101-233-151.uofm-secure.wireless.umn.edu (x-128-101-233-151.uofm-secure.wireless.umn.edu. [128.101.233.151]) by mx.google.com with ESMTPS id ez8sm9598438igb.17.2012.12.03.19.34.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 19:34:28 -0800 (PST) Message-ID: <50BD6F49.8000002@umn.edu> Date: Mon, 03 Dec 2012 21:34:33 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mick O'Rourke References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkp3GwMtbcQFp6JIbhKC7iZW6hO5GvNya+cdQyvVQUZe+0TSmLYfQ+gpncn1zG9o9yDaXexCojUIOkiCPMFHoJDxsNni621/eRGxovdz9ArkiXEsOpIX2ayN/iIUR2aapfcYyRh Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 03:34:40 -0000 On 12/2/12 04:18 , Mick O'Rourke wrote: ... > Perhaps some review of IR membership costs could allow for a better > middle ground. There is a case for non-support given the > flat nature of IPv6 Internets\internets as to not seeing this draft move > ahead. That said could a large enterprise or sp for instance request at > the present point in time a block of 2000 ASNs? I'm a little confused and not sure what you are trying to saying here. If it is that the RIR should revise their policies to allow large blocks of ASNs, then I agree. However, as I said previously the RIR's policies are based on the technical recommendations in RFC 1930, requiring "unique routing policy". If we believe this is no longer the criteria that should be applied, then we should update the technical recommendations within RFC 1930 and I'll bet that the RIR will take that into consideration. As long as RFC 1930 and a "unique routing policy" stands as the technical recommendations, I wouldn't expect the RIR's to significantly deviate from that. However, if IDR provided updated technical recommendations that entities using RFC 4364 VPNs should use registered ASNs per site to facilitate organization mergers and/or provider transitions, among other things. Then I think the RIRs would probably update their policies, fairly quickly. The point is the RIR's are basically following the guidance from this technical community, if we think they should do something different at the very least we should deprecate RFC 1930 to historic status and tell them to no longer consider that as valid guidance. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From internet-drafts@ietf.org Tue Dec 4 10:19:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3437C21F8C97; Tue, 4 Dec 2012 10:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTtjWR070KS8; Tue, 4 Dec 2012 10:19:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A370A21F8C8D; Tue, 4 Dec 2012 10:19:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204181918.10980.20825.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 10:19:18 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:19:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP Optimal Route Reflection (BGP-ORR) Author(s) : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Filename : draft-ietf-idr-bgp-optimal-route-reflection-04.txt Pages : 23 Date : 2012-12-04 Abstract: [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-optimal-route-reflect= ion-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From warren@kumari.net Tue Dec 4 13:37:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B721F8BB4 for ; Tue, 4 Dec 2012 13:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DeMbODQkgv2 for ; Tue, 4 Dec 2012 13:37:53 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6F421F8BA3 for ; Tue, 4 Dec 2012 13:37:51 -0800 (PST) Received: from [192.168.1.142] (unknown [66.84.81.123]) by vimes.kumari.net (Postfix) with ESMTPSA id 2105E1B40467; Tue, 4 Dec 2012 16:37:51 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Tue, 4 Dec 2012 16:37:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <14562746-887E-41D4-98D5-B883857D73D0@kumari.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> To: Randy Bush X-Mailer: Apple Mail (2.1499) Cc: idr wg , Tony Li Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:37:54 -0000 On Dec 2, 2012, at 2:18 AM, Randy Bush wrote: > sorry to pick on you, tli. but this is a really bad vendor habit that > has to stop. and i did recant and say i conditionally support the > draft. >=20 >>> Oh please. Such unquantified assertions are about as much help as: >>> "There is more than ample demand for not doing this" >> It's the best that I can do within the bounds of customer >> confidentiality. >=20 > thank you senator mccarthy >=20 > if your large isp and datacenter customers want something, then they = can > speak for themselves. Well, interestingly enough the draft was written by a Microsoft = Corporation person as was = http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-02 and a = nanog presentation = http://www.nanog.org/meetings/nanog55/presentations/Monday/Lapukhov.pdf =20 > i try not to speak for cisco. >=20 =85 but sometimes I translate for msft :-P W > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 -- What our ancestors would really be thinking, if they were alive today, = is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) From danny@tcb.net Tue Dec 4 19:52:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCEF21F869C for ; Tue, 4 Dec 2012 19:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdCraf2dUjVv for ; Tue, 4 Dec 2012 19:52:01 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id E652621F8651 for ; Tue, 4 Dec 2012 19:52:00 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 612492466 for ; Wed, 5 Dec 2012 03:52:00 +0000 (UTC) Received: from [172.17.67.35] (unknown [76.8.75.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2C3B72464 for ; Tue, 4 Dec 2012 20:52:00 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Tue, 4 Dec 2012 22:51:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF26A06-3533-4803-BAA5-28A136A785BE@tcb.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> <2F3EBB88EC3A454AAB08915FBF0B8C7E0FE288@eusaamb109.ericsson.se> To: idr wg X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Dec 4 20:52:00 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50bec4e0199631505612610 X-DSPAM-Factors: 27, more+#+#+#+rfc, 0.40000, sidr+#+bit, 0.40000, ltamgmt+It's, 0.40000, similar+#+are, 0.40000, 2012+#+2, 0.40000, some+#+#+#+mailing, 0.40000, at+#+14, 0.40000, sidr+#+#+more, 0.40000, ltamgmt+#+#+gross, 0.40000, by+draft, 0.40000, Idr+ietf, 0.40000, not+#+#+1918, 0.40000, sufficient+fodder, 0.40000, 2+#+at, 0.40000, albeit+#+fodder, 0.40000, addressed+by, 0.40000, for+#+#+randy, 0.40000, and+#+#+are, 0.40000, Mime-Version*Message+#+v1283, 0.40000, 2+#+#+#+14, 0.40000, Subject*Re+#+WGLC, 0.40000, never+#+in, 0.40000, 2012+#+#+#+AM, 0.40000, fodder+for, 0.40000, ietf+sidr, 0.40000, rfc+1918, 0.40000, that+#+#+work, 0.40000 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 03:52:01 -0000 On Dec 2, 2012, at 2:14 AM, Randy Bush wrote: >> It makes sidr a bit more difficult >=20 > not really. rfc 1918 and similar diseases are already addressed by > draft-ietf-sidr-ltamgmt It's a gross hack that will never work in practice, albeit sufficient = fodder for some. -danny > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From danny@tcb.net Tue Dec 4 19:53:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD2521F8BFE for ; Tue, 4 Dec 2012 19:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-nOzqMi--1T for ; Tue, 4 Dec 2012 19:53:51 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7B821F869C for ; Tue, 4 Dec 2012 19:53:51 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BDE022466 for ; Wed, 5 Dec 2012 03:53:50 +0000 (UTC) Received: from [172.17.67.35] (unknown [76.8.75.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 869F12464 for ; Tue, 4 Dec 2012 20:53:50 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Tue, 4 Dec 2012 22:53:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <651A9A70-3BCF-40D7-A9A4-2B276E347AB2@apnic.net> <3F381069-9389-4F83-8AB4-AD819C18EDF1@tony.li> To: idr wg X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Dec 4 20:53:50 2012 X-DSPAM-Confidence: 0.9898 X-DSPAM-Improbability: 1 in 9709 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50bec54e199631853666182 X-DSPAM-Factors: 27, 2012+at, 0.01000, Subject*Re+Idr, 0.01000, On+#+#+#+at, 0.01000, On+#+#+2012, 0.01000, psg+#+#+Re, 0.40000, by+#+#+community, 0.40000, hack+#+#+be, 0.40000, present+#+#+#+you, 0.40000, wrote+#+all, 0.40000, e+#+#+#+deployed, 0.40000, there+actual, 0.40000, we+#+#+#+is, 0.40000, as+#+reservation, 0.40000, said+#+#+not, 0.40000, to+#+the, 0.40000, or+#+#+present, 0.40000, an+AS, 0.40000, many+#+#+applying, 0.40000, message+#+#+Bush, 0.40000, doing+#+it's, 0.40000, danny+#+inline, 0.40000, is+#+#+#+i, 0.40000, is+#+#+#+i, 0.40000, i+#+merely, 0.40000, large+#+of, 0.40000, represented+#+the, 0.40000, li+tony, 0.40000 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 03:53:51 -0000 On Dec 2, 2012, at 4:14 AM, Randy Bush wrote: >=20 > with all due respect, and even a little extra, as i said, i did not = mean > to pick on you. i am merely reminding you and others of the iconic = case > (in the us culture) of speaking for or about non-present others. Kinda like you Randy, pretending to be the ordained operator of = operators (e.g., [1]) I agree with Shane, I support this as well. -danny [1] inline below... Begin forwarded message: > From: Randy Bush > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > Date: November 30, 2012 7:13:09 PM EST > To: Tony Li > Cc: idr wg , Robert Raszuk >=20 >> There is ample demand for doing this >=20 > in the current world, there is demand for all sorts of things. >=20 > but is there actual need? i.e. the current widely deployed practice = of > re-using an AS for many customers and applying the 'ignore as loop' = hack > seems to be working well. what we do not have is that hack = formalized. > i think wes and shane are working on that, but i could be wrong. >=20 >> There is ample demand for doing this, it's simply not represented by >> the SP community. >=20 > you will note a large number of SPs speaking against this proposal >=20 > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From danny@tcb.net Tue Dec 4 20:41:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A202721F88FE for ; Tue, 4 Dec 2012 20:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Lpd5oRRiwZd for ; Tue, 4 Dec 2012 20:41:56 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 10CA121F88FB for ; Tue, 4 Dec 2012 20:41:56 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 89ABB2466 for ; Wed, 5 Dec 2012 04:41:55 +0000 (UTC) Received: from [172.17.67.35] (unknown [76.8.75.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 54A042464 for ; Tue, 4 Dec 2012 21:41:55 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Tue, 4 Dec 2012 23:41:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5D19973D-EF7D-44C1-B039-3A1417261CC6@tcb.net> References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> <574CC47E-4BF6-4749-8B44-CFA526ECDFD6@tony.li> <135D3112-A4CB-4B88-AD4A-5A34706566C5@apnic.net> <4145B9A4-56D2-4DEB-9583-F86F7E73BD77@apnic.net> To: idr wg X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Dec 4 21:41:55 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50bed093199639373634055 X-DSPAM-Factors: 27, Mime-Version*Message+#+v1283, 0.01000, Subject*Re+#+WGLC, 0.01000, Subject*Idr+WGLC, 0.01000, 2012+at, 0.01000, Subject*on+draft-ietf-idr-as-private-reservation-00, 0.01000, Subject*Idr+#+#+draft-ietf-idr-as-private-reservation-00, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Subject*Re+#+#+on, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+Idr, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, Subject*WGLC+#+draft-ietf-idr-as-private-reservation-00, 0.01000, Subject*Re+#+#+#+draft-ietf-idr-as-private-reservation-00, 0.01000, Subject*WGLC+on, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, Mime-Version*Apple+Message, 0.01000, Subject*Idr+#+on, 0.01000, From*McPherson+danny, 0.01000, From*Danny McPherson , 0.01000, From*McPherson+#+tcb.net, 0.01000 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 04:41:56 -0000 On Nov 30, 2012, at 7:58 PM, Randy Bush wrote: >=20 > and i would like to do a simulation with 2^42 ASs. let's do an rfc > expanding the AS space to 48 bits. :) Hell, why don't we just bake it into the brand new AS_PATH (e.g., = *_Path) attributes [1] like you're attempting to do in *Standards Track* = documents in SIDR Randy. If we're going to rewrite BGP standards track = documents there but not allow trivial things like this here I recommend = folks with hacks join then fun over in SIDR. -danny [1] http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-06 From enkechen@cisco.com Tue Dec 4 21:00:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A8F21F8929 for ; Tue, 4 Dec 2012 21:00:03 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM5syQGeY5At for ; Tue, 4 Dec 2012 21:00:02 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8376521F898B for ; Tue, 4 Dec 2012 21:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=505; q=dns/txt; s=iport; t=1354683602; x=1355893202; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/1/xQM+QLPApp7dufhCV1zQmMcTFn37a43xmUuElvoc=; b=Gf3GWnNaU0vTimzCexnat1R1S7Zh6KkE5Uf++UXiSILdbPlonAAFz1fI PzqFxlIpdaMDZKTy4C0ObfYgxPwM0thqvaQaciTyWpuFwxHLjtng7nDan aW+d4PbpgAHU+cLExMEP3OnReRC59sR3yh593MDBugjRA8LR+tzJ88mdg M=; X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="63188118" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Dec 2012 05:00:02 +0000 Received: from [10.21.75.247] ([10.21.75.247]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB5500uw000647; Wed, 5 Dec 2012 05:00:01 GMT Message-ID: <50BED4D1.1060600@cisco.com> Date: Tue, 04 Dec 2012 21:00:01 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "John G. Scudder" References: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 05:00:03 -0000 Support. -- Enke On 11/30/12 11:22 AM, John G. Scudder wrote: > On Nov 30, 2012, at 12:34 PM, Chandra Appanna wrote: > >> I figure the chairs might want to hear from some of us who are reading but silent so far.. > Indeed. Thanks for speaking up and I encourage others to do the same if you have an opinion on the subject. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From russw@riw.us Wed Dec 5 05:01:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C172421F89FF for ; Wed, 5 Dec 2012 05:01:03 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JxSEGi-wc-E for ; Wed, 5 Dec 2012 05:01:03 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3212221F89D4 for ; Wed, 5 Dec 2012 05:01:03 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TgEb0-0007fh-Kr for idr@ietf.org; Wed, 05 Dec 2012 05:01:02 -0800 Message-ID: <50BF4591.7010108@riw.us> Date: Wed, 05 Dec 2012 08:01:05 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr@ietf.org References: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> <50BED4D1.1060600@cisco.com> In-Reply-To: <50BED4D1.1060600@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 13:01:03 -0000 Support. Russ On 12/5/2012 12:00 AM, Enke Chen wrote: > Support. -- Enke > > On 11/30/12 11:22 AM, John G. Scudder wrote: >> On Nov 30, 2012, at 12:34 PM, Chandra Appanna >> wrote: >> >>> I figure the chairs might want to hear from some of us who are >>> reading but silent so far.. >> Indeed. Thanks for speaking up and I encourage others to do the same >> if you have an opinion on the subject. >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- <>< riwhite@verisign.com russw@riw.us From jayb@braeburn.org Wed Dec 5 09:01:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54921F85FC for ; Wed, 5 Dec 2012 09:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HLm31WfC3xn for ; Wed, 5 Dec 2012 09:01:24 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 2619821F8447 for ; Wed, 5 Dec 2012 09:01:24 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 3ed7fb05.0.888557.00-254.2492199.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 05 Dec 2012 17:01:24 +0000 (UTC) X-MXL-Hash: 50bf7de47b15ea74-c1dd386d49fdbc117b7a4decb07162560ddd4402 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB5H1Nd1019818 for ; Wed, 5 Dec 2012 12:01:23 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qB5H1JRt019732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Dec 2012 12:01:20 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Wed, 5 Dec 2012 12:01:05 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB5H15NG000466 for ; Wed, 5 Dec 2012 12:01:05 -0500 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qB5H11m0032346 for ; Wed, 5 Dec 2012 12:01:01 -0500 Received: by oz.mt.att.com (Postfix, from userid 1000) id 7D859680A24; Wed, 5 Dec 2012 12:01:00 -0500 (EST) X-Mailer: emacs 23.3.1 (via feedmail 8 I); VM 8.2.0b under 23.3.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20671.32202.484172.394565@oz.mt.att.com> Date: Wed, 5 Dec 2012 12:00:58 -0500 From: Jay Borkenhagen To: In-Reply-To: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:01:25 -0000 Hi, My thoughts on this issue have been best expressed by Jared in his messages here, including the one repeated below. Likewise, I do not support advancing this draft. Jared also wrote in another message: > remove-private-as > Will there be remove-private-as > [oh-yeah-and-that-extended-space-too] ? How will this be > incrementally deployed and used? To spell this out a bit more explicitly, suppose: 1) this draft proceeds, and a new block of private ASNs is allocated. 2) someone starts using a private ASN from the new block, not recognizing that their routers (or their upstream provider's routers) have 'remove-private-as' configured but are running older code that recognizes & removes only the old block. still they get their connectivity to work somehow. 3) later, they (or their upstream provider) upgrades routers to a version that adds the new private ASN block to 'remove-private-as' treatment, and suddenly connectivity breaks or traffic patterns shift in some unwanted way. Yes, this sort of problem with incremental deployment happens all the time. But we should limit the occasions where it happens to those where the win is big enough. In this case I don't think there is enough of a win. BTW, if this draft does proceed, it will provide me with more reasons to encourage network designers I talk to to avoid using private ASNs altogether. Them: "But private ASNs must be great. Look, they just allocated a bunch more." Me: "All the more reason never to use them." :) Thanks. Jay B. On 28-Nov-2012, Jared Mauch writes: > Greetings, > > Jon pointed me to this draft earlier today so please be kind (for the first 5 minutes after this is delivered in your mailbox.). > > After reading the list history back a few months or so on this topic, I must express the same reservation that Randy and Geoff have raised. > > I do not feel this is a problem space that needs to be addressed. Vendors easily disable loop-detection in current running code, and rfc2270 seems to clearly apply in the problem space this is attempting to address. > > The issue of ASN collisions were raised, and I feel can be dismissed easily by one party engaging with their local RIR for a nominal "cost of running BGP" threshold. The recurring annual cost is likely a budgetary "rounding error" and is not a barrier to entry IMHO. > > I have other concerns should this move forward that would impact operations. I will comment on them in private should folks desire. > > I do not feel this draft can be supported. > > - Jared > > > On Nov 29, 2012, at 11:40 AM, Tony Li wrote: > > > > > Support. > > > > Editorial nit: I would find it MUCH more helpful if the constants were also expressed in hex. > > > > Tony > > > > > > On Nov 28, 2012, at 1:26 PM, John Scudder wrote: > > > >> Folks, > >> > >> We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > >> > >> Please send comments to the list by December 14. [*] > >> > >> Thanks, > >> > >> --John > >> > >> [*] Unless the world ends on December 12, in which case send them by December 12. > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From edc@google.com Wed Dec 5 09:13:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EF221F8CFF for ; Wed, 5 Dec 2012 09:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh+HThGuJ7-R for ; Wed, 5 Dec 2012 09:13:00 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70121F8D00 for ; Wed, 5 Dec 2012 09:13:00 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so8428693iea.24 for ; Wed, 05 Dec 2012 09:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=peAhWHUyBPWWTNrM3evhfJIzqpfilk156Pz72DpGoPY=; b=Xxf6H2+/ANTthbxYPGAywEnbIm3gUe0Y504XGTWYlM7dxt5AzXNXG0sjFaWT6OzFuK h+x0vn5hAV6XtckxsrQN9KnaDfkPfP8sUyzdwUKSZJRLf9fNeN7IkBl0Ym/pyxjO9F2k Vt6QMxnCOS5tdLXaLJdft8nh3Xcfvej/79LLvOH8f9RiQG4cNr10UYH5SXUSh3CGZxjE u76+eJC+P3wCl0BqSP8FqVHfyNyxaqL1PW9Ipnlw+D3WcWEpdbWYcsqwyR2Cm3iHGPH3 WTL/yzh0qIuLZD7EMw97rjNnfmrnWUcJm2pW40W2bWNn6AqZXHtIFUGhiHqGDC/7w6eR ynSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=peAhWHUyBPWWTNrM3evhfJIzqpfilk156Pz72DpGoPY=; b=RaBWJtnug04QhZvPC8P1HKHtcY0BZzIQMs+i+7oO2UuTGIs/WGkuNwd5U7ymVzQ4Ks 9oFUr+ZibjqzyDtjzxXJa7YFdZ/jBeVgaiTNRYFYilgQ2bXdgE9tk1UG+NtTIvMTFSqF MALEu57rTwS7lsuptoCFuzX59ZQsvxBVuTixWQs9sHi5E/9DdbHvSIcu3t3jwY3Bzek7 LZldWigtfjadgCWs3lgIxORAfj6HXUCt7R0nC7G5YodMqtFNtshigqp/kyJDU7ubMa8D +AOwYD/pJgWvaDTME0faEBfHf/HF8IuKGtATI3Ic1wAk5+YRbTBYXaDp9hOwfBH1ufEu Nukw== Received: by 10.50.153.137 with SMTP id vg9mr2878509igb.40.1354727579451; Wed, 05 Dec 2012 09:12:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.196.1 with HTTP; Wed, 5 Dec 2012 09:12:19 -0800 (PST) In-Reply-To: <20671.32202.484172.394565@oz.mt.att.com> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> From: Edward Crabbe Date: Wed, 5 Dec 2012 09:12:19 -0800 Message-ID: To: idr@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bafa124012304d01e184e X-Gm-Message-State: ALoCoQmVwQbdnyW/UHg4+u90fz5cn+WYDoIIUfLxKzL/O4WconjYF+8nzXInziA+0cZQ8WMgfpT0EwWqhvvPhc5gzBSOhdCmVnl9NLE2tBFxURok5sx6D423txArp0HpDvGBwl8Tw32FraOy6xbJ1UrSJVf4ZzsKrh/M55jSEQ9pqBl4LRCY2UnPHP1kdEA4X1vAcwtnY1Wq Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:13:01 -0000 --e89a8f3bafa124012304d01e184e Content-Type: text/plain; charset=ISO-8859-1 Support. -ed On Wed, Dec 5, 2012 at 9:00 AM, Jay Borkenhagen wrote: > Hi, > > My thoughts on this issue have been best expressed by Jared in his > messages here, including the one repeated below. Likewise, I do not > support advancing this draft. > > Jared also wrote in another message: > > > remove-private-as > > > Will there be remove-private-as > > [oh-yeah-and-that-extended-space-too] ? How will this be > > incrementally deployed and used? > > To spell this out a bit more explicitly, suppose: > > 1) this draft proceeds, and a new block of private ASNs is allocated. > > 2) someone starts using a private ASN from the new block, not > recognizing that their routers (or their upstream provider's routers) > have 'remove-private-as' configured but are running older code that > recognizes & removes only the old block. still they get their > connectivity to work somehow. > > 3) later, they (or their upstream provider) upgrades routers to a > version that adds the new private ASN block to 'remove-private-as' > treatment, and suddenly connectivity breaks or traffic patterns shift > in some unwanted way. > > > Yes, this sort of problem with incremental deployment happens all the > time. But we should limit the occasions where it happens to those > where the win is big enough. In this case I don't think there is > enough of a win. > > > BTW, if this draft does proceed, it will provide me with more reasons > to encourage network designers I talk to to avoid using private ASNs > altogether. Them: "But private ASNs must be great. Look, they just > allocated a bunch more." Me: "All the more reason never to use them." > :) > > Thanks. > Jay B. > > > > On 28-Nov-2012, Jared Mauch writes: > > Greetings, > > > > Jon pointed me to this draft earlier today so please be kind (for the > first 5 minutes after this is delivered in your mailbox.). > > > > After reading the list history back a few months or so on this topic, I > must express the same reservation that Randy and Geoff have raised. > > > > I do not feel this is a problem space that needs to be addressed. > Vendors easily disable loop-detection in current running code, and rfc2270 > seems to clearly apply in the problem space this is attempting to address. > > > > The issue of ASN collisions were raised, and I feel can be dismissed > easily by one party engaging with their local RIR for a nominal "cost of > running BGP" threshold. The recurring annual cost is likely a budgetary > "rounding error" and is not a barrier to entry IMHO. > > > > I have other concerns should this move forward that would impact > operations. I will comment on them in private should folks desire. > > > > I do not feel this draft can be supported. > > > > - Jared > > > > > > On Nov 29, 2012, at 11:40 AM, Tony Li wrote: > > > > > > > > Support. > > > > > > Editorial nit: I would find it MUCH more helpful if the constants > were also expressed in hex. > > > > > > Tony > > > > > > > > > On Nov 28, 2012, at 1:26 PM, John Scudder wrote: > > > > > >> Folks, > > >> > > >> We have received a request for a working group last call on > draft-ietf-idr-as-private-reservation-00. A URL for the draft is > http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > > >> > > >> Please send comments to the list by December 14. [*] > > >> > > >> Thanks, > > >> > > >> --John > > >> > > >> [*] Unless the world ends on December 12, in which case send them by > December 12. > > >> _______________________________________________ > > >> Idr mailing list > > >> Idr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/idr > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --e89a8f3bafa124012304d01e184e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Suppor= t.

=A0 -ed

On Wed, Dec= 5, 2012 at 9:00 AM, Jay Borkenhagen <jayb@braeburn.org> wro= te:
Hi,

My thoughts on this issue have been best expressed by Jared in his
messages here, including the one repeated below. =A0Likewise, I do not
support advancing this draft.

Jared also wrote in another message:

=A0> remove-private-as

=A0> Will there be remove-private-as
=A0> [oh-yeah-and-that-extended-space-too] ? =A0How will this be
=A0> incrementally deployed and used?

To spell this out a bit more explicitly, suppose:

1) this draft proceeds, and a new block of private ASNs is allocated.

2) someone starts using a private ASN from the new block, not
recognizing that their routers (or their upstream provider's routers) have 'remove-private-as' configured but are running older code that=
recognizes & removes only the old block. =A0still they get their
connectivity to work somehow.

3) later, they (or their upstream provider) upgrades routers to a
version that adds the new private ASN block to 'remove-private-as'<= br> treatment, and suddenly connectivity breaks or traffic patterns shift
in some unwanted way.


Yes, this sort of problem with incremental deployment happens all the
time. =A0But we should limit the occasions where it happens to those
where the win is big enough. =A0In this case I don't think there is
enough of a win.


BTW, if this draft does proceed, it will provide me with more reasons
to encourage network designers I talk to to avoid using private ASNs
altogether. =A0Them: "But private ASNs must be great. =A0Look, they ju= st
allocated a bunch more." =A0Me: "All the more reason never to use= them."
:)

Thanks.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Jay B.



On 28-Nov-2012, Jared Mauch writes:
=A0> Greetings,
=A0>
=A0> Jon pointed me to this draft earlier today so please be kind (for t= he first 5 minutes after this is delivered in your mailbox.).
=A0>
=A0> After reading the list history back a few months or so on this topi= c, I must express the same reservation that Randy and Geoff have raised. =A0>
=A0> I do not feel this is a problem space that needs to be addressed. = =A0Vendors easily disable loop-detection in current running code, and rfc22= 70 seems to clearly apply in the problem space this is attempting to addres= s.
=A0>
=A0> The issue of ASN collisions were raised, and I feel can be dismisse= d easily by one party engaging with their local RIR for a nominal "cos= t of running BGP" threshold. =A0The recurring annual cost is likely a = budgetary "rounding error" and is not a barrier to entry IMHO. =A0>
=A0> I have other concerns should this move forward that would impact op= erations. =A0I will comment on them in private should folks desire.
=A0>
=A0> I do not feel this draft can be supported.
=A0>
=A0> - Jared
=A0>
=A0>
=A0> On Nov 29, 2012, at 11:40 AM, Tony Li wrote:
=A0>
=A0> >
=A0> > Support.
=A0> >
=A0> > Editorial nit: I would find it MUCH more helpful if the consta= nts were also expressed in hex.
=A0> >
=A0> > Tony
=A0> >
=A0> >
=A0> > On Nov 28, 2012, at 1:26 PM, John Scudder <jgs@juniper.net> wrote:
=A0> >
=A0> >> Folks,
=A0> >>
=A0> >> We have received a request for a working group last call o= n draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reserv= ation-00
=A0> >>
=A0> >> Please send comments to the list by December 14. [*]
=A0> >>
=A0> >> Thanks,
=A0> >>
=A0> >> --John
=A0> >>
=A0> >> [*] Unless the world ends on December 12, in which case se= nd them by December 12.
=A0> >> _______________________________________________
=A0> >> Idr mailing list
=A0> >> Idr@ietf.org
=A0> >> https://www.ietf.org/mailman/listinfo/idr
=A0> >
=A0> > _______________________________________________
=A0> > Idr mailing list
=A0> > Idr@ietf.org
=A0> > https://www.ietf.org/mailman/listinfo/idr
=A0>
=A0> _______________________________________________
=A0> Idr mailing list
=A0> Idr@ietf.org
=A0> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--e89a8f3bafa124012304d01e184e-- From jared@puck.nether.net Wed Dec 5 09:23:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B94121F8CA0 for ; Wed, 5 Dec 2012 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yzZjj3ov3xP for ; Wed, 5 Dec 2012 09:23:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id AB51921F8C14 for ; Wed, 5 Dec 2012 09:23:21 -0800 (PST) Received: from [10.0.0.129] (173-167-0-105-michigan.hfc.comcastbusiness.net [173.167.0.105]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qB5HNJxT004261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 12:23:19 -0500 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <20671.32202.484172.394565@oz.mt.att.com> Date: Wed, 5 Dec 2012 12:23:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> To: Jay Borkenhagen X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 05 Dec 2012 12:23:19 -0500 (EST) Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:23:22 -0000 On Dec 5, 2012, at 12:00 PM, Jay Borkenhagen wrote: > Yes, this sort of problem with incremental deployment happens all the > time. But we should limit the occasions where it happens to those > where the win is big enough. In this case I don't think there is > enough of a win. >=20 >=20 > BTW, if this draft does proceed, it will provide me with more reasons > to encourage network designers I talk to to avoid using private ASNs > altogether. Them: "But private ASNs must be great. Look, they just > allocated a bunch more." Me: "All the more reason never to use them." > :) This represents my concerns as well with incremental deployment. Most = BGP ASes aren't as smart as the people on this list, and I am concerned = for them as they upgrade and the vendors update the code and implement = this change. (I say this, because I feel like i'm hearing consensus on = supporting this). I think perhaps there should be some recommendations about implementing = this, perhaps: routes should not go eBGP without explicit configuration Then again, I wish that vendors wouldn't send ANY routes without = explicit policy configuration.. would solve the millions of transient = routing leaks seen all day long. (see work in grow-wg). - Jared= From christopher.morrow@gmail.com Wed Dec 5 09:56:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1340821F8720 for ; Wed, 5 Dec 2012 09:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvmsaEmAxArk for ; Wed, 5 Dec 2012 09:56:44 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B74CA21F870C for ; Wed, 5 Dec 2012 09:56:43 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so2385163eaa.31 for ; Wed, 05 Dec 2012 09:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/Z39Pw37xkVJtdlNTF7uuw35NWxQD392xfSyewbAWyc=; b=wb4FcWCn5KBGN1sYVY/Ly3/xg8L6pASmofiGUnltEWVhWpZVT5HCZkeJ6kvcJcIjmc EbMpEsOhKsRJEGBTyb5T24CWqgHfK02ZepAtzXii9qEtpmBqAVnRzH6KAyl10Mpo8j6l gzO1Sz2sAkVJfeYH2mTuPAQHxbPSyausPM56xsffNaCQwY32Eon3d3eHYx6hawmt+6pu UpvMOl+QWrf9BqXMX38Vcr7XCUAiR1pxlUN2VywHRA5DRN6GcujSIitpmBTXyDf9mvBD oGalL+EMv8fg4kq+j+Hg5gwoX+EIiAaDI+qVaO/LMMtDFNDWxTCl6KaVRqIXoRkiBc/t 6dMg== MIME-Version: 1.0 Received: by 10.14.214.132 with SMTP id c4mr63085815eep.18.1354730202802; Wed, 05 Dec 2012 09:56:42 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Wed, 5 Dec 2012 09:56:42 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> Date: Wed, 5 Dec 2012 12:56:42 -0500 X-Google-Sender-Auth: LNL9q902NRWN5QQRWwXGcjFLgXA Message-ID: From: Christopher Morrow To: Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:56:45 -0000 On Wed, Dec 5, 2012 at 12:12 PM, Edward Crabbe wrote: > Support. > you support the draft of jay's non-support for support of the draft? > > > On Wed, Dec 5, 2012 at 9:00 AM, Jay Borkenhagen wrote: >> >> Hi, >> >> My thoughts on this issue have been best expressed by Jared in his >> messages here, including the one repeated below. Likewise, I do not >> support advancing this draft. >> >> Jared also wrote in another message: >> >> > remove-private-as >> >> > Will there be remove-private-as >> > [oh-yeah-and-that-extended-space-too] ? How will this be >> > incrementally deployed and used? >> >> To spell this out a bit more explicitly, suppose: >> >> 1) this draft proceeds, and a new block of private ASNs is allocated. >> >> 2) someone starts using a private ASN from the new block, not >> recognizing that their routers (or their upstream provider's routers) >> have 'remove-private-as' configured but are running older code that >> recognizes & removes only the old block. still they get their >> connectivity to work somehow. >> >> 3) later, they (or their upstream provider) upgrades routers to a >> version that adds the new private ASN block to 'remove-private-as' >> treatment, and suddenly connectivity breaks or traffic patterns shift >> in some unwanted way. >> >> >> Yes, this sort of problem with incremental deployment happens all the >> time. But we should limit the occasions where it happens to those >> where the win is big enough. In this case I don't think there is >> enough of a win. >> >> >> BTW, if this draft does proceed, it will provide me with more reasons >> to encourage network designers I talk to to avoid using private ASNs >> altogether. Them: "But private ASNs must be great. Look, they just >> allocated a bunch more." Me: "All the more reason never to use them." >> :) >> >> Thanks. >> Jay B. >> >> >> >> On 28-Nov-2012, Jared Mauch writes: >> > Greetings, >> > >> > Jon pointed me to this draft earlier today so please be kind (for the >> first 5 minutes after this is delivered in your mailbox.). >> > >> > After reading the list history back a few months or so on this topic, I >> must express the same reservation that Randy and Geoff have raised. >> > >> > I do not feel this is a problem space that needs to be addressed. >> Vendors easily disable loop-detection in current running code, and rfc2270 >> seems to clearly apply in the problem space this is attempting to address. >> > >> > The issue of ASN collisions were raised, and I feel can be dismissed >> easily by one party engaging with their local RIR for a nominal "cost of >> running BGP" threshold. The recurring annual cost is likely a budgetary >> "rounding error" and is not a barrier to entry IMHO. >> > >> > I have other concerns should this move forward that would impact >> operations. I will comment on them in private should folks desire. >> > >> > I do not feel this draft can be supported. >> > >> > - Jared >> > >> > >> > On Nov 29, 2012, at 11:40 AM, Tony Li wrote: >> > >> > > >> > > Support. >> > > >> > > Editorial nit: I would find it MUCH more helpful if the constants >> were also expressed in hex. >> > > >> > > Tony >> > > >> > > >> > > On Nov 28, 2012, at 1:26 PM, John Scudder wrote: >> > > >> > >> Folks, >> > >> >> > >> We have received a request for a working group last call on >> draft-ietf-idr-as-private-reservation-00. A URL for the draft is >> http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 >> > >> >> > >> Please send comments to the list by December 14. [*] >> > >> >> > >> Thanks, >> > >> >> > >> --John >> > >> >> > >> [*] Unless the world ends on December 12, in which case send them by >> December 12. >> > >> _______________________________________________ >> > >> Idr mailing list >> > >> Idr@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/idr >> > > >> > > _______________________________________________ >> > > Idr mailing list >> > > Idr@ietf.org >> > > https://www.ietf.org/mailman/listinfo/idr >> > >> > _______________________________________________ >> > Idr mailing list >> > Idr@ietf.org >> > https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From edc@google.com Wed Dec 5 10:01:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C125321F8CA6 for ; Wed, 5 Dec 2012 10:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z27sZn9q3QRb for ; Wed, 5 Dec 2012 10:01:11 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0A6F21F874D for ; Wed, 5 Dec 2012 10:01:11 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4474009iaz.31 for ; Wed, 05 Dec 2012 10:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=l53g6ET4+dzkyslnadQv9051JI/P8K1CfHRo8NNJ1QY=; b=Ib+J7GXf3G69lkt0s2QUnzJYzrgzUgNudBPsZ6vAP8VAPRszAfTafdQtnAjqtO7IGg CM423omd27/Dgf4++bXP5XNSo68CNfpivx0kmvlcfQ4j+FZGOO7RNJdoxN+g4LapaAqy M8hbkucZ2/L02Iy2iHFSwuHBzXg7gN7+d3lRUEhXX2ShdbiGDTKDP4WDuiIMVdMCeV6a 6E0fx7n5r1rEIlH0hWxGYu7qCucxFhB3lVAKMX59HbLt027l4eXikUMmt4OfUtC2dcbQ cXdPLq0prfAabzUfudEI7E96X8J+WGPNzqvPa8SZoo7qbgp9mwvdH/uy58NlXtlitwkA nTvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=l53g6ET4+dzkyslnadQv9051JI/P8K1CfHRo8NNJ1QY=; b=kM82UzTdqNQUsWCvFEfhIR6ZarciJ/g4VwKElaRFQtH/qqzx6ido8RITzfRmjDFoxe ZGc0pQFDzhqPiWXHHA8LAHpA7BhzPUOWH/FosCqqWALVCJNQ2vOEOqZXMVdG+S26LwJO kfi4IWsj6T5gAfaDbImg+2qEmcxG99vcFJuE5dGe5NZQaW0Q1umJbip0F+DksLSNOry9 ezD4kV3wpZwKNZX7xYdFzaXXXxYvi4dv+ELtbgUi3fiCG8j4aXKhvpvWXAUyMZul4+bE HfULOU/OotO5aSWTP/7Zk6BVIDj28bXc6YIzBnibHjY+I/t6WhK8UnAt5G3CuE6zqDGr +R7A== Received: by 10.50.214.68 with SMTP id ny4mr2988834igc.65.1354730471030; Wed, 05 Dec 2012 10:01:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.196.1 with HTTP; Wed, 5 Dec 2012 10:00:30 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> From: Edward Crabbe Date: Wed, 5 Dec 2012 10:00:30 -0800 Message-ID: To: Christopher Morrow Content-Type: multipart/alternative; boundary=14dae93404f57dff5e04d01ec4c4 X-Gm-Message-State: ALoCoQnzHNdEQ8TvtMMDA2It8rHs6jCZpHwxZR6noSQZuabO1VCHr9RgrIAmTaa/lG2Jb/c53U+eqq2kexQB5UApDCv6IM4/6VlZebrrpXMrnW1DaTSdExVe8MTM4Uxy1vY//90rsmtymQVsfDyUwXaooF2WGR2CrXkmLeCZff/H2lBfeyZ+lq1M5nRpNw0rXFRKKsCcvJoA Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:01:12 -0000 --14dae93404f57dff5e04d01ec4c4 Content-Type: text/plain; charset=ISO-8859-1 I support the draft. cheers, -ed On Wed, Dec 5, 2012 at 9:56 AM, Christopher Morrow wrote: > On Wed, Dec 5, 2012 at 12:12 PM, Edward Crabbe wrote: > > Support. > > > > you support the draft of jay's non-support for support of the draft? > > > > > > > On Wed, Dec 5, 2012 at 9:00 AM, Jay Borkenhagen > wrote: > >> > >> Hi, > >> > >> My thoughts on this issue have been best expressed by Jared in his > >> messages here, including the one repeated below. Likewise, I do not > >> support advancing this draft. > >> > >> Jared also wrote in another message: > >> > >> > remove-private-as > >> > >> > Will there be remove-private-as > >> > [oh-yeah-and-that-extended-space-too] ? How will this be > >> > incrementally deployed and used? > >> > >> To spell this out a bit more explicitly, suppose: > >> > >> 1) this draft proceeds, and a new block of private ASNs is allocated. > >> > >> 2) someone starts using a private ASN from the new block, not > >> recognizing that their routers (or their upstream provider's routers) > >> have 'remove-private-as' configured but are running older code that > >> recognizes & removes only the old block. still they get their > >> connectivity to work somehow. > >> > >> 3) later, they (or their upstream provider) upgrades routers to a > >> version that adds the new private ASN block to 'remove-private-as' > >> treatment, and suddenly connectivity breaks or traffic patterns shift > >> in some unwanted way. > >> > >> > >> Yes, this sort of problem with incremental deployment happens all the > >> time. But we should limit the occasions where it happens to those > >> where the win is big enough. In this case I don't think there is > >> enough of a win. > >> > >> > >> BTW, if this draft does proceed, it will provide me with more reasons > >> to encourage network designers I talk to to avoid using private ASNs > >> altogether. Them: "But private ASNs must be great. Look, they just > >> allocated a bunch more." Me: "All the more reason never to use them." > >> :) > >> > >> Thanks. > >> Jay B. > >> > >> > >> > >> On 28-Nov-2012, Jared Mauch writes: > >> > Greetings, > >> > > >> > Jon pointed me to this draft earlier today so please be kind (for the > >> first 5 minutes after this is delivered in your mailbox.). > >> > > >> > After reading the list history back a few months or so on this > topic, I > >> must express the same reservation that Randy and Geoff have raised. > >> > > >> > I do not feel this is a problem space that needs to be addressed. > >> Vendors easily disable loop-detection in current running code, and > rfc2270 > >> seems to clearly apply in the problem space this is attempting to > address. > >> > > >> > The issue of ASN collisions were raised, and I feel can be dismissed > >> easily by one party engaging with their local RIR for a nominal "cost of > >> running BGP" threshold. The recurring annual cost is likely a budgetary > >> "rounding error" and is not a barrier to entry IMHO. > >> > > >> > I have other concerns should this move forward that would impact > >> operations. I will comment on them in private should folks desire. > >> > > >> > I do not feel this draft can be supported. > >> > > >> > - Jared > >> > > >> > > >> > On Nov 29, 2012, at 11:40 AM, Tony Li wrote: > >> > > >> > > > >> > > Support. > >> > > > >> > > Editorial nit: I would find it MUCH more helpful if the constants > >> were also expressed in hex. > >> > > > >> > > Tony > >> > > > >> > > > >> > > On Nov 28, 2012, at 1:26 PM, John Scudder wrote: > >> > > > >> > >> Folks, > >> > >> > >> > >> We have received a request for a working group last call on > >> draft-ietf-idr-as-private-reservation-00. A URL for the draft is > >> http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > >> > >> > >> > >> Please send comments to the list by December 14. [*] > >> > >> > >> > >> Thanks, > >> > >> > >> > >> --John > >> > >> > >> > >> [*] Unless the world ends on December 12, in which case send them > by > >> December 12. > >> > >> _______________________________________________ > >> > >> Idr mailing list > >> > >> Idr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/idr > >> > > > >> > > _______________________________________________ > >> > > Idr mailing list > >> > > Idr@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/idr > >> > > >> > _______________________________________________ > >> > Idr mailing list > >> > Idr@ietf.org > >> > https://www.ietf.org/mailman/listinfo/idr > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > --14dae93404f57dff5e04d01ec4c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I supp= ort the draft.

cheers,
=A0
=A0-ed
On Wed, Dec 5, 2012 at 9:56 AM, Christopher= Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Dec 5, 2012 at 12:12 PM, Edward Crab= be <edc@google.com> wrote:
> Support.
>

you support the draft of jay's non-support for support of the draft?

>
>
> On Wed, Dec 5, 2012 at 9:00 AM, Jay Borkenhagen <jayb@braeburn.org> wrote:
>>
>> Hi,
>>
>> My thoughts on this issue have been best expressed by Jared in his=
>> messages here, including the one repeated below. =A0Likewise, I do= not
>> support advancing this draft.
>>
>> Jared also wrote in another message:
>>
>> =A0> remove-private-as
>>
>> =A0> Will there be remove-private-as
>> =A0> [oh-yeah-and-that-extended-space-too] ? =A0How will this b= e
>> =A0> incrementally deployed and used?
>>
>> To spell this out a bit more explicitly, suppose:
>>
>> 1) this draft proceeds, and a new block of private ASNs is allocat= ed.
>>
>> 2) someone starts using a private ASN from the new block, not
>> recognizing that their routers (or their upstream provider's r= outers)
>> have 'remove-private-as' configured but are running older = code that
>> recognizes & removes only the old block. =A0still they get the= ir
>> connectivity to work somehow.
>>
>> 3) later, they (or their upstream provider) upgrades routers to a<= br> >> version that adds the new private ASN block to 'remove-private= -as'
>> treatment, and suddenly connectivity breaks or traffic patterns sh= ift
>> in some unwanted way.
>>
>>
>> Yes, this sort of problem with incremental deployment happens all = the
>> time. =A0But we should limit the occasions where it happens to tho= se
>> where the win is big enough. =A0In this case I don't think the= re is
>> enough of a win.
>>
>>
>> BTW, if this draft does proceed, it will provide me with more reas= ons
>> to encourage network designers I talk to to avoid using private AS= Ns
>> altogether. =A0Them: "But private ASNs must be great. =A0Look= , they just
>> allocated a bunch more." =A0Me: "All the more reason nev= er to use them."
>> :)
>>
>> Thanks.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jay B.
>>
>>
>>
>> On 28-Nov-2012, Jared Mauch writes:
>> =A0> Greetings,
>> =A0>
>> =A0> Jon pointed me to this draft earlier today so please be ki= nd (for the
>> first 5 minutes after this is delivered in your mailbox.).
>> =A0>
>> =A0> After reading the list history back a few months or so on = this topic, I
>> must express the same reservation that Randy and Geoff have raised= .
>> =A0>
>> =A0> I do not feel this is a problem space that needs to be add= ressed.
>> Vendors easily disable loop-detection in current running code, and= rfc2270
>> seems to clearly apply in the problem space this is attempting to = address.
>> =A0>
>> =A0> The issue of ASN collisions were raised, and I feel can be= dismissed
>> easily by one party engaging with their local RIR for a nominal &q= uot;cost of
>> running BGP" threshold. =A0The recurring annual cost is likel= y a budgetary
>> "rounding error" and is not a barrier to entry IMHO.
>> =A0>
>> =A0> I have other concerns should this move forward that would = impact
>> operations. =A0I will comment on them in private should folks desi= re.
>> =A0>
>> =A0> I do not feel this draft can be supported.
>> =A0>
>> =A0> - Jared
>> =A0>
>> =A0>
>> =A0> On Nov 29, 2012, at 11:40 AM, Tony Li wrote:
>> =A0>
>> =A0> >
>> =A0> > Support.
>> =A0> >
>> =A0> > Editorial nit: I would find it MUCH more helpful if t= he constants
>> were also expressed in hex.
>> =A0> >
>> =A0> > Tony
>> =A0> >
>> =A0> >
>> =A0> > On Nov 28, 2012, at 1:26 PM, John Scudder <jgs@juniper.net> wrote:
>> =A0> >
>> =A0> >> Folks,
>> =A0> >>
>> =A0> >> We have received a request for a working group la= st call on
>> draft-ietf-idr-as-private-reservation-00. A URL for the draft is >> http://tools.ietf.org/html/draft-ietf-idr-a= s-private-reservation-00
>> =A0> >>
>> =A0> >> Please send comments to the list by December 14. = [*]
>> =A0> >>
>> =A0> >> Thanks,
>> =A0> >>
>> =A0> >> --John
>> =A0> >>
>> =A0> >> [*] Unless the world ends on December 12, in whic= h case send them by
>> December 12.
>> =A0> >> _______________________________________________ >> =A0> >> Idr mailing list
>> =A0> >> Idr@ietf.org<= br> >> =A0> >> https://www.ietf.org/mailman/listinfo/idr
>> =A0> >
>> =A0> > _______________________________________________
>> =A0> > Idr mailing list
>> =A0> > Idr@ietf.org
>> =A0> > https://www.ietf.org/mailman/listinfo/idr
>> =A0>
>> =A0> _______________________________________________
>> =A0> Idr mailing list
>> =A0> Idr@ietf.org
>> =A0> https://www.ietf.org/mailman/listinfo/idr
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--14dae93404f57dff5e04d01ec4c4-- From ttauber@1-4-5.net Wed Dec 5 12:17:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402D621F88EE for ; Wed, 5 Dec 2012 12:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaD0aYp0AmRN for ; Wed, 5 Dec 2012 12:17:16 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0821F8860 for ; Wed, 5 Dec 2012 12:17:16 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5993026obc.31 for ; Wed, 05 Dec 2012 12:17:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=h+3kXosoIUoR7txxP8Cnme/KsWZeKhKustFgTYG6wfk=; b=Xnimr0gEuvODX95Cr4iLKodF4cwwIkHqR1YgSpPMCpnEnjRU8tiu5BQeuyPm6zNu1/ r5CNxDr9SpDF0S8zhmTjtA6L7i4D2o9m2HVeM6ykgYR8y+E9ixgOmwzXimDKWeFJ/zjR /TUmEU5FrpDxroNYJfy3NnP9pQQPr01gwp848CjbMbGsJ2sjYpScyHF/w1S5HfphOLI3 FO3YV4cE9ZtfZlqoLZbFEP/OV+mBkHLB0Yrr9W8g/lw6od0ILgSXBvkS5K26ezyNuemf v/fIIc8LusY+5NIaym3T3IqYPwIVhcE8XO+xXSzhikiVEDxskkiGET++MYyVGcNsPfU9 MBrA== MIME-Version: 1.0 Received: by 10.182.45.42 with SMTP id j10mr11005765obm.60.1354738635851; Wed, 05 Dec 2012 12:17:15 -0800 (PST) Received: by 10.76.153.99 with HTTP; Wed, 5 Dec 2012 12:17:15 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: <20671.32202.484172.394565@oz.mt.att.com> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> Date: Wed, 5 Dec 2012 15:17:15 -0500 Message-ID: From: Tony Tauber To: Jay Borkenhagen Content-Type: multipart/alternative; boundary=f46d044472b52746d304d020ab65 X-Gm-Message-State: ALoCoQkSRK1xowp0cwvJPUTq+s9lZGgxGIYy7fGWbmHzVWbsStn2qFg6Gk/PBkb+dmBTJMG/zsjq Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:17:17 -0000 --f46d044472b52746d304d020ab65 Content-Type: text/plain; charset=ISO-8859-1 A long-time public hater of "private" namespaces (trans: "Hey, I can do whatever I want!"), I oppose this draft. As usual, my reasons are the inevitable clashes during mergers and some other silo in the company wanting to bring their junk out the Lab and play right with Production. (Why Production is using private name/number spaces is not something I can quash on my own, unfortunately.) Tony --f46d044472b52746d304d020ab65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A long-time public hater of "private" namespaces (trans: "He= y, I can do whatever I want!"), I oppose this draft.

As usual, = my reasons are the inevitable clashes during mergers and some other silo in= the company wanting to bring their junk out the Lab and play right with Pr= oduction.=A0 (Why Production is using private name/number spaces is not som= ething I can quash on my own, unfortunately.)

Tony
--f46d044472b52746d304d020ab65-- From rraszuk@gmail.com Wed Dec 5 12:49:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B733F21F8BF3 for ; Wed, 5 Dec 2012 12:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNAnBKDtL91m for ; Wed, 5 Dec 2012 12:49:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id F24A121F8AF5 for ; Wed, 5 Dec 2012 12:49:36 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9655433ieb.31 for ; Wed, 05 Dec 2012 12:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Wzwt3EZ+vzlogyEOMxJa++EPrhZR4C74rq2nITudvCs=; b=ERfQx0mKjqjtqEa8ZIIISYMjEBfGjmk6jjy5z+PQ3nOqOY0aphTecIUfuGNGS0bVrO 4odP/NTlnR02EzYhC2wiaRM05p9ECXMTuFe9M+4ygaJN4GjxzxVB4eMycCT53u1uOScJ mdarkQj3NTsjTpFozJUNOBroXQndymt904CUXCD2QrdEAmsA4V67ivTne775W2Wi1hcS KKQGWL+xNjFodO1v9W9ZmOLfOoPKkIKyB3jXlnPxQigSLeZMBQjxe6A9zPidl+D5EhGN Wh+cxMyJOCIP+iW4aOguDd9nX+5Lj4oaFKESt8VUpB8I6PmhHYp4GO3ZsQkS7RodQ/4f snHA== MIME-Version: 1.0 Received: by 10.50.207.104 with SMTP id lv8mr3508556igc.33.1354740576546; Wed, 05 Dec 2012 12:49:36 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 5 Dec 2012 12:49:36 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> Date: Wed, 5 Dec 2012 21:49:36 +0100 X-Google-Sender-Auth: l2Q5GMDs_9QLoHI-CvRfuFfo1Z8 Message-ID: From: Robert Raszuk To: Tony Tauber Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, Jay Borkenhagen Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:49:37 -0000 All, I think both Tony and Jay forgot that routing and reachability is not about originator AS .. it is about prefixes they advertise. If peering ISP AS chooses to peer with private as or remove private as from AS-PATH or for completeness substitute with their own it is all ok. He takes responsibility to route data to such customer(s). Any subsequent removal of private as in the path also results in the same responsibility of the provider who permits private AS for peering. I am not sure why there is concern with it on the list. Is this perhaps related to folks being afraid that some providers may offer a "SIDR free peering" for a little more value add ? I still support the draft to proceed to RFC. Cheers, R. > On Wed, Dec 5, 2012 at 9:17 PM, Tony Tauber wrote: > > A long-time public hater of "private" namespaces (trans: "Hey, I can do > whatever I want!"), I oppose this draft. > > As usual, my reasons are the inevitable clashes during mergers and some > other silo in the company wanting to bring their junk out the Lab and play > right with Production. (Why Production is using private name/number spaces > is not something I can quash on my own, unfortunately.) > > Tony > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From pmohapat@cisco.com Wed Dec 5 13:45:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6D21F87D7 for ; Wed, 5 Dec 2012 13:45:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33nNPrC-LRcZ for ; Wed, 5 Dec 2012 13:45:16 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8489421F8AF1 for ; Wed, 5 Dec 2012 13:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1299; q=dns/txt; s=iport; t=1354743916; x=1355953516; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BN1nnu6IcPb1yZl8YE5WmKVrH/rpeHqHYK9R8Hybb+g=; b=OUcP/byLK8V4VOKc8eQJ64nBliTBjle1GhMQIckO//zTdxXhDBQEPW39 weDwsigAD/YSUfyugWf8GC2W1neIrpjeUOYy3BQwkM6g/gTT2Xz61MTvU IQu0mFMPHvroffdyzIo6x34D09ujEQDaMt5Tc/HRI7SlSJXNcexoImXNY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANS/v1CtJV2d/2dsb2JhbABEulyDSBZzgiABBDo/EgEIIgsJQiUCBAENDYgIwlmMX2aCUmEDpkqCcoFlPA X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149829566" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2012 21:45:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB5LjFcg028539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 21:45:15 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.110]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 15:45:14 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Robert Raszuk , Tony Tauber Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHNza+ASu61tTboPkC+faw5xeSRvpgBaZKAgAADxACACXARAIAANteAgAAJCgD//4ltAA== Date: Wed, 5 Dec 2012 21:45:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.155.33.251] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , Jay Borkenhagen Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:45:17 -0000 >I think both Tony and Jay forgot that routing and reachability is not >about originator AS .. it is about prefixes they advertise. > >If peering ISP AS chooses to peer with private as or remove private as >from AS-PATH or for completeness substitute with their own it is all >ok. He takes responsibility to route data to such customer(s). > >Any subsequent removal of private as in the path also results in the >same responsibility of the provider who permits private AS for >peering. > >I am not sure why there is concern with it on the list. Not sure you understood the issue Jay was pointing to - but it is a problem worth talking about if we are serious about advancing this draft. Say an enterprise starts using ASN 4278190081. It already has a bunch of ASNs from the 16-bit private AS range and relies on the correct behavior of "remove-private-as" from the ISP. The ISP routers are not upgraded to understand 4278190081 is a private ASN. We get into all sorts of interesting scenarios based on the connectivity graph (changes in traffic pattern come to mind as I know folks compare AS_PATH length taking into account remove-private-as). The 'operational considerations' section does talk about this - but I would like it described in more detail. - Pradosh From rraszuk@gmail.com Wed Dec 5 13:51:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96E21F8BBA for ; Wed, 5 Dec 2012 13:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBjlqR4FMLaZ for ; Wed, 5 Dec 2012 13:51:37 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C86C21F898B for ; Wed, 5 Dec 2012 13:51:37 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4674624iaz.31 for ; Wed, 05 Dec 2012 13:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WGuUK8GBpc5G8RhwbLV4kdhMrun7oJkl9YwrmQow5kI=; b=bbi91Cd/YURY3ULPqFv6ePExI6CVDTpq3pauuLSgptU8DhpoIbTChOIBOeWrYFLkOQ Df7hNLk5r8dU9L0cxthwZNdegsL7ryjdkE5McLScNMJUTCSVwOl+NIzUT+751SvBqVGS DvXABnuJ10JO3cnSB3JEWpM7I/Jn/EaokT08Dbqe2xj36Ak/vssCANWx+Jw5qZNn0okH qGXA1pLMxa1QcJNCsMj+paJPHbgZsldgyVSQHT/TH8+GdTKr8J5Omcd2RnRKbtixwn2R ClE/aBEXY3d12KaYDldwpy20A86tHf7OGDNH29PD3jcl5zZN3wdBwzbwQR9djUrfxmkv 1M9Q== MIME-Version: 1.0 Received: by 10.42.52.204 with SMTP id k12mr1560064icg.3.1354744297137; Wed, 05 Dec 2012 13:51:37 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 5 Dec 2012 13:51:36 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Dec 2012 22:51:36 +0100 X-Google-Sender-Auth: 6zEqBJP07v0cjXZa7G6rqxnzfYc Message-ID: From: Robert Raszuk To: "Pradosh Mohapatra (pmohapat)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:51:38 -0000 Pradosh, It is ISP 101 to provide BGP peer configuration by specifying peering AS number. If ISP does it in the same time he needs to apply appropriate policy reg handling or propagation of such AS. Simple as this. If you say that ISP is not aware that his old "remove-private-as" knob will not remove newly defined 4 octet private AS range I think such ISP should go back to class. Cheers, R. > On Wed, Dec 5, 2012 at 10:45 PM, Pradosh Mohapatra (pmohapat) wrote: >>I think both Tony and Jay forgot that routing and reachability is not >>about originator AS .. it is about prefixes they advertise. >> >>If peering ISP AS chooses to peer with private as or remove private as >>from AS-PATH or for completeness substitute with their own it is all >>ok. He takes responsibility to route data to such customer(s). >> >>Any subsequent removal of private as in the path also results in the >>same responsibility of the provider who permits private AS for >>peering. >> >>I am not sure why there is concern with it on the list. > > > Not sure you understood the issue Jay was pointing to - but it is a > problem worth talking about if we are serious about advancing this draft. > > Say an enterprise starts using ASN 4278190081. It already has a bunch of > ASNs from the 16-bit private AS range and relies on the correct behavior > of "remove-private-as" from the ISP. The ISP routers are not upgraded to > understand 4278190081 is a private ASN. We get into all sorts of > interesting scenarios based on the connectivity graph (changes in traffic > pattern come to mind as I know folks compare AS_PATH length taking into > account remove-private-as). > > The 'operational considerations' section does talk about this - but I > would like it described in more detail. > > - Pradosh > From pmohapat@cisco.com Wed Dec 5 13:55:58 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C0C21F8CED for ; Wed, 5 Dec 2012 13:55:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEJw8yTEibaP for ; Wed, 5 Dec 2012 13:55:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8AD21F8CA4 for ; Wed, 5 Dec 2012 13:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2204; q=dns/txt; s=iport; t=1354744557; x=1355954157; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=c/dZs95ktJ/2wrSluk/75g1A4wWGcESz4nIGuutj4A4=; b=hR7mmt2PxCc5XUN3VszWnlXDPooZcUe6GmF1EkrB9SCYagGhLKC5L1Pg G7YHuuCRqqgA95ninK9JlqUXto7upA2y6xhxrb7QlxisS3SLI+RmIwx2t fJ5xTQq4tasITt9VKxqszrqCxESXn3gkD1L2AiVeQjF9FwocTSHWIU8QC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIfBv1CtJXG//2dsb2JhbABEviQWc4IeAQEBBDo/EgEIGAoLCUIlAgQOBQiICMJZjDcoZoJSYQOmSoJygWU8 X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149618672" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 05 Dec 2012 21:55:56 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB5LtusB001449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 21:55:56 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.110]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 15:55:55 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Robert Raszuk Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHNza+ASu61tTboPkC+faw5xeSRvpgBaZKAgAADxACACXARAIAANteAgAAJCgD//4ltAIAAh+YA//97EYA= Date: Wed, 5 Dec 2012 21:55:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.155.33.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <38CA880C5781C54284E35F5FB9AE11EB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 21:55:58 -0000 Robert, It may not be the same ISP (think of inter-AS VPNs). Again, as I said, I would like this to be spelled out in the document in more detail - what problems we envision and what the guidelines are. - Pradosh On 12/5/12 1:51 PM, "Robert Raszuk" wrote: >Pradosh, > >It is ISP 101 to provide BGP peer configuration by specifying peering >AS number. > >If ISP does it in the same time he needs to apply appropriate policy >reg handling or propagation of such AS. > >Simple as this. > >If you say that ISP is not aware that his old "remove-private-as" knob >will not remove newly defined 4 octet private AS range I think such >ISP should go back to class. > >Cheers, >R. > >> On Wed, Dec 5, 2012 at 10:45 PM, Pradosh Mohapatra (pmohapat) >> wrote: >>>I think both Tony and Jay forgot that routing and reachability is not >>>about originator AS .. it is about prefixes they advertise. >>> >>>If peering ISP AS chooses to peer with private as or remove private as >>>from AS-PATH or for completeness substitute with their own it is all >>>ok. He takes responsibility to route data to such customer(s). >>> >>>Any subsequent removal of private as in the path also results in the >>>same responsibility of the provider who permits private AS for >>>peering. >>> >>>I am not sure why there is concern with it on the list. >> >> >> Not sure you understood the issue Jay was pointing to - but it is a >> problem worth talking about if we are serious about advancing this >>draft. >> >> Say an enterprise starts using ASN 4278190081. It already has a bunch of >> ASNs from the 16-bit private AS range and relies on the correct behavior >> of "remove-private-as" from the ISP. The ISP routers are not upgraded to >> understand 4278190081 is a private ASN. We get into all sorts of >> interesting scenarios based on the connectivity graph (changes in >>traffic >> pattern come to mind as I know folks compare AS_PATH length taking into >> account remove-private-as). >> >> The 'operational considerations' section does talk about this - but I >> would like it described in more detail. >> >> - Pradosh >> From rraszuk@gmail.com Wed Dec 5 14:02:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D704C21F8BAE for ; Wed, 5 Dec 2012 14:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQMJnESSEP2Z for ; Wed, 5 Dec 2012 14:02:03 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9821F86D1 for ; Wed, 5 Dec 2012 14:02:02 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so5259585iaz.17 for ; Wed, 05 Dec 2012 14:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7SoHgX43JpU7LocCJImXBud6AL9yEcD4dW2zWCBhPXQ=; b=QnxUOpuHjKO5BR1WBJn8XyMRNhhmJVXZ8pEN4fLOJm+gn0hECxuz809ZIHoE77aheQ oVcrsPxqvn5/AQ2ojegPvSB3gccS5Gf5vP2fFcak8tYhJENZICQ2nudcTpHsY7Ua5MVo RVGPmq+QqG7Gi/Wr6qAcSoSLN101rQBkJLvzBv84IVcDsyKDYgfK5AlsPjv8V+1z0jYZ Py6L5Shv7bQHxGflpL/PklUA4kJ2x04MEAA4jNw/DG6GA0PV4XBumff0+HSMjxIW57UW tEgws0LVUEseaCnJR9ZiS/hONcs5+JFwrXAAzRWUqrgTresFs8oUOmKn8ct9TUcmKJtm vg+Q== MIME-Version: 1.0 Received: by 10.50.157.130 with SMTP id wm2mr3848267igb.0.1354744922618; Wed, 05 Dec 2012 14:02:02 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 5 Dec 2012 14:02:02 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Dec 2012 23:02:02 +0100 X-Google-Sender-Auth: iEIgs4ADnHhjtnSTFS6VBLGisWA Message-ID: From: Robert Raszuk To: "Pradosh Mohapatra (pmohapat)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 22:02:04 -0000 Pradosh, I think mixing Internet routing with L3VPNs with DCs etc .. in this discussion is completely not that much helpful. Likewise if we go the path to mandate listing concerns and various deployment scenarios the odds that this document will proceed is quite low. IMO this document should just reserve the new private AS space leaving all other aspects of it's use to the autonomy and freedom of local operators. Rgs, R. > On Wed, Dec 5, 2012 at 10:55 PM, Pradosh Mohapatra (pmohapat) wrote: > > Robert, > > It may not be the same ISP (think of inter-AS VPNs). > > Again, as I said, I would like this to be spelled out in the document in > more detail - what problems we envision and what the guidelines are. > > - Pradosh > > > On 12/5/12 1:51 PM, "Robert Raszuk" wrote: > >>Pradosh, >> >>It is ISP 101 to provide BGP peer configuration by specifying peering >>AS number. >> >>If ISP does it in the same time he needs to apply appropriate policy >>reg handling or propagation of such AS. >> >>Simple as this. >> >>If you say that ISP is not aware that his old "remove-private-as" knob >>will not remove newly defined 4 octet private AS range I think such >>ISP should go back to class. >> >>Cheers, >>R. >> >>> On Wed, Dec 5, 2012 at 10:45 PM, Pradosh Mohapatra (pmohapat) >>> wrote: >>>>I think both Tony and Jay forgot that routing and reachability is not >>>>about originator AS .. it is about prefixes they advertise. >>>> >>>>If peering ISP AS chooses to peer with private as or remove private as >>>>from AS-PATH or for completeness substitute with their own it is all >>>>ok. He takes responsibility to route data to such customer(s). >>>> >>>>Any subsequent removal of private as in the path also results in the >>>>same responsibility of the provider who permits private AS for >>>>peering. >>>> >>>>I am not sure why there is concern with it on the list. >>> >>> >>> Not sure you understood the issue Jay was pointing to - but it is a >>> problem worth talking about if we are serious about advancing this >>>draft. >>> >>> Say an enterprise starts using ASN 4278190081. It already has a bunch of >>> ASNs from the 16-bit private AS range and relies on the correct behavior >>> of "remove-private-as" from the ISP. The ISP routers are not upgraded to >>> understand 4278190081 is a private ASN. We get into all sorts of >>> interesting scenarios based on the connectivity graph (changes in >>>traffic >>> pattern come to mind as I know folks compare AS_PATH length taking into >>> account remove-private-as). >>> >>> The 'operational considerations' section does talk about this - but I >>> would like it described in more detail. >>> >>> - Pradosh >>> > From pmohapat@cisco.com Wed Dec 5 14:11:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100F821F892F for ; Wed, 5 Dec 2012 14:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsX1Y7HgGJ7u for ; Wed, 5 Dec 2012 14:11:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4429421F8CCC for ; Wed, 5 Dec 2012 14:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=485; q=dns/txt; s=iport; t=1354745484; x=1355955084; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eXQGoMJJnwIsbW8PZHSVHqQbOFG5D+1RVLzQX/2uULk=; b=BOfRRCeDCBRTAnjecnxjZIBW1MYiSRgyQsIm15fwEHZOPP6GuenqIf2n hhGcL6TosgHvHw/tnMlzEs2OQCZ3C4fF1PzgcP6pFimG6gIsbKvssSHfF RB3EEE7O6JaDhk6XLkhIgakSLF9ecceZAytkURq4yroFZeI18Njiyd4mL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADTFv1CtJV2c/2dsb2JhbABEviQWc4IgAQQ6PxIBCCIUQiUCBA4NiAjCXZAXYQOmSoJygiE X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149837675" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2012 22:11:24 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB5MBNeq000739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 22:11:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.110]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 16:11:23 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Robert Raszuk Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHNza+ASu61tTboPkC+faw5xeSRvpgBaZKAgAADxACACXARAIAANteAgAAJCgD//4ltAIAAh+YA//97EYCAAIfZAP//fH6A Date: Wed, 5 Dec 2012 22:11:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.155.33.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CCEE7C631E052488FD125071E84331A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 22:11:31 -0000 >I think mixing Internet routing with L3VPNs with DCs etc .. in this >discussion is completely not that much helpful. ?? >Likewise if we go the path to mandate listing concerns and various >deployment scenarios the odds that this document will proceed is quite >low. > >IMO this document should just reserve the new private AS space leaving >all other aspects of it's use to the autonomy and freedom of local >operators. Thank you for your opinion. - Pradosh From christopher.morrow@gmail.com Wed Dec 5 22:24:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78D221F8D48 for ; Wed, 5 Dec 2012 22:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHxt9UWhDtQw for ; Wed, 5 Dec 2012 22:24:33 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E39021F868E for ; Wed, 5 Dec 2012 22:24:32 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so2591064eaa.31 for ; Wed, 05 Dec 2012 22:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=c4/qV1t1Md/BXpHQ7RqOCXcpW4CJ89V0Nxx/zdZOvMI=; b=ik6DrGILKZ5VnqVlSzzBWfOml0DeFWjUBIcDrGH27IFRBwQ4wZQhxOnUfznPsiPaYL AdXlvhHxn17SeZ/aywAIqrs4rjyMwbS3d/+BCRc2k+sbC/LRmFx8ffzkqLqnJLbO3c88 WEMNzYstcoo0wPTSwVbOOXJkuokrChYOOtgEYRhARv+h0ZCkZlHCd+9JpVCOQwjDKD5G 8HuLA7lmBHIXjmW8Zqn7Q8Os4D9uiBpmMbKlsF+9g0onw0zSyu8LVSGjsQ/pNK7I3fyX rFowrusXcZDyAE9Bxbcpd4Q/1bylEoMjgPn8NMz+Hs7hViX5ykEd9tSoOkvPWCe+kN8q /1sA== MIME-Version: 1.0 Received: by 10.14.208.137 with SMTP id q9mr2088351eeo.28.1354775068209; Wed, 05 Dec 2012 22:24:28 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Wed, 5 Dec 2012 22:24:27 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Dec 2012 01:24:27 -0500 X-Google-Sender-Auth: uEyngkBM6EZURnJGDKZYXbcU0jw Message-ID: From: Christopher Morrow To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , Tony Tauber , Jay Borkenhagen Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 06:24:34 -0000 On Wed, Dec 5, 2012 at 4:51 PM, Robert Raszuk wrote: > Pradosh, > > It is ISP 101 to provide BGP peer configuration by specifying peering > AS number. > > If ISP does it in the same time he needs to apply appropriate policy > reg handling or propagation of such AS. so glad those filters are working so well today... > Simple as this. > > If you say that ISP is not aware that his old "remove-private-as" knob > will not remove newly defined 4 octet private AS range I think such > ISP should go back to class. sure works well today. > Cheers, > R. > >> On Wed, Dec 5, 2012 at 10:45 PM, Pradosh Mohapatra (pmohapat) wrote: >>>I think both Tony and Jay forgot that routing and reachability is not >>>about originator AS .. it is about prefixes they advertise. >>> >>>If peering ISP AS chooses to peer with private as or remove private as >>>from AS-PATH or for completeness substitute with their own it is all >>>ok. He takes responsibility to route data to such customer(s). >>> >>>Any subsequent removal of private as in the path also results in the >>>same responsibility of the provider who permits private AS for >>>peering. >>> >>>I am not sure why there is concern with it on the list. >> >> >> Not sure you understood the issue Jay was pointing to - but it is a >> problem worth talking about if we are serious about advancing this draft. >> >> Say an enterprise starts using ASN 4278190081. It already has a bunch of >> ASNs from the 16-bit private AS range and relies on the correct behavior >> of "remove-private-as" from the ISP. The ISP routers are not upgraded to >> understand 4278190081 is a private ASN. We get into all sorts of >> interesting scenarios based on the connectivity graph (changes in traffic >> pattern come to mind as I know folks compare AS_PATH length taking into >> account remove-private-as). >> >> The 'operational considerations' section does talk about this - but I >> would like it described in more detail. >> >> - Pradosh >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Thu Dec 6 01:06:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A190921F8628 for ; Thu, 6 Dec 2012 01:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQlYEKFKz-NE for ; Thu, 6 Dec 2012 01:06:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2C84221F8632 for ; Thu, 6 Dec 2012 01:06:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TgXPO-0008eE-PO; Thu, 06 Dec 2012 09:06:19 +0000 Date: Thu, 06 Dec 2012 18:06:14 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 09:06:23 -0000 > so glad those filters are working so well today... > ... > sure works well today. i offer a really nice dinner, probably in berlin, for someone who comes up with a simple emoticon for dripping sarcasm (apologies for idiomatic american). randy From chris.hall@highwayman.com Thu Dec 6 05:21:41 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38D521F853A for ; Thu, 6 Dec 2012 05:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BukLNRtTfPQQ for ; Thu, 6 Dec 2012 05:21:41 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id EB7C921F8543 for ; Thu, 6 Dec 2012 05:21:40 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 5CA99384084; Thu, 6 Dec 2012 13:21:39 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 3852E384080; Thu, 6 Dec 2012 13:21:39 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP; Thu, 6 Dec 2012 13:21:39 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TgbOU-0005ao-DR; Thu, 06 Dec 2012 13:21:38 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> In-Reply-To: <50AD2986.90705@cisco.com> Date: Thu, 6 Dec 2012 13:21:33 -0000 Organization: Highwayman Message-ID: <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6Kl7t2PBA= Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 13:21:41 -0000 I've been trying to adjust the error handling in Quagga bgpd to follow this draft, without success. If an update message arrives and there is a problem with one or more significant attributes, then if (and only if) *all* the NLRI in the update can be identified, then treat-as-withdraw is an excellent alternative to crashing the entire session. This much is clear, and clearly a step forward. If only it were possible to "parse" attributes individually.... ....but since it is not: when faced with a broken set of attributes, I do not see how the receiver can be certain that it has correctly and completely identified all NLRI. RFC4271 allows for an update to contain any and all combinations of vanilla IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI (also reachable and/or unreachable). Given that one broken attribute may obscure following ones, the receiver can be certain that it has correctly and completely identified all NLRI if, and only if, it has extracted *both* a complete MP_REACH_NLRI *and* a complete MP_UNREACH_NLRI attribute. Otherwise, the receiver must, in effect, prove a negative: that one or both attributes were not sent. The draft acknowledges the issue, and requires that "the MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first path attribute" (should that be "and/or" rather than "or" ?). How is the receiver to know that the sender is following this new rule ? Can it simply assume that to be the case ? Apparently the answers are: it cannot and may not, in that order -- since the draft also says "... MUST still be prepared to receive these fields in any position". If the receiver cannot know (or simply assume) that the new rule is being followed, then given a broken set of attributes: * if there are vanilla IPv4 NLRI: - can it be assumed that there are no MP NLRI if none can be extracted ? * if there are no vanilla IPv4 NLRI: - can it be assumed that if MP_REACH_NLRI can be extracted then there will be no MP_UNREACH_NLRI ? - if the only attribute is MP_UNREACH_NLRI then everything is fine. But if any other attribute is present, if no MP_REACH_NLRI can be extracted, should the receiver assume that one is missing (hidden by a broken attribute) ? The answer to that appears, currently, to be yes. But that excludes, forever, the ability to attach extra information to a withdraw update. - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI can be extracted, can it be assumed that this is an empty UPDATE ? Or is this a session- crashing-error ? Of course, if the session is only carrying vanilla IPv4 Unicast, life is easy. But otherwise, it seems to me that in order to make use of the "treat-as-withdraw" mechanism, the receiver of a broken set of attributes has to make some significant assumptions about the behaviour of the sender. I do not know which, if any, of those assumptions it is safe to make. I am, of course, assuming that having received a broken UPDATE, it is *essential* to avoid continuing with the session unless *all* NLRI referred to in that UPDATE have been "treated-as-withdraw". Chris From ttauber@1-4-5.net Thu Dec 6 07:19:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D2921F8773 for ; Thu, 6 Dec 2012 07:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol+kDOaxJN32 for ; Thu, 6 Dec 2012 07:19:01 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAF721F876C for ; Thu, 6 Dec 2012 07:19:01 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so7087070oag.31 for ; Thu, 06 Dec 2012 07:19:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zPndE/mFnDRhnv+6f8WXwheDUF67TuJ/bLI7Rr1ks3Q=; b=UvNxsI4S+hZ4+4GQ/UHrIhYjsrrKjsH0LynNMgHJ8oZ9pQlcbLGGL36/5s/Zqi76hb 66J6XHWLiE65pmk4conC15jWe+CD4bb2YGv/PNEzJ2n3vfZHoA7vFO8O5ZvTaLTlM6rV j/OPGJu2kNM0BKW4JCubRiQIkT7BeBKGYYY5EHPYfTLuGfwGWTuQl3wH97nmHsm9vXmi JtbPQ6NArLPOdW67ej9Q8vyu0bB4FDzgx15VVvE9igLWRxo0ayitMH8B0bOCalZVUR11 Q1ktfoYlHN7NRqW/NXVfpoF43gKqMLYo2qyM9pBFEX1ObX6o5KjMMQGUOX+BovDrcU/m kl+Q== MIME-Version: 1.0 Received: by 10.60.32.39 with SMTP id f7mr1057787oei.86.1354807140935; Thu, 06 Dec 2012 07:19:00 -0800 (PST) Received: by 10.76.153.99 with HTTP; Thu, 6 Dec 2012 07:19:00 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> Date: Thu, 6 Dec 2012 10:19:00 -0500 Message-ID: From: Tony Tauber To: Robert Raszuk Content-Type: multipart/alternative; boundary=e89a8fb1eb8a5fe8e804d0309e6c X-Gm-Message-State: ALoCoQlklVITbhaMsUmwMx9PxwE1sm4XclgLyydEKOWeYFBEIObZ4IBRgPBcRAAFcjEohAuLPSvx Cc: idr@ietf.org, Jay Borkenhagen Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:19:02 -0000 --e89a8fb1eb8a5fe8e804d0309e6c Content-Type: text/plain; charset=ISO-8859-1 Not at all what I had in mind. What I had in mind was a situation where a carrier is using a separate ASN for every one of thousands of some type of site or customer (because there are so many private ASNs, don't worry!) Then they have policies which say "when a route comes with such and such an origin AS, do something or other". Of course, stripping the private AS internally will break such policy logic. Then they acquire another carrier whose clever engineers had the same type of thinking and now the presumption of uniqueness w/in their deployment scope is broken. Sometimes such things can be aided by clever use of hack-y vendor features (unless remove-private-as is part of the BGP standard); sometimes not. That problem was the one I was trying to articulate. The problem that Jay seemed to have in mind of backward compatibility and semantics of what is considered a private AS is different (and something I hadn't considered, so glad he mentioned it.) Tony On Wed, Dec 5, 2012 at 3:49 PM, Robert Raszuk wrote: > All, > > I think both Tony and Jay forgot that routing and reachability is not > about originator AS .. it is about prefixes they advertise. > > If peering ISP AS chooses to peer with private as or remove private as > from AS-PATH or for completeness substitute with their own it is all > ok. He takes responsibility to route data to such customer(s). > > Any subsequent removal of private as in the path also results in the > same responsibility of the provider who permits private AS for > peering. > > I am not sure why there is concern with it on the list. > --e89a8fb1eb8a5fe8e804d0309e6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not at all what I had in mind.=A0 What I had in mind was a situation where = a carrier is using a separate ASN for every one of thousands of some type o= f site or customer (because there are so many private ASNs, don't worry= !)=A0 Then they have policies which say "when a route comes with such = and such an origin AS, do something or other".=A0 Of course, stripping= the private AS internally will break such policy logic.

Then they acquire another carrier whose clever engineers had the same t= ype of thinking and now the presumption of uniqueness w/in their deployment= scope is broken.=A0 Sometimes such things can be aided by clever use of ha= ck-y vendor features (unless remove-private-as is part of the BGP standard)= ; sometimes not.

That problem was the one I was trying to articulate.

The problem= that Jay seemed to have in mind of backward compatibility and semantics of= what is considered a private AS is different (and something I hadn't c= onsidered, so glad he mentioned it.)

Tony

On Wed, Dec 5, 2012 at 3:49 PM, = Robert Raszuk <robert@raszuk.net> wrote:
All,

I think both Tony and Jay forgot that routing and reachability is not
about originator AS .. it is about prefixes they advertise.

If peering ISP AS chooses to peer with private as or remove private as
from AS-PATH or for completeness substitute with their own it is all
ok. He takes responsibility to route data to such customer(s).

Any subsequent removal of private as in the path also results in the
same responsibility of the provider who permits private AS for
peering.

I am not sure why there is concern with it on the list.
--e89a8fb1eb8a5fe8e804d0309e6c-- From sairay@cisco.com Thu Dec 6 08:25:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A334021F86FE for ; Thu, 6 Dec 2012 08:25:25 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjtcKvCAdvMZ for ; Thu, 6 Dec 2012 08:25:24 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A36F421F875B for ; Thu, 6 Dec 2012 08:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4057; q=dns/txt; s=iport; t=1354811124; x=1356020724; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=h32ww+pKnvNM+DhZdDsxwaXm8HZx5JCk7qZVtkYCBmM=; b=P1H228nNPnLwATE6yMr+GF/FycQmg/dj0OY3NMj/pd8WnFe5sOmKS+8X 2ycx6t2Yjrmp0Ar0TRGvTOMinm7LiNqhmisvvZXJ26EOdXSS9zfjNhhsg lIV5scGN0DFGkX7TKeSACl8t9lxAD3Bj3DC6q+Wui0zP/vLyyYVf0KNTT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL3FwFCtJV2c/2dsb2JhbABEvioWc4IeAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEggRh3cMwjAEjDmDYmEDklCTeoJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="150103623" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 06 Dec 2012 16:25:24 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB6GPOPE012106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 16:25:24 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.90]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 10:25:23 -0600 From: "Saikat Ray (sairay)" To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6Kl7t2PBCAAEyvoA== Date: Thu, 6 Dec 2012 16:25:23 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> In-Reply-To: <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:25:25 -0000 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Chris= Hall Sent: Thursday, December 06, 2012 5:22 AM To: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt I've been trying to adjust the error handling in Quagga bgpd to follow this= draft, without success. If an update message arrives and there is a problem with one or more signif= icant attributes, then if (and only if) *all* the NLRI in the update can be= identified, then treat-as-withdraw is an excellent alternative to crashing= the entire session. This much is clear, and clearly a step forward. If only it were possible t= o "parse" attributes individually.... [SR] In which way is the attribute "broken"? If the receiver ever thinks/kn= ows that it has lost the sync=20 (i.e., the knowledge of TLV to byte mapping) on the tcp stream, it= must reset the session. So if an attribute is broken because of any length issue, the sess= ion needs to be reset. ....but since it is not: when faced with a broken set of attributes, I do n= ot see how the receiver can be certain that it has correctly and completely= identified all NLRI. RFC4271 allows for an update to contain any and all combinations of vanilla= IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI (also reachab= le and/or unreachable). Given that one broken attribute may obscure follow= ing ones, the receiver can be certain that it has correctly and completely = identified all NLRI if, and only if, it has extracted *both* a complete MP_= REACH_NLRI *and* a complete MP_UNREACH_NLRI attribute. Otherwise, the rece= iver must, in effect, prove a negative: that one or both attributes were no= t sent. The draft acknowledges the issue, and requires that "the MP_REACH_NLRI or M= P_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first pa= th attribute" (should that be "and/or" rather than "or" ?). How is the receiver to know that the sender is following this new rule ? C= an it simply assume that to be the case ? Apparently the answers are: it cannot and may not, in that order -- since the draft also says "...= MUST still be prepared to receive these fields in any position". If the receiver cannot know (or simply assume) that the new rule is being f= ollowed, then given a broken set of attributes: * if there are vanilla IPv4 NLRI: - can it be assumed that there are no MP NLRI if none can be extracted ? * if there are no vanilla IPv4 NLRI: - can it be assumed that if MP_REACH_NLRI can be extracted then there will be no MP_UNREACH_NLRI ? - if the only attribute is MP_UNREACH_NLRI then everything is fine. But if any other attribute is present, if no=20 MP_REACH_NLRI can be extracted, should the receiver assume that one is missing (hidden by a broken attribute) ? The answer to that appears, currently, to be yes. But that excludes, forever, the ability to attach extra information to a withdraw update. - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI can be extracted, can it be assumed that this is an empty UPDATE ? Or is this a session- crashing-error ? Of course, if the session is only carrying vanilla IPv4 Unicast, life is ea= sy. But otherwise, it seems to me that in order to make use of the "treat-as-wi= thdraw" mechanism, the receiver of a broken set of attributes has to make s= ome significant assumptions about the behaviour of the sender. I do not kn= ow which, if any, of those assumptions it is safe to make. I am, of course, assuming that having received a broken UPDATE, it is *essential* to avoid continuing with the session unless *all* NLRI referred= to in that UPDATE have been "treated-as-withdraw". Chris _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Dec 6 10:07:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9DE21F880D for ; Thu, 6 Dec 2012 10:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbvL0g2g1GdK for ; Thu, 6 Dec 2012 10:07:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5666D21F8654 for ; Thu, 6 Dec 2012 10:07:48 -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 qB6IHIgG020375; Thu, 6 Dec 2012 12:17:19 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Dec 2012 13:07:38 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 13:07:38 -0500 From: Jakob Heitz To: "Saikat Ray (sairay)" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCq Date: Thu, 6 Dec 2012 18:07:38 +0000 Message-ID: <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com>, <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:07:51 -0000 Some length errors will not be detected as length errors, but as misinterpr= etation of subsequent bytes. You must accept receipt of any legal combinations of NLRI and attributes, e= ven if they seem weird. If you get a message length too long error, the most likely result will be = that you misinterpret the 0xFF's as NLRI and get an NLRI length error. -- Jakob Heitz. On Dec 6, 2012, at 8:25 AM, "Saikat Ray (sairay)" wrote: > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Chr= is Hall > Sent: Thursday, December 06, 2012 5:22 AM > To: idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt >=20 > I've been trying to adjust the error handling in Quagga bgpd to follow th= is draft, without success. >=20 > If an update message arrives and there is a problem with one or more sign= ificant attributes, then if (and only if) *all* the NLRI in the update can = be identified, then treat-as-withdraw is an excellent alternative to crashi= ng the entire session. >=20 > This much is clear, and clearly a step forward. If only it were possible= to "parse" attributes individually.... >=20 > [SR] In which way is the attribute "broken"? If the receiver ever thinks/= knows that it has lost the sync=20 > (i.e., the knowledge of TLV to byte mapping) on the tcp stream, i= t must reset the session. > So if an attribute is broken because of any length issue, the ses= sion needs to be reset. >=20 > ....but since it is not: when faced with a broken set of attributes, I do= not see how the receiver can be certain that it has correctly and complete= ly identified all NLRI. >=20 > RFC4271 allows for an update to contain any and all combinations of vanil= la IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI (also reach= able and/or unreachable). Given that one broken attribute may obscure foll= owing ones, the receiver can be certain that it has correctly and completel= y identified all NLRI if, and only if, it has extracted *both* a complete M= P_REACH_NLRI *and* a complete MP_UNREACH_NLRI attribute. Otherwise, the re= ceiver must, in effect, prove a negative: that one or both attributes were = not sent. >=20 > The draft acknowledges the issue, and requires that "the MP_REACH_NLRI or= MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first = path attribute" (should that be "and/or" rather than "or" ?). > How is the receiver to know that the sender is following this new rule ? = Can it simply assume that to be the case ? Apparently the answers > are: it cannot and may not, in that order -- since the draft also says ".= .. MUST still be prepared to receive these fields in any position". >=20 > If the receiver cannot know (or simply assume) that the new rule is being= followed, then given a broken set of attributes: >=20 > * if there are vanilla IPv4 NLRI: >=20 > - can it be assumed that there are no MP NLRI > if none can be extracted ? >=20 > * if there are no vanilla IPv4 NLRI: >=20 > - can it be assumed that if MP_REACH_NLRI can be > extracted then there will be no MP_UNREACH_NLRI ? >=20 > - if the only attribute is MP_UNREACH_NLRI then > everything is fine. >=20 > But if any other attribute is present, if no=20 > MP_REACH_NLRI can be extracted, should the > receiver assume that one is missing (hidden by > a broken attribute) ? >=20 > The answer to that appears, currently, to be yes. > But that excludes, forever, the ability to attach > extra information to a withdraw update. >=20 > - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI > can be extracted, can it be assumed that this > is an empty UPDATE ? Or is this a session- > crashing-error ? >=20 > Of course, if the session is only carrying vanilla IPv4 Unicast, life is = easy. >=20 > But otherwise, it seems to me that in order to make use of the "treat-as-= withdraw" mechanism, the receiver of a broken set of attributes has to make= some significant assumptions about the behaviour of the sender. I do not = know which, if any, of those assumptions it is safe to make. >=20 > I am, of course, assuming that having received a broken UPDATE, it is > *essential* to avoid continuing with the session unless *all* NLRI referr= ed to in that UPDATE have been "treated-as-withdraw". >=20 > Chris >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From brian.peter.dickson@gmail.com Thu Dec 6 10:59:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8885F21F8653 for ; Thu, 6 Dec 2012 10:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6suD5MAsh2DX for ; Thu, 6 Dec 2012 10:59:24 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D489821F862C for ; Thu, 6 Dec 2012 10:59:23 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so4229263eek.31 for ; Thu, 06 Dec 2012 10:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b+3T6O0XqbgtxDfZ7oc9XY0Jm7twjQwCpXl5zGPGoEI=; b=XDwAVx29LnOqL92/C8gfjRKChJLXm4RIOrjOQdoIaN3taElPOGoHFE0KAzoUjQJnPG wNbQ+Kec4wdGojQJHckhZytiGvb7jReDZs2wL/ZHbhEtNud5YUOCtbjfXJKCCxK4Kedn vPbBcTzg3UITuNZpBT56VcK9k6ZswXiOXcLJHi1DainVAWBqqC9LxNzeXzoeRqjcNSem zeym3epKOdOVXIMR8RtezFUIZGdA6AMjG73JXQ6hV59M3nkqguLWJtQDspAJF9h3GupA GnRFpgCwg2T2T1DbWYQ6FS1N7IHsYgSpddmw8Y2LgPPFAmR8dPMQG+Bi8zKgKehoslWT rp0A== MIME-Version: 1.0 Received: by 10.14.173.65 with SMTP id u41mr8409107eel.13.1354820363109; Thu, 06 Dec 2012 10:59:23 -0800 (PST) Received: by 10.223.173.199 with HTTP; Thu, 6 Dec 2012 10:59:22 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Dec 2012 13:59:22 -0500 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: multipart/alternative; boundary=047d7b6226b07a441b04d033b217 Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:59:24 -0000 --047d7b6226b07a441b04d033b217 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 6, 2012 at 4:06 AM, Randy Bush wrote: > > so glad those filters are working so well today... > > ... > > sure works well today. > > i offer a really nice dinner, probably in berlin, for someone who comes > up with a simple emoticon for dripping sarcasm (apologies for idiomatic > american). > > Okay, I'll bite (with on-topic example usage): Hey, Chris, I love how you show those leaks propagate Internet-wide and cause major problems. ;~> And how opposing new ranges will stop current leaks of 6[45]... from happening, too. ;~> (Note the dripping sarcasm emoticon. :-)) Brian --047d7b6226b07a441b04d033b217 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2012 at 4:06 AM, Randy Bush <randy@psg.com> wrote= :
> so glad those filters are working so well today...
> ...
> sure works well today.

i offer a really nice dinner, probably in berlin, for someone who comes
up with a simple emoticon for dripping sarcasm (apologies for idiomatic
american).


Okay, I'll bite (wit= h on-topic example usage):

Hey, Chris,
<= br>
I love how you show those leaks propagate Internet-wide and c= ause major problems.=A0=A0;~>

And how op= posing new ranges will stop current leaks of 6[45]... from happening, too. = ;~>

(Note the dripping sarcasm emoticon. :-))
Brian
--047d7b6226b07a441b04d033b217-- From christopher.morrow@gmail.com Thu Dec 6 11:09:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EC421F880D for ; Thu, 6 Dec 2012 11:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcnJ6msvPVoE for ; Thu, 6 Dec 2012 11:09:43 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC02321F875B for ; Thu, 6 Dec 2012 11:09:42 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so2893475eaa.31 for ; Thu, 06 Dec 2012 11:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=C7l1XZtv4gpsY12WfmMTXMdnUlpSq7uFs7NRwVoffHA=; b=YmuOnXjq0fTvxu9I2AmB1+wddxnuOkcvd6A1gPufZtWNioa5VQ/g1NSDZcQIUrMIzU bbISn2K9sCAYuRqlxyqyz7I1M6Mmd5hvtGftU9mI4bWc3kH1ActRwktzClbk2wkb9Lri sJ12srxGFhYfuK81+idtKIUIctp8pKKKxIEgpca8cnxUmBDqnq13F0acQ1hHbmdho9cG duGu7YrsxjvJPXGl0tVW/zj0mxr2PME40X5+GnKtX2l87cAHXdWvxYOmgU2cmWKRtGjd K9J5E4KsInzEVLdRSdyWezDNjqUR0Ir7v1SF4GqzRP1JbBHUUWgO9lRhGdbDv3UwpF6d dyYA== MIME-Version: 1.0 Received: by 10.14.184.131 with SMTP id s3mr8238129eem.38.1354820982131; Thu, 06 Dec 2012 11:09:42 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Thu, 6 Dec 2012 11:09:41 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Dec 2012 14:09:41 -0500 X-Google-Sender-Auth: tR3qt9IhQKg1Oa0rIQNMHGu22IU Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:09:43 -0000 On Thu, Dec 6, 2012 at 1:59 PM, Brian Dickson wrote: > Okay, I'll bite (with on-topic example usage): > > Hey, Chris, > > I love how you show those leaks propagate Internet-wide and cause major > problems. ;~> > > And how opposing new ranges will stop current leaks of 6[45]... from > happening, too. ;~> > > (Note the dripping sarcasm emoticon. :-)) I think before I said something like: "Just because all my freinds are failing out of school doesn't make it acceptable for me to as well" (perhaps I said, just because we started down the hill doesn't mean we need rocket engines attached...) why make it more possible to have problems? why not work out the transition to the new spec if it gets approved and moves forward? (note jon will probably do this part) still not a fan of the plan, fyi. -chris From jgs@juniper.net Thu Dec 6 14:42:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAA721F8773 for ; Thu, 6 Dec 2012 14:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mssiAyjC36T1 for ; Thu, 6 Dec 2012 14:42:18 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 11F5F21F8632 for ; Thu, 6 Dec 2012 14:42:18 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUMEfSR99vY4Dhb4Qy2atvZ2OuXUqAFCr@postini.com; Thu, 06 Dec 2012 14:42:18 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 6 Dec 2012 14:39:41 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 6 Dec 2012 14:39:40 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 6 Dec 2012 14:47:19 -0800 Received: from mail194-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Dec 2012 22:39:40 +0000 Received: from mail194-co1 (localhost [127.0.0.1]) by mail194-co1-R.bigfish.com (Postfix) with ESMTP id 0342E480139 for ; Thu, 6 Dec 2012 22:39:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zz4015Izz1de0h1202h1d1ah1d2ah1082kzzz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1155h) Received: from mail194-co1 (localhost.localdomain [127.0.0.1]) by mail194-co1 (MessageSwitch) id 1354833578192429_12727; Thu, 6 Dec 2012 22:39:38 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.225]) by mail194-co1.bigfish.com (Postfix) with ESMTP id 234B4B0006D for ; Thu, 6 Dec 2012 22:39:38 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 6 Dec 2012 22:39:37 +0000 Received: from rameshr-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 6 Dec 2012 22:39:25 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> Date: Thu, 6 Dec 2012 17:39:22 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 22:42:18 -0000 Folks, The authors have requested IDR adopt = draft-svshah-interdomain-sla-exchange-03 as a working group document. Please send any comments to the list by the Winter Solstice (December = 21). Thanks, --John= From chris.hall@highwayman.com Fri Dec 7 04:41:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522A521F8983 for ; Fri, 7 Dec 2012 04:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs83uhP0y3tr for ; Fri, 7 Dec 2012 04:41:30 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tbr.inty.net [91.221.168.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9108721F8961 for ; Fri, 7 Dec 2012 04:41:30 -0800 (PST) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id E1064A0C07F; Fri, 7 Dec 2012 12:41:28 +0000 (GMT) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id B914CA0C073; Fri, 7 Dec 2012 12:41:28 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tbr.inty.net (Postfix) with ESMTP; Fri, 7 Dec 2012 12:41:28 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TgxF9-0005cK-Sq; Fri, 07 Dec 2012 12:41:27 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com>, <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> In-Reply-To: <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> Date: Fri, 7 Dec 2012 12:41:22 -0000 Organization: Highwayman Message-ID: <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAl418ofA= Content-Language: en-gb X-MDF-HostID: 9 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 12:41:31 -0000 Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000): > Some length errors will not be detected as length errors, but as > misinterpretation of subsequent bytes. The draft appears to be relaxing everything in sight, so there are indeed few (if any) length errors per se left; or many other errors for that matter. Also, the relaxation means that almost any pair of octets are acceptable Attribute Flags and Type. And, as far as I can see, a final attribute which overruns the end of the attributes part of the message (as defined by the 'Total Attributes Length') is also acceptable. By "error" I assume we mean something which would today trigger a session-reset. By "acceptable" I mean "does not trigger a session-reset" -- the result may or may not appear to be "malformed". Given that most Type values are unknown, a broken length in an attribute is likely to result in the rest of the attributes part of the message being interpreted as a number of unknown attributes, the last of which will probably overrun the end... all of which is "acceptable" and only the last "malformed". For almost all cases of broken attribute(s), the draft requires: "the UPDATE message containing the attribute MUST be treated as if all contained routes had been withdrawn". Except, the draft does: "observe that in order to use the approach of 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed". It seems to me that "successfully parsing" MP_REACH_NLRI and MP_UNREACH_NLRI attributes must include knowing when they are NOT there. Suppose the code has "parsed" a set of attributes, one or more of which is "malformed", and has managed to extract a valid MP_UNREACH_NLRI attribute. Should it "treat-as-withdraw" ? The smart money would be on there being an MP_REACH_NLRI somewhere amongst the broken attributes... unless there were some vanilla IPv4 Unicast NLRI. Also ambiguous is the case where an MP_REACH_NLRI has been extracted: is there an MP_UNREACH_NLRI buried under the malformed stuff ? In short, as far as I can see, the draft requires: * "treat-as-withdraw" for almost every conceivable case of "malformed" attribute(s). * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are "successfully parsed". which appear to be mutually exclusive in many cases :-( The only (not session-reset) case where there is no ambiguity is when *both* MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which, unfortunately, is not a very useful case in practice. (There is also no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but invalid. And no ambiguity if one or both of them is repeated. But those are session-reset cases.) .... > If you get a message length too long error, the most likely result > will be that you misinterpret the 0xFF's as NLRI and get an NLRI > length error. Blimy. That suggests reading beyond the various boundaries established by the 'Message Length', 'Withdrawn Routes Length' and 'Total Attribute Length'... surely not ?! Chris From enkechen@cisco.com Fri Dec 7 11:17:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E247C21F8646 for ; Fri, 7 Dec 2012 11:17:22 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eWfkP3p-2Rh for ; Fri, 7 Dec 2012 11:17:22 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7E621F86C3 for ; Fri, 7 Dec 2012 11:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4146; q=dns/txt; s=iport; t=1354907842; x=1356117442; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=t9P3ZGnuD8M+7rWfd3EHYbqwmlGZGS7Q187YyEUrjDE=; b=UhvQir9UOoBPS5zcdiJHBE5/Spd3exLbtneDhmwIKoSqo6ZKkV7nIdIO qBykabcSt3GnKjP0NbAIZfC/1cNnlZgd6lc6p9/KDc0x67vlxb/mrC1rA q2NLLiPHgr2JY0p+3NXZ+LF7J+eWnLNJ3oaHEEKDEyY0iRmTSda9VOMPv E=; X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="62884970" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 07 Dec 2012 19:17:20 +0000 Received: from [171.71.139.31] (dhcp-171-71-139-31.cisco.com [171.71.139.31]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB7JHKG6013865; Fri, 7 Dec 2012 19:17:20 GMT Message-ID: <50C240C0.6070609@cisco.com> Date: Fri, 07 Dec 2012 11:17:20 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Chris Hall References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> In-Reply-To: <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:17:23 -0000 Hi, Chris: On 12/6/12 5:21 AM, Chris Hall wrote: > I've been trying to adjust the error handling in Quagga bgpd to follow > this draft, without success. > > If an update message arrives and there is a problem with one or more > significant attributes, then if (and only if) *all* the NLRI in the > update can be identified, then treat-as-withdraw is an excellent > alternative to crashing the entire session. > > This much is clear, and clearly a step forward. If only it were > possible to "parse" attributes individually.... > > ....but since it is not: when faced with a broken set of attributes, I > do not see how the receiver can be certain that it has correctly and > completely identified all NLRI. > > RFC4271 allows for an update to contain any and all combinations of > vanilla IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI > (also reachable and/or unreachable). Given that one broken attribute > may obscure following ones, the receiver can be certain that it has > correctly and completely identified all NLRI if, and only if, it has > extracted *both* a complete MP_REACH_NLRI *and* a complete > MP_UNREACH_NLRI attribute. Otherwise, the receiver must, in effect, > prove a negative: that one or both attributes were not sent. > > The draft acknowledges the issue, and requires that "the MP_REACH_NLRI > or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very > first path attribute" (should that be "and/or" rather than "or" ?). > How is the receiver to know that the sender is following this new rule > ? Can it simply assume that to be the case ? Apparently the answers > are: it cannot and may not, in that order -- since the draft also says > "... MUST still be prepared to receive these fields in any position". When parsing the path attributes, the receiver knows definitely whether the MP_REACH_NLRI or MP_UNREACH_NLRI attribute is the very first path attribute. If it is the first path attribute, life would be better w.r.t the error handling. If it is not (as is the case with the old code), it can be tricky and disruptive. The situation will progressively improve with the continuous rollout of new code. Another practical detail that helps error handling in some cases is that vendors are not encoding multiple NLRI fields in one UPDATE message (as least I am not aware of any that does). -- Enke > > If the receiver cannot know (or simply assume) that the new rule is > being followed, then given a broken set of attributes: > > * if there are vanilla IPv4 NLRI: > > - can it be assumed that there are no MP NLRI > if none can be extracted ? > > * if there are no vanilla IPv4 NLRI: > > - can it be assumed that if MP_REACH_NLRI can be > extracted then there will be no MP_UNREACH_NLRI ? > > - if the only attribute is MP_UNREACH_NLRI then > everything is fine. > > But if any other attribute is present, if no > MP_REACH_NLRI can be extracted, should the > receiver assume that one is missing (hidden by > a broken attribute) ? > > The answer to that appears, currently, to be yes. > But that excludes, forever, the ability to attach > extra information to a withdraw update. > > - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI > can be extracted, can it be assumed that this > is an empty UPDATE ? Or is this a session- > crashing-error ? > > Of course, if the session is only carrying vanilla IPv4 Unicast, life > is easy. > > But otherwise, it seems to me that in order to make use of the > "treat-as-withdraw" mechanism, the receiver of a broken set of > attributes has to make some significant assumptions about the > behaviour of the sender. I do not know which, if any, of those > assumptions it is safe to make. > > I am, of course, assuming that having received a broken UPDATE, it is > *essential* to avoid continuing with the session unless *all* NLRI > referred to in that UPDATE have been "treated-as-withdraw". > > Chris > From shyam.ioml@gmail.com Fri Dec 7 13:55:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5D21F880D for ; Fri, 7 Dec 2012 13:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdjF91ARltxi for ; Fri, 7 Dec 2012 13:55:43 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8521F87E1 for ; Fri, 7 Dec 2012 13:55:42 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so925459vcb.31 for ; Fri, 07 Dec 2012 13:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nj4PGLykVx5ucQqm8qi5r07gH1n39mfqEeXDSOUmcRg=; b=ZzdA3rFTuJ4cSXX4goU7iNcNlWhEvKVlod2/19D2C3WiwBB50ki29VXr4C5blKNPtL /DlMpKxTXE9ZG3LUs5N/LVj3b5SMjtXrlorlPouQGNXETYPldOj90Tcv2xs2Tz5t50wl 7lMFWRSLHHsAMoCOSHeXC2hAHLslBSrC90V1o+spWbo6DbntdnVWjkeiYboG3CorT/VQ puLiUewKUr5s2WBCFqHM3zZ4uZY6Vctk8nKcK/rTpNPi5IaGWWr1Z2rpaTfeWL5rQ8BK yomwLpFbRR0rt3pv9i+jtDNLYA0o74f+aVuZGSjJQSanNzJbXBJ/250Ggh4uUA6jUzoQ Dwrw== MIME-Version: 1.0 Received: by 10.58.198.135 with SMTP id jc7mr4714798vec.51.1354917342167; Fri, 07 Dec 2012 13:55:42 -0800 (PST) Received: by 10.58.215.10 with HTTP; Fri, 7 Dec 2012 13:55:41 -0800 (PST) In-Reply-To: <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> Date: Fri, 7 Dec 2012 13:55:41 -0800 Message-ID: From: Shyam Sethuram To: Chris Hall Content-Type: multipart/alternative; boundary=047d7b5d8cd7e1434e04d04a46bc Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 21:55:44 -0000 --047d7b5d8cd7e1434e04d04a46bc Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall wrote: > Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000): > > Some length errors will not be detected as length errors, but as > > misinterpretation of subsequent bytes. > > The draft appears to be relaxing everything in sight, so there are > indeed few (if any) length errors per se left; or many other errors > for that matter. Also, the relaxation means that almost any pair of > octets are acceptable Attribute Flags and Type. One attribute follows another. There's really no way to tell what pairs of octets are really acceptable as Flags and Type. > And, as far as I can > see, a final attribute which overruns the end of the attributes part > of the message (as defined by the 'Total Attributes Length') is also > acceptable. > You can reset the session at this point if you haven't come across MP_REACH so far and know that IPv4 NLRI length is 0. > > By "error" I assume we mean something which would today trigger a > session-reset. By "acceptable" I mean "does not trigger a > session-reset" -- the result may or may not appear to be "malformed". > Given that most Type values are unknown, a broken length in an > attribute is likely to result in the rest of the attributes part of > the message being interpreted as a number of unknown attributes, the > last of which will probably overrun the end... all of which is > "acceptable" and only the last "malformed". > > For almost all cases of broken attribute(s), the draft requires: "the > UPDATE message containing the attribute MUST be treated as if all > contained routes had been withdrawn". > > Except, the draft does: "observe that in order to use the approach of > 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI > and MP_UNREACH_NLRI attributes need to be successfully parsed". > > It seems to me that "successfully parsing" MP_REACH_NLRI and > MP_UNREACH_NLRI attributes must include knowing when they are NOT > there. > > Suppose the code has "parsed" a set of attributes, one or more of > which is "malformed", and has managed to extract a valid > MP_UNREACH_NLRI attribute. Should it "treat-as-withdraw" ? The smart > money would be on there being an MP_REACH_NLRI somewhere amongst the > broken attributes... unless there were some vanilla IPv4 Unicast NLRI. > Also ambiguous is the case where an MP_REACH_NLRI has been extracted: > is there an MP_UNREACH_NLRI buried under the malformed stuff ? > > In short, as far as I can see, the draft requires: > > * "treat-as-withdraw" for almost every conceivable case > of "malformed" attribute(s). > > * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are > "successfully parsed". > > which appear to be mutually exclusive in many cases :-( The only (not > session-reset) case where there is no ambiguity is when *both* > MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which, > unfortunately, is not a very useful case in practice. (There is also > no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but > invalid. And no ambiguity if one or both of them is repeated. But > those are session-reset cases.) > IMO, MP_UNREACH_NLRI does not enter the picture here. The test for NLRI presence for the scenario you described is limited to plain IPv4 NLRI and/or MP_REACH_NLRI. > > .... > > If you get a message length too long error, the most likely result > > will be that you misinterpret the 0xFF's as NLRI and get an NLRI > > length error. > > Blimy. That suggests reading beyond the various boundaries > established by the 'Message Length', 'Withdrawn Routes Length' and > 'Total Attribute Length'... surely not ?! > IMO there's no scenario where this is needed or implied by the draft. shyam > > Chris > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b5d8cd7e1434e04d04a46bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chris,
On Fri, Dec 7, 2012 at 4:41 AM, Chr= is Hall <chris.hall@highwayman.com> wrote:
Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000):
> Some length errors will not be detected as length errors, but as
> misinterpretation of subsequent bytes.

The draft appears to be relaxing everything in sight, so there are
indeed few (if any) length errors per se left; or many other errors
for that matter. =A0Also, the relaxation means that almost any pair of
octets are acceptable Attribute Flags and Type. =A0
=A0
One attribute follows another. There's really no way to tell
what pairs of octets are really acceptable as Flags and Type.
=A0
And, as far as I can
see, a final attribute which overruns the end of the attributes part
of the message (as defined by the 'Total Attributes Length') is als= o
acceptable.
=A0
You can reset the session at= this point if you haven't come
across MP_REACH so far and kn= ow that IPv4 NLRI length is 0.
=A0

By "error" I assume we mean something which would today trigger a=
session-reset. =A0By "acceptable" I mean "does not trigger a=
session-reset" -- the result may or may not appear to be "malform= ed".
Given that most Type values are unknown, a broken length in an
attribute is likely to result in the rest of the attributes part of
the message being interpreted as a number of unknown attributes, the
last of which will probably overrun the end... all of which is
"acceptable" and only the last "malformed".

For almost all cases of broken attribute(s), the draft requires: "the<= br> UPDATE message containing the attribute MUST be treated as if all
contained routes had been withdrawn".

Except, the draft does: "observe that in order to use the approach of<= br> 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI=
and MP_UNREACH_NLRI attributes need to be successfully parsed".

It seems to me that "successfully parsing" MP_REACH_NLRI and
MP_UNREACH_NLRI attributes must include knowing when they are NOT
there.

Suppose the code has "parsed" a set of attributes, one or more of=
which is "malformed", and has managed to extract a valid
MP_UNREACH_NLRI attribute. =A0Should it "treat-as-withdraw" ? =A0= The smart
money would be on there being an MP_REACH_NLRI somewhere amongst the
broken attributes... unless there were some vanilla IPv4 Unicast NLRI.
Also ambiguous is the case where an MP_REACH_NLRI has been extracted:
is there an MP_UNREACH_NLRI buried under the malformed stuff ?

In short, as far as I can see, the draft requires:

=A0 * "treat-as-withdraw" for almost every conceivable case
=A0 =A0 of "malformed" attribute(s).

=A0 * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are
=A0 =A0 "successfully parsed".

which appear to be mutually exclusive in many cases :-( =A0The only (not session-reset) case where there is no ambiguity is when *both*
MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which,
unfortunately, is not a very useful case in practice. =A0(There is also
no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but
invalid. =A0And no ambiguity if one or both of them is repeated. =A0But
those are session-reset cases.)
=A0
IMO, MP_= UNREACH_NLRI does not enter the picture here. The
test for NLRI p= resence for the scenario you described is limited
to plain IPv4= =A0NLRI and/or MP_REACH_NLRI.
=A0
=A0

....
> If you get a message length too long error, the most likely result
> will be that you misinterpret the 0xFF's as NLRI and get an NLRI > length error.

Blimy. =A0That suggests reading beyond the various boundaries
established by the 'Message Length', 'Withdrawn Routes Length&#= 39; and
'Total Attribute Length'... surely not ?!
=A0<= /div>
IMO there's no scenario where this is needed or implied
=
by the draft.
=A0
shyam
=A0

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b5d8cd7e1434e04d04a46bc-- From brian.peter.dickson@gmail.com Fri Dec 7 15:12:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C621F8BC4 for ; Fri, 7 Dec 2012 15:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOfkBOw3Fmai for ; Fri, 7 Dec 2012 15:12:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0B21F8BBE for ; Fri, 7 Dec 2012 15:12:57 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so626377eek.31 for ; Fri, 07 Dec 2012 15:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVl+oZ+aXucf8/fIjx1zGTiTq6UMF+ukTTZtL2Wa8ZA=; b=dGUqAefyW1e1PpznSKrGRb1tUc94xpYXHT/VGX24ChAaqmnrWXFqGjd96mIJlvyq+u 8J05JUaoDJSFjrDjHABhRclEu8hu7qXf44nbNLLlWFJluB8J38RcB9SROqckCupTbKCM fF2PbvJa8NX69rcA8gDnBxRHzP/nU0Eecxd0n/MCE+mQS/mzGYVOtAmPw1/qGy0PaHK1 TYrtSFa75FeONAOl/LZ7dK7yqhlE/H1WOEPmFdY8pPkrTSs6Fr5eJseILyq0ygIB2xqr YWJB7HeUukxQCNJsvCgIpyKO/1G7q3XUNzuGKK3jSncgwijLlgRrP738JxCacmvlhYix 0iyQ== MIME-Version: 1.0 Received: by 10.14.206.197 with SMTP id l45mr22051415eeo.17.1354921977206; Fri, 07 Dec 2012 15:12:57 -0800 (PST) Received: by 10.223.173.199 with HTTP; Fri, 7 Dec 2012 15:12:57 -0800 (PST) In-Reply-To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> Date: Fri, 7 Dec 2012 18:12:57 -0500 Message-ID: From: Brian Dickson To: Shyam Sethuram Content-Type: multipart/alternative; boundary=047d7b34413c26560504d04b5b8d Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:12:59 -0000 --047d7b34413c26560504d04b5b8d Content-Type: text/plain; charset=ISO-8859-1 I see the high-level problem Chris describes, and think maybe it requires discussing possible ways of removing doubt/ambiguity over successful parsing of such MP_REACH and MP_UNREACH attributes. For instance, on a given BGP session, negotiation on a per-(AFI,SAFI) is done to establish which MP things are to be sent. Perhaps it would be a reasonable additional requirement to have every UPDATE include 2*N attributes for N afi/safi classes, where the 2 is REACH and UNREACH? Also, if IPv4 is negotiated as an MP type, should it maybe be required to be done via MP and _not_ via non-MP (vanilla) type? That way, only if all the REACH/UNREACH decode successfully, and appropriate additional types are present (based on 4470 rules), it is possible to validate that sufficient detail is available for the error handling. Thoughts? Brian On Fri, Dec 7, 2012 at 4:55 PM, Shyam Sethuram wrote: > Hi Chris, > On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall wrote: > >> Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000): >> > Some length errors will not be detected as length errors, but as >> > misinterpretation of subsequent bytes. >> >> The draft appears to be relaxing everything in sight, so there are >> indeed few (if any) length errors per se left; or many other errors >> for that matter. Also, the relaxation means that almost any pair of >> octets are acceptable Attribute Flags and Type. > > > One attribute follows another. There's really no way to tell > what pairs of octets are really acceptable as Flags and Type. > > >> And, as far as I can >> see, a final attribute which overruns the end of the attributes part >> of the message (as defined by the 'Total Attributes Length') is also >> acceptable. >> > > You can reset the session at this point if you haven't come > across MP_REACH so far and know that IPv4 NLRI length is 0. > > >> >> By "error" I assume we mean something which would today trigger a >> session-reset. By "acceptable" I mean "does not trigger a >> session-reset" -- the result may or may not appear to be "malformed". >> Given that most Type values are unknown, a broken length in an >> attribute is likely to result in the rest of the attributes part of >> the message being interpreted as a number of unknown attributes, the >> last of which will probably overrun the end... all of which is >> "acceptable" and only the last "malformed". >> >> For almost all cases of broken attribute(s), the draft requires: "the >> UPDATE message containing the attribute MUST be treated as if all >> contained routes had been withdrawn". >> >> Except, the draft does: "observe that in order to use the approach of >> 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI >> and MP_UNREACH_NLRI attributes need to be successfully parsed". >> >> It seems to me that "successfully parsing" MP_REACH_NLRI and >> MP_UNREACH_NLRI attributes must include knowing when they are NOT >> there. >> >> Suppose the code has "parsed" a set of attributes, one or more of >> which is "malformed", and has managed to extract a valid >> MP_UNREACH_NLRI attribute. Should it "treat-as-withdraw" ? The smart >> money would be on there being an MP_REACH_NLRI somewhere amongst the >> broken attributes... unless there were some vanilla IPv4 Unicast NLRI. >> Also ambiguous is the case where an MP_REACH_NLRI has been extracted: >> is there an MP_UNREACH_NLRI buried under the malformed stuff ? >> >> In short, as far as I can see, the draft requires: >> >> * "treat-as-withdraw" for almost every conceivable case >> of "malformed" attribute(s). >> >> * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are >> "successfully parsed". >> >> which appear to be mutually exclusive in many cases :-( The only (not >> session-reset) case where there is no ambiguity is when *both* >> MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which, >> unfortunately, is not a very useful case in practice. (There is also >> no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but >> invalid. And no ambiguity if one or both of them is repeated. But >> those are session-reset cases.) >> > > IMO, MP_UNREACH_NLRI does not enter the picture here. The > test for NLRI presence for the scenario you described is limited > to plain IPv4 NLRI and/or MP_REACH_NLRI. > > >> > > >> .... >> > If you get a message length too long error, the most likely result >> > will be that you misinterpret the 0xFF's as NLRI and get an NLRI >> > length error. >> >> Blimy. That suggests reading beyond the various boundaries >> established by the 'Message Length', 'Withdrawn Routes Length' and >> 'Total Attribute Length'... surely not ?! >> > > IMO there's no scenario where this is needed or implied > by the draft. > > shyam > > >> >> Chris >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --047d7b34413c26560504d04b5b8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see the high-level problem Chris describes, and think maybe it requires d= iscussing possible ways of removing doubt/ambiguity over successful parsing= of such MP_REACH and MP_UNREACH attributes.

For instanc= e, on a given BGP session, negotiation on a per-(AFI,SAFI) is done to estab= lish which MP things are to be sent.
Perhaps it would be a reasonable additional requirement to have every = UPDATE include 2*N attributes for N afi/safi classes, where the 2 is REACH = and UNREACH?
Also, if IPv4 is negotiated as an MP type, should it= maybe be required to be done via MP and _not_ via non-MP (vanilla) type?

That way, only if all the REACH/UNREACH decode successf= ully, and appropriate additional types are present (based on 4470 rules), i= t is possible to validate that sufficient detail is available for the error= handling.

Thoughts?

Brian

On Fri, Dec 7, 2012 at 4:55 PM, Shyam Sethuram <shy= am.ioml@gmail.com> wrote:
Hi Chris,
On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall = <chris.ha= ll@highwayman.com> wrote:
Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000):
> Some length errors will not be detected as length errors, but as
> misinterpretation of subsequent bytes.

The draft appears to be relaxing everything in sight, so there are
indeed few (if any) length errors per se left; or many other errors
for that matter. =A0Also, the relaxation means that almost any pair of
octets are acceptable Attribute Flags and Type. =A0
=A0
One attribute follows another. There's really no way to t= ell
what pairs of octets are really acceptable as Flags and Type.=
=A0
And, as far as I can
see, a final attribute which overruns the end of the attributes part
of the message (as defined by the 'Total Attributes Length') is als= o
acceptable.
=A0
You can reset the sess= ion at this point if you haven't come
across MP_REACH so far = and know that IPv4 NLRI length is 0.
=A0

By "error" I assume we mean something which would today trigger a=
session-reset. =A0By "acceptable" I mean "does not trigger a=
session-reset" -- the result may or may not appear to be "malform= ed".
Given that most Type values are unknown, a broken length in an
attribute is likely to result in the rest of the attributes part of
the message being interpreted as a number of unknown attributes, the
last of which will probably overrun the end... all of which is
"acceptable" and only the last "malformed".

For almost all cases of broken attribute(s), the draft requires: "the<= br> UPDATE message containing the attribute MUST be treated as if all
contained routes had been withdrawn".

Except, the draft does: "observe that in order to use the approach of<= br> 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI=
and MP_UNREACH_NLRI attributes need to be successfully parsed".

It seems to me that "successfully parsing" MP_REACH_NLRI and
MP_UNREACH_NLRI attributes must include knowing when they are NOT
there.

Suppose the code has "parsed" a set of attributes, one or more of=
which is "malformed", and has managed to extract a valid
MP_UNREACH_NLRI attribute. =A0Should it "treat-as-withdraw" ? =A0= The smart
money would be on there being an MP_REACH_NLRI somewhere amongst the
broken attributes... unless there were some vanilla IPv4 Unicast NLRI.
Also ambiguous is the case where an MP_REACH_NLRI has been extracted:
is there an MP_UNREACH_NLRI buried under the malformed stuff ?

In short, as far as I can see, the draft requires:

=A0 * "treat-as-withdraw" for almost every conceivable case
=A0 =A0 of "malformed" attribute(s).

=A0 * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are
=A0 =A0 "successfully parsed".

which appear to be mutually exclusive in many cases :-( =A0The only (not session-reset) case where there is no ambiguity is when *both*
MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which,
unfortunately, is not a very useful case in practice. =A0(There is also
no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but
invalid. =A0And no ambiguity if one or both of them is repeated. =A0But
those are session-reset cases.)
=A0
<= div>IMO, MP_UNREACH_NLRI does not enter the picture here. The
tes= t for NLRI presence for the scenario you described is limited
to plain IPv4=A0NLRI and/or MP_REACH_NLRI.
=A0
=A0

....
> If you get a message length too long error, the most likely result
> will be that you misinterpret the 0xFF's as NLRI and get an NLRI > length error.

Blimy. =A0That suggests reading beyond the various boundaries
established by the 'Message Length', 'Withdrawn Routes Length&#= 39; and
'Total Attribute Length'... surely not ?!
=A0<= /div>
IMO there's no scenario where this is needed or implied=
by the draft.
=A0
shyam
=A0

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--047d7b34413c26560504d04b5b8d-- From jakob.heitz@ericsson.com Fri Dec 7 15:23:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA06221F8784 for ; Fri, 7 Dec 2012 15:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22FkHZYxetEK for ; Fri, 7 Dec 2012 15:23:31 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0DD21F8773 for ; Fri, 7 Dec 2012 15:23:31 -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 qB7NXDqn025070; Fri, 7 Dec 2012 17:33:15 -0600 Received: from EUSAAHC007.ericsson.se (147.117.188.93) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Dec 2012 18:23:24 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 18:23:24 -0500 From: Jakob Heitz To: Brian Dickson , Shyam Sethuram Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCqgAGK/gCAAJrggIAAFZeA//+t8ZA= Date: Fri, 7 Dec 2012 23:23:23 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E10B7BA@eusaamb109.ericsson.se> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10B7BAeusaamb109ericsso_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:23:32 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10B7BAeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had previously suggested an "end of attribute list" attribute. However, a goal of this draft is not to require any change to peers. Anything that requires changes on both sides of a connection is going to be radically different. -- Jakob Heitz. ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian= Dickson Sent: Friday, December 07, 2012 3:13 PM To: Shyam Sethuram Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt I see the high-level problem Chris describes, and think maybe it requires d= iscussing possible ways of removing doubt/ambiguity over successful parsing= of such MP_REACH and MP_UNREACH attributes. For instance, on a given BGP session, negotiation on a per-(AFI,SAFI) is do= ne to establish which MP things are to be sent. Perhaps it would be a reasonable additional requirement to have every UPDAT= E include 2*N attributes for N afi/safi classes, where the 2 is REACH and U= NREACH? Also, if IPv4 is negotiated as an MP type, should it maybe be required to b= e done via MP and _not_ via non-MP (vanilla) type? That way, only if all the REACH/UNREACH decode successfully, and appropriat= e additional types are present (based on 4470 rules), it is possible to val= idate that sufficient detail is available for the error handling. Thoughts? Brian On Fri, Dec 7, 2012 at 4:55 PM, Shyam Sethuram > wrote: Hi Chris, On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall > wrote: Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000): > Some length errors will not be detected as length errors, but as > misinterpretation of subsequent bytes. The draft appears to be relaxing everything in sight, so there are indeed few (if any) length errors per se left; or many other errors for that matter. Also, the relaxation means that almost any pair of octets are acceptable Attribute Flags and Type. One attribute follows another. There's really no way to tell what pairs of octets are really acceptable as Flags and Type. And, as far as I can see, a final attribute which overruns the end of the attributes part of the message (as defined by the 'Total Attributes Length') is also acceptable. You can reset the session at this point if you haven't come across MP_REACH so far and know that IPv4 NLRI length is 0. By "error" I assume we mean something which would today trigger a session-reset. By "acceptable" I mean "does not trigger a session-reset" -- the result may or may not appear to be "malformed". Given that most Type values are unknown, a broken length in an attribute is likely to result in the rest of the attributes part of the message being interpreted as a number of unknown attributes, the last of which will probably overrun the end... all of which is "acceptable" and only the last "malformed". For almost all cases of broken attribute(s), the draft requires: "the UPDATE message containing the attribute MUST be treated as if all contained routes had been withdrawn". Except, the draft does: "observe that in order to use the approach of 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed". It seems to me that "successfully parsing" MP_REACH_NLRI and MP_UNREACH_NLRI attributes must include knowing when they are NOT there. Suppose the code has "parsed" a set of attributes, one or more of which is "malformed", and has managed to extract a valid MP_UNREACH_NLRI attribute. Should it "treat-as-withdraw" ? The smart money would be on there being an MP_REACH_NLRI somewhere amongst the broken attributes... unless there were some vanilla IPv4 Unicast NLRI. Also ambiguous is the case where an MP_REACH_NLRI has been extracted: is there an MP_UNREACH_NLRI buried under the malformed stuff ? In short, as far as I can see, the draft requires: * "treat-as-withdraw" for almost every conceivable case of "malformed" attribute(s). * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are "successfully parsed". which appear to be mutually exclusive in many cases :-( The only (not session-reset) case where there is no ambiguity is when *both* MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which, unfortunately, is not a very useful case in practice. (There is also no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but invalid. And no ambiguity if one or both of them is repeated. But those are session-reset cases.) IMO, MP_UNREACH_NLRI does not enter the picture here. The test for NLRI presence for the scenario you described is limited to plain IPv4 NLRI and/or MP_REACH_NLRI. .... > If you get a message length too long error, the most likely result > will be that you misinterpret the 0xFF's as NLRI and get an NLRI > length error. Blimy. That suggests reading beyond the various boundaries established by the 'Message Length', 'Withdrawn Routes Length' and 'Total Attribute Length'... surely not ?! IMO there's no scenario where this is needed or implied by the draft. shyam Chris _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10B7BAeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I had previously suggest= ed an "end of attribute list" attribute.
 
However, a goal of this = draft is not to require any change to peers.
Anything that requires c= hanges on both sides of a connection
is going to be radically= different.

-- Jakob Heitz.

 

From: idr-bounces@ietf.org [mailto:= idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Friday, December 07, 2012 3:13 PM
To: Shyam Sethuram
Cc: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt<= br>
I see the high-level problem Chris describes, and think maybe it requires d= iscussing possible ways of removing doubt/ambiguity over successful parsing= of such MP_REACH and MP_UNREACH attributes.

For instance, on a given BGP session, negotiation on a per-(AFI,SAFI) = is done to establish which MP things are to be sent.
Perhaps it would be a reasonable additional requirement to have every = UPDATE include 2*N attributes for N afi/safi classes, where the 2 is REACH = and UNREACH?
Also, if IPv4 is negotiated as an MP type, should it maybe be required= to be done via MP and _not_ via non-MP (vanilla) type?

That way, only if all the REACH/UNREACH decode successfully, and appro= priate additional types are present (based on 4470 rules), it is possible t= o validate that sufficient detail is available for the error handling.

Thoughts?

Brian

On Fri, Dec 7, 2012 at 4:55 PM, Shyam Sethuram <= span dir=3D"ltr"> <shyam.ioml@gm= ail.com> wrote:
Hi Chris,
On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall <chri= s.hall@highwayman.com> wrote:
Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000):
> Some length errors will not be detected as length errors, but as
> misinterpretation of subsequent bytes.

The draft appears to be relaxing everything in sight, so there are
indeed few (if any) length errors per se left; or many other errors
for that matter.  Also, the relaxation means that almost any pair of octets are acceptable Attribute Flags and Type.  
 
One attribute follows another. There's really no way to tell
what pairs of octets are really acceptable as Flags and Type.
 
And, as far as I can
see, a final attribute which overruns the end of the attributes part
of the message (as defined by the 'Total Attributes Length') is also
acceptable.
 
You can reset the session at this point if you haven't come
across MP_REACH so far and know that IPv4 NLRI length is 0.
 

By "error" I assume we mean something which would today trigger a=
session-reset.  By "acceptable" I mean "does not trigge= r a
session-reset" -- the result may or may not appear to be "malform= ed".
Given that most Type values are unknown, a broken length in an
attribute is likely to result in the rest of the attributes part of
the message being interpreted as a number of unknown attributes, the
last of which will probably overrun the end... all of which is
"acceptable" and only the last "malformed".

For almost all cases of broken attribute(s), the draft requires: "the<= br> UPDATE message containing the attribute MUST be treated as if all
contained routes had been withdrawn".

Except, the draft does: "observe that in order to use the approach of<= br> 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI
and MP_UNREACH_NLRI attributes need to be successfully parsed".

It seems to me that "successfully parsing" MP_REACH_NLRI and
MP_UNREACH_NLRI attributes must include knowing when they are NOT
there.

Suppose the code has "parsed" a set of attributes, one or more of=
which is "malformed", and has managed to extract a valid
MP_UNREACH_NLRI attribute.  Should it "treat-as-withdraw" ? =  The smart
money would be on there being an MP_REACH_NLRI somewhere amongst the
broken attributes... unless there were some vanilla IPv4 Unicast NLRI.
Also ambiguous is the case where an MP_REACH_NLRI has been extracted:
is there an MP_UNREACH_NLRI buried under the malformed stuff ?

In short, as far as I can see, the draft requires:

  * "treat-as-withdraw" for almost every conceivable case     of "malformed" attribute(s).

  * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are
    "successfully parsed".

which appear to be mutually exclusive in many cases :-(  The only (not=
session-reset) case where there is no ambiguity is when *both*
MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which,
unfortunately, is not a very useful case in practice.  (There is also<= br> no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but
invalid.  And no ambiguity if one or both of them is repeated.  B= ut
those are session-reset cases.)
 
IMO, MP_UNREACH_NLRI does not enter the picture here. The
test for NLRI presence for the scenario you described is limited
to plain IPv4 NLRI and/or MP_REACH_NLRI.
 
 

....
> If you get a message length too long error, the most likely result
> will be that you misinterpret the 0xFF's as NLRI and get an NLRI
> length error.

Blimy.  That suggests reading beyond the various boundaries
established by the 'Message Length', 'Withdrawn Routes Length' and
'Total Attribute Length'... surely not ?!
 
IMO there's no scenario where this is needed or implied
by the draft.
 
shyam
 

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10B7BAeusaamb109ericsso_-- From danny@tcb.net Fri Dec 7 15:35:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A992A21F86E8 for ; Fri, 7 Dec 2012 15:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SONR+avRgyCx for ; Fri, 7 Dec 2012 15:35:48 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 215F121F878D for ; Fri, 7 Dec 2012 15:35:48 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D13E4300093 for ; Fri, 7 Dec 2012 23:35:47 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 20393300091; Fri, 7 Dec 2012 16:35:46 -0700 (MST) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2012 18:35:46 -0500 References: To: "grow@ietf.org grow@ietf.org" , idr wg Message-Id: <09E34042-DFEB-4360-9D7B-6C7986952B80@tcb.net> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Dec 7 16:35:47 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50c27d53199631316253122 X-DSPAM-Factors: 27, Mime-Version*Message+#+v1283, 0.01000, To*wg+#+ietf.org, 0.01000, 2012+at, 0.01000, To*idr+#+#+ietf.org, 0.01000, at+#+#+PM, 0.01000, To*wg+idr, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, To*idr+ietf.org, 0.01000, To*idr+wg, 0.01000, To*idr+#+idr, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, 2012+#+#+#+PM, 0.01000, 2012+#+#+#+PM, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, to+be, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, e+g, 0.01000, Mime-Version*Apple+Message, 0.01000, of+the, 0.01000, of+the, 0.01000, From*McPherson+danny, 0.01000 Subject: [Idr] Fwd: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:35:48 -0000 [apologies in advance for cross-post]=20 An example of why some of the work in SIDR is making me uneasy, = particularly given they're currently aiming for standards track at the = moment.. I'll just note that this is *your* BGP system they're talking about.. -danny Begin forwarded message: > From: Danny McPherson > Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol > Date: December 7, 2012 6:24:00 PM EST > To: "Murphy, Sandra" > Cc: "sidr@ietf.org" >=20 >=20 > On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote: >=20 >> =46rom comments made at the mike in the last IETG sidr session after = the discussion of key rollover techniques, I think there might be a bit = of confusion about beaconing. >>=20 >> An Expire Time was a feature of the bgpsec protocol in versions = 00-01. The purpose of the Expire Time was to prevent replay and ensure = freshness. The effect of this feature was to require periodic = readvertisements of all prefixes, hence the name "beaconing". >>=20 >> Based on wg discussions, "beaconing" was removed from the bgpsec = protocol in versions 02 (Mar 12) forward. >>=20 >> Protection against human time scale replay, e.g., from neighbor = relationships that change, was suggested to be possible through the use = of key rollover. >=20 >=20 > I'm pretty sure the captured proceedings for "Discussion of Key = Rollover Mechanisms for Replay-Attack Protection" [!=3Dbeacon?] mentions = "beacon" at least eleven times. Additionally, "BGPSEC router key = rollover" was about periodic updates (aka "beacons") as well. >=20 > Folks can name them periodic updates, or beacons, or even stretch and = call them triggered updates if you want. Adding new attributes to = standards-track BGP that require a "refresh" function through *some* new = attribute by the origin AND independently by each transit AS (and = perhaps each BGPSEC-enabled BGP router therein) under the auspices of = "key rollover" rather than "freshness" is, well, still pretty much the = same thing functionally - they're still periodic updates in a soft state = protocol that don't exist in BGP today. >=20 > I still contend that doing anything to introduce periodic updates in = the global inter-domain routing system is a terrible idea and is = something we should avoid altogether. Even [ripv1-rfc1058] provides = some hints as to why this is a bad idea. >=20 > I know we're focusing on hyper-deduced stuff here, but the = combinatorial effects of orders of magnitude larger updates in BGP = through BGPSEC proposals, breaking and effectively disabling the ability = for BGP update packing anywhere, considerable added churn through = origination and transit node-triggered "beacons", and added processing = overhead for cryptographic functions for signing and validation, all in = today's BGP, sure makes me real concern about our goals and if the = reward outweighs the risk here. >=20 > I highly recommend that these documents be experimental and people = playing with this stuff in BGP do so in closed environments, not on = routers attached to the global routing system; it's fragile enough as = is. >=20 >=20 > -danny >=20 > [!=3Dbeacon?] = http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf > [ripv1-1058] http://tools.ietf.org/html/rfc1058 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From internet-drafts@ietf.org Fri Dec 7 16:51:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349DC21F884D; Fri, 7 Dec 2012 16:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trJe9UCJ8e4C; Fri, 7 Dec 2012 16:51:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C730221F857B; Fri, 7 Dec 2012 16:51:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121208005156.4951.1400.idtracker@ietfa.amsl.com> Date: Fri, 07 Dec 2012 16:51:56 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-gr-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 00:51:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Accelerated Routing Convergence for BGP Graceful Restart Author(s) : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-ietf-idr-enhanced-gr-02.txt Pages : 9 Date : 2012-12-07 Abstract: In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-enhanced-gr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-enhanced-gr-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-enhanced-gr-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chris.hall@highwayman.com Sat Dec 8 03:20:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC07E21F8752 for ; Sat, 8 Dec 2012 03:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpE6tGaM+kGb for ; Sat, 8 Dec 2012 03:20:59 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta010.mxout.tbr.inty.net [91.221.168.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1CE21F8751 for ; Sat, 8 Dec 2012 03:20:58 -0800 (PST) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 6B5666F843F; Sat, 8 Dec 2012 11:20:57 +0000 (GMT) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 50A916F8421; Sat, 8 Dec 2012 11:20:57 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tbr.inty.net (Postfix) with ESMTP; Sat, 8 Dec 2012 11:20:57 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ThISm-0005dg-Eb; Sat, 08 Dec 2012 11:20:56 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> In-Reply-To: Date: Sat, 8 Dec 2012 11:20:50 -0000 Organization: Highwayman Message-ID: <074d01cdd536$173f5830$45be0890$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8Zd8bHrQ Content-Language: en-gb X-MDF-HostID: 3 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 11:20:59 -0000 Shyam Sethuram wrote (on Fri 07-Dec-2012 at 21:56 +0000): ... > One attribute follows another. There's really no way to tell > what pairs of octets are really acceptable as Flags and Type. =A0 Currently, for both known and unknown Types there are some (small) restrictions on the Flags, and repeat Types are invalid. However strong these cross-checks are, the draft relaxes them. For known Types there are known restrictions on the length. The draft relaxes all those cross-checks too. ... > You can reset the session at this point if you haven't come > across MP_REACH so far and know that IPv4 NLRI length is 0. =A0 Indeed. If you have a messed up set of attributes and no NLRI in your hands, then it's fair to assume that some NLRI have been lost, so session-reset is the only way forward. This is one of the few unambiguous cases. ... > IMO, MP_UNREACH_NLRI does not enter the picture here. The > test for NLRI presence for the scenario you described is > limited to plain IPv4=A0NLRI and/or MP_REACH_NLRI. =A0 I suggest that failing to withdraw some routes is worse than failing to install or update the attributes of some routes. Suppose an MP_UNREACH_NLRI was sent, but is obscured by some broken attribute. If the code takes the view that MP_UNREACH_NLRI do not matter, then routes which the sender knows should not be used, may continue to be installed and advertised by the receiver -- and may stay that way "forever". Conversely, with an MP_REACH_NLRI the receiver may (a) not install a new route (which is effectively "treat-as-withdraw"), or (b) not update an existing route (which is bad, but may not actually matter). Chris From shares@ndzh.com Sat Dec 8 08:02:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E07821F896C for ; Sat, 8 Dec 2012 08:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.311 X-Spam-Level: *** X-Spam-Status: No, score=3.311 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_50=0.001, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28Lmkz09R4QE for ; Sat, 8 Dec 2012 08:02:43 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9767321F8848 for ; Sat, 8 Dec 2012 08:02:43 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Sat, 8 Dec 2012 11:02:37 -0500 Message-ID: <00b301cdd55d$720f1bc0$562d5340$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3VXSX8wS1+5H0MT1e0YIilqhc+/w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [Idr] IDR accepts draft-scudder-deprecate-dpa-etal-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 16:02:44 -0000 Idr-wg: Draft-scudder-deprecate-dpa-etal-00.txt is approved. John will submit the draft as: Draft-idr-deprecate-dpa-etal-00.txt. Sue Hares From jakob.heitz@ericsson.com Sat Dec 8 08:43:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4B21F861F for ; Sat, 8 Dec 2012 08:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUQcDKNb6064 for ; Sat, 8 Dec 2012 08:43:06 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3476C21F85E7 for ; Sat, 8 Dec 2012 08:43:06 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qB8Gh34X026336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Dec 2012 10:43:04 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sat, 8 Dec 2012 11:43:03 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Sat, 8 Dec 2012 11:43:03 -0500 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCqgAGK/gCAAJrggIAA4PUAgAAGNdw= Date: Sat, 8 Dec 2012 16:43:02 +0000 Message-ID: <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> In-Reply-To: <074d01cdd536$173f5830$45be0890$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 16:43:07 -0000 The goal of "treat as withdraw" is not to reinterpret a broken update messa= ge and continue the session, like nothing happened. IMO, the goal is to limit the disruption caused by a session reset, while a= lerting a human to fix the problem that no machine can. -- Jakob Heitz. On Dec 8, 2012, at 3:21 AM, "Chris Hall" wrote: > Shyam Sethuram wrote (on Fri 07-Dec-2012 at 21:56 +0000): > ... >> One attribute follows another. There's really no way to tell >> what pairs of octets are really acceptable as Flags and Type. > =20 > Currently, for both known and unknown Types there are some (small) > restrictions on the Flags, and repeat Types are invalid. However > strong these cross-checks are, the draft relaxes them. >=20 > For known Types there are known restrictions on the length. The draft > relaxes all those cross-checks too. >=20 > ... >> You can reset the session at this point if you haven't come >> across MP_REACH so far and know that IPv4 NLRI length is 0. > =20 > Indeed. If you have a messed up set of attributes and no NLRI in your > hands, then it's fair to assume that some NLRI have been lost, so > session-reset is the only way forward. >=20 > This is one of the few unambiguous cases. >=20 > ... >> IMO, MP_UNREACH_NLRI does not enter the picture here. The >> test for NLRI presence for the scenario you described is >> limited to plain IPv4 NLRI and/or MP_REACH_NLRI. > =20 > I suggest that failing to withdraw some routes is worse than failing > to install or update the attributes of some routes. >=20 > Suppose an MP_UNREACH_NLRI was sent, but is obscured by some broken > attribute. If the code takes the view that MP_UNREACH_NLRI do not > matter, then routes which the sender knows should not be used, may > continue to be installed and advertised by the receiver -- and may > stay that way "forever". >=20 > Conversely, with an MP_REACH_NLRI the receiver may (a) not install a > new route (which is effectively "treat-as-withdraw"), or (b) not > update an existing route (which is bad, but may not actually matter). >=20 > Chris >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From shane@castlepoint.net Sat Dec 8 09:49:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBFD21F8643 for ; Sat, 8 Dec 2012 09:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aiv5q4hndDjh for ; Sat, 8 Dec 2012 09:49:49 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 854BE21F85F7 for ; Sat, 8 Dec 2012 09:49:48 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 8A7C9300049 for ; Sat, 8 Dec 2012 17:49:48 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 3658330003D; Sat, 8 Dec 2012 10:49:47 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2FB501D4-D41C-45EC-A118-6F1D2C3E2240" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Sat, 8 Dec 2012 10:49:45 -0700 Message-Id: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <20671.32202.484172.394565@oz.mt.att.com> To: Tony Tauber X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Dec 8 10:49:48 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50c37dbc199635526810484 X-DSPAM-Factors: 27, Subject*Re+#+WGLC, 0.01000, mailing+list, 0.01000, mailing+list, 0.01000, Subject*Idr+WGLC, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, Subject*on+draft-ietf-idr-as-private-reservation-00, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, list+#+ietf, 0.01000, list+#+ietf, 0.01000, mailing+#+#+ietf, 0.01000, mailing+#+#+ietf, 0.01000, On+Dec, 0.01000, On+Dec, 0.01000, Subject*Idr+#+#+draft-ietf-idr-as-private-reservation-00, 0.01000, the+#+#+of, 0.01000, the+#+#+of, 0.01000, Dec+#+#+at, 0.01000, Dec+#+#+at, 0.01000, Dec+#+2012, 0.01000, Dec+#+2012, 0.01000, Url*www, 0.01000, Url*www, 0.01000, Subject*Re+#+#+on, 0.01000, in+the, 0.01000, in+the, 0.01000 Cc: idr@ietf.org, Jay Borkenhagen , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 17:49:50 -0000 --Apple-Mail=_2FB501D4-D41C-45EC-A118-6F1D2C3E2240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Tony, On Dec 6, 2012, at 8:19 AM, Tony Tauber wrote: > Not at all what I had in mind. What I had in mind was a situation = where a carrier is using a separate ASN for every one of thousands of = some type of site or customer (because there are so many private ASNs, = don't worry!) Then they have policies which say "when a route comes = with such and such an origin AS, do something or other". Of course, = stripping the private AS internally will break such policy logic. >=20 > Then they acquire another carrier whose clever engineers had the same = type of thinking and now the presumption of uniqueness w/in their = deployment scope is broken. Sometimes such things can be aided by = clever use of hack-y vendor features (unless remove-private-as is part = of the BGP standard); sometimes not. >=20 > That problem was the one I was trying to articulate. In all fairness, the above is true of all private/reserved "numbers" = used by two, disparate networks that are being consolidated into one, = e.g.: RFC 1918 addresses. I'd go a bit further and say that all = competent engineers understand and acknowledge this risk, regardless of = whether it's private ASN's or RFC 1918 addresses, as they are in the = design phases. I would also assert, based on personal experience of the = last several years, that when such consolidations happen, there are = conversations and planning that occurs between "clever engineers" of = _both_ networks /prior/ to the day of "flipping the switch" so-to-speak = where the two networks start to become one. Furthermore, given that the = "standard" private ASN's (64512-65534), and other vendor-proprietary BGP = knobs, are already deployed and, most likely, in use by one or both = networks, then such due diligence & planning MUST already be common = practice among those clever engineers ... so, I'm unclear how NOT = extending the private ASN space makes this any different? Admittedly, all of the above is "not fun" nor as easy as using globally = unique ASN's. However, that's not an available option on the table, = because operators don't have an economically feasible _choice_ to use = globally unique ASN's. (See previous discussion on changing RFC 1930 = and/or RIR policies if you want to fix that). =20 Just to be clear, my recommendation is still to publish this draft as a = RFC. -shane > The problem that Jay seemed to have in mind of backward compatibility = and semantics of what is considered a private AS is different (and = something I hadn't considered, so glad he mentioned it.) >=20 > Tony >=20 > On Wed, Dec 5, 2012 at 3:49 PM, Robert Raszuk = wrote: > All, >=20 > I think both Tony and Jay forgot that routing and reachability is not > about originator AS .. it is about prefixes they advertise. >=20 > If peering ISP AS chooses to peer with private as or remove private as > from AS-PATH or for completeness substitute with their own it is all > ok. He takes responsibility to route data to such customer(s). >=20 > Any subsequent removal of private as in the path also results in the > same responsibility of the provider who permits private AS for > peering. >=20 > I am not sure why there is concern with it on the list. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_2FB501D4-D41C-45EC-A118-6F1D2C3E2240 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ttauber@1-4-5.net> = wrote:
Not at all what I had in = mind.  What I had in mind was a situation where a carrier is using = a separate ASN for every one of thousands of some type of site or = customer (because there are so many private ASNs, don't worry!)  = Then they have policies which say "when a route comes with such and such = an origin AS, do something or other".  Of course, stripping the = private AS internally will break such policy logic.

Then they acquire another carrier whose clever engineers had the = same type of thinking and now the presumption of uniqueness w/in their = deployment scope is broken.  Sometimes such things can be aided by = clever use of hack-y vendor features (unless remove-private-as is part = of the BGP standard); sometimes not.

That problem was the one I was trying to = articulate.

In all fairness, the = above is true of all private/reserved "numbers" used by two, disparate = networks that are being consolidated into one, e.g.: RFC 1918 addresses. =  I'd go a bit further and say that all competent engineers = understand and acknowledge this risk, regardless of whether it's private = ASN's or RFC 1918 addresses, as they are in the design phases.  I = would also assert, based on personal experience of the last several = years, that when such consolidations happen, there are conversations and = planning that occurs between "clever engineers" of _both_ networks = /prior/ to the day of "flipping the switch" so-to-speak where the two = networks start to become one.  Furthermore, given that the = "standard" private ASN's (64512-65534), and other vendor-proprietary BGP = knobs, are already deployed and, most likely, in use by one or both = networks, then such due diligence & planning MUST already be = common practice among those clever engineers ... so, I'm unclear how NOT = extending the private ASN space makes this any = different?

Admittedly, all of the above is "not = fun" nor as easy as using globally unique ASN's.  However, that's = not an available option on the table, because operators don't have an = economically feasible _choice_ to use globally unique ASN's.  (See = previous discussion on changing RFC 1930 and/or RIR policies if you want = to fix that).  

Just to be clear, my = recommendation is still to publish this draft as a = RFC.

-shane


The problem that Jay seemed to have in mind of backward = compatibility and semantics of what is considered a private AS is = different (and something I hadn't considered, so glad he mentioned = it.)

Tony

On Wed, Dec 5, 2012 at 3:49 = PM, Robert Raszuk <robert@raszuk.net> wrote:
All,

I think both Tony and Jay forgot that routing and reachability is = not
about originator AS .. it is about prefixes they advertise.

If peering ISP AS chooses to peer with private as or remove private = as
from AS-PATH or for completeness substitute with their own it is all
ok. He takes responsibility to route data to such customer(s).

Any subsequent removal of private as in the path also results in the
same responsibility of the provider who permits private AS for
peering.

I am not sure why there is concern with it on the = list.
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr

= --Apple-Mail=_2FB501D4-D41C-45EC-A118-6F1D2C3E2240-- From jsw@inconcepts.biz Sun Dec 9 01:07:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EE221F8556 for ; Sun, 9 Dec 2012 01:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh8psg0nH9tq for ; Sun, 9 Dec 2012 01:07:24 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56F3121F8545 for ; Sun, 9 Dec 2012 01:07:24 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6324173ieb.31 for ; Sun, 09 Dec 2012 01:07:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=/Zd8Hseg+Zw4CKl0nJbNQsUmCGotweu+9Kmgk4hQcAs=; b=MfNlobIpy6KFkqBhFNLBHHEGkf+xcOTHxge5e8XwmSsYdtUQVzNSeUGDGhqsC3S61p C7hm6Znko8IfAAbvkAQ6rdQc4lDJynlNp8gXWe2YZg7zwyrjVr+HU92i29JF634Oh5rI L0IXuaKCcHqcnOWhQ4KvLuZbLHIQMEZn63U+i+pnmj5ug2nlqeXlYVUXcjyUQ40Abaix vHCSK0wIieORzWOW3Q2YHOBjpIY1JkHdDGTwNEf2UgMiRZXIh8v6afbQXGrolxnODPuH EivlkojaeKaHVQhrU5GBjvUAHQvbWHFJjNHl1OzS86ejOv2U2V+vW2HsTtSObE6KMr5w BsYw== MIME-Version: 1.0 Received: by 10.42.22.198 with SMTP id p6mr8378685icb.17.1355044043486; Sun, 09 Dec 2012 01:07:23 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sun, 9 Dec 2012 01:07:23 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: Date: Sun, 9 Dec 2012 04:07:23 -0500 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkkCIwMod3tKMZ0FQeSOFzQZIz/Y0H0wBvTCPECpLfj5Z6WcGdhxlbiLn98DxMFdSYG1fhl Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 09:07:25 -0000 On Wed, Nov 28, 2012 at 4:26 PM, John Scudder wrote: > We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 I did some searching to try and find if there has been any discussion on the recommended range of values that IANA should reserve. I didn't find any, but admittedly, my searching skills may have simply been poor. I mentioned this draft to two colleagues, and our discussion was immediately that it would be nice if the range of newly reserved values were easier for humans to read. If it simply extended from 4,000,000,000 until 2**32-2 this would be a little nicer. If there has been discussion about this, could someone point me to it? Operators care about what things look like in the CLI or the NMS. A bunch of private ASN all beginning with 427xxxxxxx 428xxxxxxx 429xxxxxxx is a little confusing, especially because 4278190080 would be a private ASN but 4278190079 is not. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From swmike@swm.pp.se Sun Dec 9 01:22:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616F121F8640 for ; Sun, 9 Dec 2012 01:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMeKfpvdqvVC for ; Sun, 9 Dec 2012 01:22:19 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C8FEB21F8524 for ; Sun, 9 Dec 2012 01:22:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D4AFE9C; Sun, 9 Dec 2012 10:22:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD73A9A; Sun, 9 Dec 2012 10:22:15 +0100 (CET) Date: Sun, 9 Dec 2012 10:22:15 +0100 (CET) From: Mikael Abrahamsson To: Jeff Wheeler In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 09:22:19 -0000 On Sun, 9 Dec 2012, Jeff Wheeler wrote: > I mentioned this draft to two colleagues, and our discussion was > immediately that it would be nice if the range of newly reserved > values were easier for humans to read. If it simply extended from > 4,000,000,000 until 2**32-2 this would be a little nicer. > > If there has been discussion about this, could someone point me to it? > > Operators care about what things look like in the CLI or the NMS. A > bunch of private ASN all beginning with 427xxxxxxx 428xxxxxxx > 429xxxxxxx is a little confusing, especially because 4278190080 would > be a private ASN but 4278190079 is not. I agree that 4,000,000,000 would be a nice number to start at. It would make it extremely easy to match prive ASN range with regexp as well. If it's felt that 4B up to 2**32 is too many, then I propose that whatever number of private ASN is allocated starting at 4,000,000,000 instead of going from 2**32 and going down. -- Mikael Abrahamsson email: swmike@swm.pp.se From chris.hall@highwayman.com Sun Dec 9 03:37:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF2121F883A for ; Sun, 9 Dec 2012 03:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shAgsqdUJYu0 for ; Sun, 9 Dec 2012 03:37:45 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7A21F8745 for ; Sun, 9 Dec 2012 03:37:44 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 80D3B384081; Sun, 9 Dec 2012 11:37:43 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 59FF3384080; Sun, 9 Dec 2012 11:37:43 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP; Sun, 9 Dec 2012 11:37:43 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ThfCX-0005em-VP; Sun, 09 Dec 2012 11:37:42 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> In-Reply-To: Date: Sun, 9 Dec 2012 11:37:36 -0000 Organization: Highwayman Message-ID: <079901cdd601$9901b630$cb052290$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGYNqrRl3E29RA= Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 11:37:46 -0000 Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000): > > I see the high-level problem Chris describes, and think maybe > it requires discussing possible ways of removing > doubt/ambiguity over successful parsing of such MP_REACH > and MP_UNREACH attributes. My suggestion, for minimal change to the protocol, would be a new capability which would carry the undertaking that: * when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI they will be the first attribute(s), and will appear in that order. * the ORIGIN attribute will be the first attribute, or will follow any NLRI attributes. Which deals with the absence of one or both NLRI attributes. A receiver in possession of this new capability knows that, once it has seen completely valid versions of these leading attributes, it can tolerate any malformation of the following attributes, or absence of essential attributes, etc. and "treat-as-withdraw". The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is supposed to be 0 and Y MUST be 0, 1 or 2. This pattern is, effectively, and "end-of-NLRI-attributes" mark. If the new capability also meant that this attribute would always be output with extended length and guaranteed X = 0, then the receiver would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more unique, and offer a little more assurance that the attributes so far are completely valid. (But this is not essential) (The new capability could also mean that IPv4 Unicast will not appear both in the body of the message and in NLRI attributes -- but that is not essential, either.) If the sender misbehaves, and sends any NLRI attribute after the ORIGIN then: a) if it is not a repeat attribute then... ...accept, but turn off the capability ? ...treat as a repeat ? b) if it is a repeat attribute then... ...session-reset, as per draft ? c) if the extra attribute is hidden by a preceding broken attribute then... ...the change to the relevant NLRI is lost. The last case is BAD: the receiver will "treat-as-withdraw" the NLRI it can see, but not those it cannot. The risk here may be deemed ignorable -- but needs to be assessed. For all code which deals with BGP updates -- BGP speakers or analysers of BGP streams etc -- the only change here is the new capability; UPDATE messages will have attributes in a particular order (and perhaps take a particular form) but are entirely RFC4271 compliant. That leaves the question of what the receiver does in the absence of the new capability... but that's another story, for another day. Chris From enkechen@cisco.com Sun Dec 9 10:26:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF81921F8681 for ; Sun, 9 Dec 2012 10:26:53 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnKoI9aoJZJk for ; Sun, 9 Dec 2012 10:26:53 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7E221F85C6 for ; Sun, 9 Dec 2012 10:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3260; q=dns/txt; s=iport; t=1355077613; x=1356287213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lIwtTd6frMN/KpkuzJ0vAoONkScALERWAwCaQA7hLko=; b=T+U9+V9C6/Y0Y/eVdaDe3qe1C7nbCCwxr9s3LbsMH1jYGxcr0w/KGdMf kMqWxodll1MWurZQ65P1AKPQ/40gAvCP1tYRoDwle+Bc5VX668ay+Gr4w M7n7LvpQrugC1B8xvfGFeEyT+lFmuBQcfEYOZF1H+AsfMwjP0/x3ZWVgq g=; X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="66045164" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Dec 2012 18:26:53 +0000 Received: from [10.21.150.107] (sjc-vpn7-1643.cisco.com [10.21.150.107]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB9IQq0N031228; Sun, 9 Dec 2012 18:26:52 GMT Message-ID: <50C4D7EC.4070309@cisco.com> Date: Sun, 09 Dec 2012 10:26:52 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Chris Hall References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <079901cdd601$9901b630$cb052290$@highwayman.com> In-Reply-To: <079901cdd601$9901b630$cb052290$@highwayman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 18:26:54 -0000 Hi, Chris: As I replied before, the receiver knows from parsing the path attributes whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first attribute in an UPDATE message. It does not need a new capability to make that determination. -- Enke On 12/9/12 3:37 AM, Chris Hall wrote: > Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000): >> I see the high-level problem Chris describes, and think maybe >> it requires discussing possible ways of removing >> doubt/ambiguity over successful parsing of such MP_REACH >> and MP_UNREACH attributes. > My suggestion, for minimal change to the protocol, would be a new > capability which would carry the undertaking that: > > * when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI > they will be the first attribute(s), and will > appear in that order. > > * the ORIGIN attribute will be the first attribute, > or will follow any NLRI attributes. > > Which deals with the absence of one or both NLRI > attributes. > > A receiver in possession of this new capability knows that, once it > has seen completely valid versions of these leading attributes, it can > tolerate any malformation of the following attributes, or absence of > essential attributes, etc. and "treat-as-withdraw". > > The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is > supposed to be 0 and Y MUST be 0, 1 or 2. This pattern is, > effectively, and "end-of-NLRI-attributes" mark. > > If the new capability also meant that this attribute would always be > output with extended length and guaranteed X = 0, then the receiver > would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more > unique, and offer a little more assurance that the attributes so far > are completely valid. (But this is not essential) > > (The new capability could also mean that IPv4 Unicast will not appear > both in the body of the message and in NLRI attributes -- but that is > not essential, either.) > > If the sender misbehaves, and sends any NLRI attribute after the > ORIGIN then: > > a) if it is not a repeat attribute then... > > ...accept, but turn off the capability ? > > ...treat as a repeat ? > > b) if it is a repeat attribute then... > > ...session-reset, as per draft ? > > c) if the extra attribute is hidden by a preceding > broken attribute then... > > ...the change to the relevant NLRI is lost. > > The last case is BAD: the receiver will "treat-as-withdraw" the NLRI > it can see, but not those it cannot. The risk here may be deemed > ignorable -- but needs to be assessed. > > For all code which deals with BGP updates -- BGP speakers or analysers > of BGP streams etc -- the only change here is the new capability; > UPDATE messages will have attributes in a particular order (and > perhaps take a particular form) but are entirely RFC4271 compliant. > > That leaves the question of what the receiver does in the absence of > the new capability... but that's another story, for another day. > > Chris > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From brian.peter.dickson@gmail.com Sun Dec 9 12:19:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0921F8CD8 for ; Sun, 9 Dec 2012 12:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e09oGezKoozj for ; Sun, 9 Dec 2012 12:19:56 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53E6C21F8CD4 for ; Sun, 9 Dec 2012 12:19:56 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1300508eek.31 for ; Sun, 09 Dec 2012 12:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wHWdjz47D/aMSM1pJ4LGvmc9H6srJE9VP+9UFWPlFFQ=; b=RZQ08XMhp9431rXEJkkjs0epOgTnvsxAJVwtQQg8AmqFzRLHNnTCj6srlUzAI32y4s bJi0S2iWOrY9gyNWjOyA5XAqmZsPizC7VriCI/VFMxEKtJ7KzbVHWMwYRq6xWzYjg1nB gxVzqx1ZvpKLRrZp5cHGK0LDQ711oQGnD3MwIhzRvmqcMOVD1J5I7f7M9zR1WplVC/kH 83/xcT7pLWMXUb6AlZ30rxASdqzZBN+g6YX2V8BpzANUwtSAzg/QmWOzEWrh8FVLj6YW B0erWbdiypmyPXL+87awgWSeciUBPQP9y1qQm338x+rMm4FSpzU8C4CW29QCh6TBgUQG 8cQw== MIME-Version: 1.0 Received: by 10.14.173.65 with SMTP id u41mr41534231eel.13.1355084395525; Sun, 09 Dec 2012 12:19:55 -0800 (PST) Received: by 10.223.173.199 with HTTP; Sun, 9 Dec 2012 12:19:55 -0800 (PST) In-Reply-To: <50C4D7EC.4070309@cisco.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <079901cdd601$9901b630$cb052290$@highwayman.com> <50C4D7EC.4070309@cisco.com> Date: Sun, 9 Dec 2012 15:19:55 -0500 Message-ID: From: Brian Dickson To: Enke Chen Content-Type: multipart/alternative; boundary=047d7b6226b009364804d0712c44 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 20:19:57 -0000 --047d7b6226b009364804d0712c44 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 9, 2012 at 1:26 PM, Enke Chen wrote: > Hi, Chris: > > As I replied before, the receiver knows from parsing the path attributes > whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first attribute in > an UPDATE message. It does not need a new capability to make that > determination. > Hi, Enke, Yes, BUT... The specific attributes will be first, ONLY if the sender puts them in that order. (This is restating the obvious for effect, sorry.) What Chris is proposing is a negotiated option where the sender COMMITS to observing the specified order in which to send the attributes. Without that negotiated option, there is no method of influencing the sender's behavior. This is not to say that SOME senders won't use that order. However, any implementation that supports this new option negotiation, and either defaults to or exposes a "knob" for enabling it, will then need to use the SPECIFIC order to be compliant. Having this in an RFC, gives customers a specific thing to point the implementors/vendors at, for requesting support for this. The amount of logic needed to use this specific order, versus any other deterministic, semi-deterministic, or random order, is pretty small. The order is a good order, IMHO. And I think the cost of doing so as a negotiated capability is well worth it, in order to better facilitate the desired error handling, especially inter-vendor/inter-implementation/inter-code-train. (And standardized is much better than potential vendor-specific ways of signaling behavior or defaults, of course.) Brian > On 12/9/12 3:37 AM, Chris Hall wrote: > >> Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000): >> >>> I see the high-level problem Chris describes, and think maybe >>> it requires discussing possible ways of removing >>> doubt/ambiguity over successful parsing of such MP_REACH >>> and MP_UNREACH attributes. >>> >> My suggestion, for minimal change to the protocol, would be a new >> capability which would carry the undertaking that: >> >> * when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI >> they will be the first attribute(s), and will >> appear in that order. >> >> * the ORIGIN attribute will be the first attribute, >> or will follow any NLRI attributes. >> >> Which deals with the absence of one or both NLRI >> attributes. >> >> A receiver in possession of this new capability knows that, once it >> has seen completely valid versions of these leading attributes, it can >> tolerate any malformation of the following attributes, or absence of >> essential attributes, etc. and "treat-as-withdraw". >> >> The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is >> supposed to be 0 and Y MUST be 0, 1 or 2. This pattern is, >> effectively, and "end-of-NLRI-attributes" mark. >> >> If the new capability also meant that this attribute would always be >> output with extended length and guaranteed X = 0, then the receiver >> would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more >> unique, and offer a little more assurance that the attributes so far >> are completely valid. (But this is not essential) >> >> (The new capability could also mean that IPv4 Unicast will not appear >> both in the body of the message and in NLRI attributes -- but that is >> not essential, either.) >> >> If the sender misbehaves, and sends any NLRI attribute after the >> ORIGIN then: >> >> a) if it is not a repeat attribute then... >> >> ...accept, but turn off the capability ? >> >> ...treat as a repeat ? >> >> b) if it is a repeat attribute then... >> >> ...session-reset, as per draft ? >> >> c) if the extra attribute is hidden by a preceding >> broken attribute then... >> >> ...the change to the relevant NLRI is lost. >> >> The last case is BAD: the receiver will "treat-as-withdraw" the NLRI >> it can see, but not those it cannot. The risk here may be deemed >> ignorable -- but needs to be assessed. >> >> For all code which deals with BGP updates -- BGP speakers or analysers >> of BGP streams etc -- the only change here is the new capability; >> UPDATE messages will have attributes in a particular order (and >> perhaps take a particular form) but are entirely RFC4271 compliant. >> >> That leaves the question of what the receiver does in the absence of >> the new capability... but that's another story, for another day. >> >> Chris >> >> ______________________________**_________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/**listinfo/idr >> > > ______________________________**_________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/**listinfo/idr > --047d7b6226b009364804d0712c44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Dec 9, 2012 at 1:26 PM, Enke Che= n <enkechen@cisco.com> wrote:
Hi, Chris:

As I replied before, =A0the receiver knows from parsing the path attributes= whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first attribute in= an UPDATE message. =A0It does not need a new capability to make that deter= mination.

Hi, Enke,

Yes, BUT...

<= div>The specific attributes will be first, ONLY if the sender puts them in = that order. (This is restating the obvious for effect, sorry.)

What Chris is proposing is a negotiated option where th= e sender COMMITS to observing the specified order in which to send the attr= ibutes.

Without that negotiated option, there is n= o method of influencing the sender's behavior.=A0

This is not to say that SOME senders won't use that= order.

However, any implementation that supports = this new option negotiation, and either defaults to or exposes a "knob= " for enabling it, will then need to use the SPECIFIC order to be comp= liant.

Having this in an RFC, gives customers a specific thing= to point the implementors/vendors at, for requesting support for this.

The amount of logic needed to use this specific order= , versus any other deterministic, semi-deterministic, or random order, is p= retty small.

The order is a good order, IMHO. And I think the cost o= f doing so as a negotiated capability is well worth it, in order to better = facilitate the desired error handling, especially inter-vendor/inter-implem= entation/inter-code-train. (And standardized is much better than potential = vendor-specific ways of signaling behavior or defaults, of course.)

=A0Brian


On 12/9/12 3:37 AM, Chris Hall wrote:
Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000):
I see the high-level problem Chris describes, and think maybe
it requires discussing possible ways of removing
doubt/ambiguity over successful parsing of such MP_REACH
and MP_UNREACH attributes.
My suggestion, for minimal change to the protocol, would be a new
capability which would carry the undertaking that:

=A0 =A0* when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI
=A0 =A0 =A0they will be the first attribute(s), and will
=A0 =A0 =A0appear in that order.

=A0 =A0* the ORIGIN attribute will be the first attribute,
=A0 =A0 =A0or will follow any NLRI attributes.

=A0 =A0 =A0Which deals with the absence of one or both NLRI
=A0 =A0 =A0attributes.

A receiver in possession of this new capability knows that, once it
has seen completely valid versions of these leading attributes, it can
tolerate any malformation of the following attributes, or absence of
essential attributes, etc. and "treat-as-withdraw".

The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is
supposed to be 0 and Y MUST be 0, 1 or 2. =A0This pattern is,
effectively, and "end-of-NLRI-attributes" mark.

If the new capability also meant that this attribute would always be
output with extended length and guaranteed X =3D 0, then the receiver
would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more
unique, and offer a little more assurance that the attributes so far
are completely valid. =A0(But this is not essential)

(The new capability could also mean that IPv4 Unicast will not appear
both in the body of the message and in NLRI attributes -- but that is
not essential, either.)

If the sender misbehaves, and sends any NLRI attribute after the
ORIGIN then:

=A0 =A0a) if it is not a repeat attribute then...

=A0 =A0 =A0 =A0 ...accept, but turn off the capability ?

=A0 =A0 =A0 =A0 ...treat as a repeat ?

=A0 =A0b) if it is a repeat attribute then...

=A0 =A0 =A0 =A0 ...session-reset, as per draft ?

=A0 =A0c) if the extra attribute is hidden by a preceding
=A0 =A0 =A0 broken attribute then...

=A0 =A0 =A0 =A0 ...the change to the relevant NLRI is lost.

The last case is BAD: the receiver will "treat-as-withdraw" the N= LRI
it can see, but not those it cannot. =A0The risk here may be deemed
ignorable -- but needs to be assessed.

For all code which deals with BGP updates -- BGP speakers or analysers
of BGP streams etc -- the only change here is the new capability;
UPDATE messages will have attributes in a particular order (and
perhaps take a particular form) but are entirely RFC4271 compliant.

That leaves the question of what the receiver does in the absence of
the new capability... but that's another story, for another day.

Chris
=A0 =A0
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b6226b009364804d0712c44-- From rraszuk@gmail.com Sun Dec 9 12:51:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62BD21F8D04 for ; Sun, 9 Dec 2012 12:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdsEL0KdYi-a for ; Sun, 9 Dec 2012 12:51:05 -0800 (PST) Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) by ietfa.amsl.com (Postfix) with ESMTP id EA69A21F8CFF for ; Sun, 9 Dec 2012 12:51:04 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id z3so3200971iad.34 for ; Sun, 09 Dec 2012 12:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QDwtBLPs2s4t2f9/6NRnnTgb+ssD7gUFKhYXK8p6u6s=; b=bI6mc9WWETGA9SYdoRFanRGS2kxyggZgsclknf7V+nqHEIYWXlSpAS/fKOe6WMDb8n tyHWkzQ45xnN7PIx6+zqrYCf4Vahdor7uB2BKK9Qd7VJQFNQ/tx5BYedoxikZB4OJe6j 90IBfccEh9blI0Xs6HkXEqNafyhgxOAaPUjYl8Zbmc03jPCrHwUqQGlXUuwXuQusYaHS 0fRsCP/kSLHo9idramltdH4a/RcbVihjLFppGyhh0tJptOqOxZVyl1Ya2jzpbeFOeHLm db9kjVoNbXDQYrTguI3njFDMl7HJHNMpmLhgBHrPGASm94qTgXAox45M14/bMqRTGvQm Ot9Q== MIME-Version: 1.0 Received: by 10.50.40.137 with SMTP id x9mr7488212igk.1.1355086264392; Sun, 09 Dec 2012 12:51:04 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Sun, 9 Dec 2012 12:51:04 -0800 (PST) In-Reply-To: <50C4D7EC.4070309@cisco.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <079901cdd601$9901b630$cb052290$@highwayman.com> <50C4D7EC.4070309@cisco.com> Date: Sun, 9 Dec 2012 21:51:04 +0100 X-Google-Sender-Auth: 5xqHBq5Ja5etqV_ho39P-Y5_ikw Message-ID: From: Robert Raszuk To: Enke Chen Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 20:51:06 -0000 Hi Enke, I think the draft is pretty clear reg the MP_REACH_NLRI. However as indicated in this thread what is not clear are the following cases: - MP_UNREACH_NLRI is not mandatory so you never know if it was not sent after some malformed attribute -> possible solution would be to send empty UNREACH each time after MP_REACH. Otherwise if you are not sure sender did not include MP_UNREACH you really can not treat-as-withdraw so session will get reset. - Sending vanilla IPv4 reach/unreach unicast NLRI is still allowed and receiver has no way of knowing if sender did include those or not in addition to new SAFIs in MP_REACH - here again lack of such assurance will cause session reset even if first MP_REACH was parsed -> possible solution would be to depreciate vanilla IPv4 reach/unreach unicast NLRI if MP capabilities were negotiated. Thx, R. On Sun, Dec 9, 2012 at 7:26 PM, Enke Chen wrote: > Hi, Chris: > > As I replied before, the receiver knows from parsing the path attributes > whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first attribute in > an UPDATE message. It does not need a new capability to make that > determination. > > -- Enke > > > On 12/9/12 3:37 AM, Chris Hall wrote: >> >> Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000): >>> >>> I see the high-level problem Chris describes, and think maybe >>> it requires discussing possible ways of removing >>> doubt/ambiguity over successful parsing of such MP_REACH >>> and MP_UNREACH attributes. >> >> My suggestion, for minimal change to the protocol, would be a new >> capability which would carry the undertaking that: >> >> * when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI >> they will be the first attribute(s), and will >> appear in that order. >> >> * the ORIGIN attribute will be the first attribute, >> or will follow any NLRI attributes. >> >> Which deals with the absence of one or both NLRI >> attributes. >> >> A receiver in possession of this new capability knows that, once it >> has seen completely valid versions of these leading attributes, it can >> tolerate any malformation of the following attributes, or absence of >> essential attributes, etc. and "treat-as-withdraw". >> >> The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is >> supposed to be 0 and Y MUST be 0, 1 or 2. This pattern is, >> effectively, and "end-of-NLRI-attributes" mark. >> >> If the new capability also meant that this attribute would always be >> output with extended length and guaranteed X = 0, then the receiver >> would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more >> unique, and offer a little more assurance that the attributes so far >> are completely valid. (But this is not essential) >> >> (The new capability could also mean that IPv4 Unicast will not appear >> both in the body of the message and in NLRI attributes -- but that is >> not essential, either.) >> >> If the sender misbehaves, and sends any NLRI attribute after the >> ORIGIN then: >> >> a) if it is not a repeat attribute then... >> >> ...accept, but turn off the capability ? >> >> ...treat as a repeat ? >> >> b) if it is a repeat attribute then... >> >> ...session-reset, as per draft ? >> >> c) if the extra attribute is hidden by a preceding >> broken attribute then... >> >> ...the change to the relevant NLRI is lost. >> >> The last case is BAD: the receiver will "treat-as-withdraw" the NLRI >> it can see, but not those it cannot. The risk here may be deemed >> ignorable -- but needs to be assessed. >> >> For all code which deals with BGP updates -- BGP speakers or analysers >> of BGP streams etc -- the only change here is the new capability; >> UPDATE messages will have attributes in a particular order (and >> perhaps take a particular form) but are entirely RFC4271 compliant. >> >> That leaves the question of what the receiver does in the absence of >> the new capability... but that's another story, for another day. >> >> Chris >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From chris.hall@highwayman.com Sun Dec 9 14:35:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8156C21F8D2A for ; Sun, 9 Dec 2012 14:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSdOeVs054IH for ; Sun, 9 Dec 2012 14:35:05 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta010.mxout.tbr.inty.net [91.221.168.51]) by ietfa.amsl.com (Postfix) with ESMTP id AB37D21F8CED for ; Sun, 9 Dec 2012 14:35:04 -0800 (PST) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 420F56F83E5; Sun, 9 Dec 2012 22:35:03 +0000 (GMT) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 1DA546F83B2; Sun, 9 Dec 2012 22:35:03 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tbr.inty.net (Postfix) with ESMTP; Sun, 9 Dec 2012 22:35:02 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ThpSf-0005fe-Rt; Sun, 09 Dec 2012 22:35:02 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <079901cdd601$9901b630$cb052290$@highwayman.com> <50C4D7EC.4070309@cisco.com> In-Reply-To: Date: Sun, 9 Dec 2012 22:34:56 -0000 Organization: Highwayman Message-ID: <07dd01cdd65d$6d5d3520$48179f60$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGYNqrRAQ+Sq64BU0/mmgIDSabIl07I82A= Content-Language: en-gb X-MDF-HostID: 3 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 22:35:05 -0000 On Sun, Dec 9, 2012 at 1:26 PM, Enke Chen wrote: > Hi, Chris: > > As I replied before, the receiver knows from parsing the path > attributes whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is > the first attribute in an UPDATE message. =A0It does not need a > new capability to make that determination. Well, yes, there is no escaping the fact that... if the receiver can see an MP_REACH_NLRI attribute and it is the first attribute, the receiver can be pretty sure that the sender sent an MP_REACH_NLRI attribute, and (what's more) they sent it first. The capability, in this case, serves only to provide a warm feeling that the sender is actually doing what they have committed themselves to. But that's not really the purpose of the capability... ...the difficulty/ambiguity I'm trying to get past is: what conclusion can the receiver draw if they do *not* see an MP_REACH_NLRI attribute anywhere, and the attributes are broken. At present the receiver cannot tell whether: a) the sender sent an MP_REACH_NLRI attribute which is buried under the debris of the broken attribute(s), or: b) the sender did not send an MP_REACH_NLRI attribute at all at all. The purpose of the capability is to allow the receiver to know that the answer is (b), because the sender is promising to send MP_REACH_NLRI and/or MP_UNREACH_NLRI before any other attribute(s), and hence neither of those attributes can be obscured by some other broken attribute. [Well... I guess we have to consider the possibility that the sender fails to live up to their promise -- in which case the answer could still be (a) but the receiver would assume (b). My feeling is that this case is not worth worrying about...]=20 Similarly MP_UNREACH_NLRI on its own, and in combination with MP_REACH_NLRI. Clearly, if an UPDATE contains only vanilla IPv4 Unicast in the body of the message (ie, not in any NLRI attribute), then "treat-as-withdraw" can be applied to all the NLRI no matter how broken the attributes -- because the NLRI in the body of the message are quite separate from the attributes. Where the sender always sends any NLRI attributes as the first attributes, they are effectively separated from the rest of the attributes. However, the receiver has to *know* that is what the sender will do in order to take advantage of it -- since, otherwise, the sender is allowed to send attributes in any order. That's where the capability comes in. Chris From chris.hall@highwayman.com Sun Dec 9 14:57:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7959821F8D3C for ; Sun, 9 Dec 2012 14:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL3LZYyxi+ts for ; Sun, 9 Dec 2012 14:57:11 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tch.inty.net [91.221.169.50]) by ietfa.amsl.com (Postfix) with ESMTP id C431421F8CE2 for ; Sun, 9 Dec 2012 14:57:10 -0800 (PST) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 4AD3512840D; Sun, 9 Dec 2012 22:57:09 +0000 (GMT) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 1FB0C12840C; Sun, 9 Dec 2012 22:57:09 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tch.inty.net (Postfix) with ESMTP; Sun, 9 Dec 2012 22:57:08 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Thpo4-0005fi-8m; Sun, 09 Dec 2012 22:57:08 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <079901cdd601$9901b630$cb052290$@highwayman.com> <50C4D7EC.4070309@cisco.com> In-Reply-To: Date: Sun, 9 Dec 2012 22:57:01 -0000 Organization: Highwayman Message-ID: <07de01cdd660$83c28420$8b478c60$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGYNqrRAQ+Sq64BU0/mmgIDSabIl07VpzA= Content-Language: en-gb X-MDF-HostID: 22 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 22:57:13 -0000 Brian Dickson wrote (on Sun 09-Dec-2012 at 20:20 +0000) > > What Chris is proposing is a negotiated option where the > sender COMMITS to observing the specified order in which > to send the attributes. > > Without that negotiated option, there is no method of > influencing the sender's behavior.=A0 It would be straightforward for a BGP implementation to always use the specified order, and always announce the "capability" -- this is essentially unilateral. The key thing is that receivers who understand the significance of the capability can factor that into their error handling strategy. (And receivers who do not understand the capability can simply ignore it.) > This is not to say that SOME senders won't use that order. Indeed, in the absence of the capability, the receiver has to assume that attributes may be sent in any order (as per current RFC)... > However, any implementation that supports this new > option negotiation, and either defaults to or exposes > a "knob" for enabling it, will then need to use the > SPECIFIC order to be compliant. ...or have some "knob" to force it to assume something else. Chris From chris.hall@highwayman.com Sun Dec 9 15:07:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B625921F8CCE for ; Sun, 9 Dec 2012 15:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJad-UFJkT1g for ; Sun, 9 Dec 2012 15:07:26 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta010.mxout.tbr.inty.net [91.221.168.51]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2F21F8CBD for ; Sun, 9 Dec 2012 15:07:25 -0800 (PST) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 969316F83B2; Sun, 9 Dec 2012 23:07:24 +0000 (GMT) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 7CA886F839B; Sun, 9 Dec 2012 23:07:24 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tbr.inty.net (Postfix) with ESMTP; Sun, 9 Dec 2012 23:07:24 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Thpxz-0005fl-Dd; Sun, 09 Dec 2012 23:07:23 +0000 From: "Chris Hall" To: "'Jakob Heitz'" References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> In-Reply-To: <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> Date: Sun, 9 Dec 2012 23:07:17 -0000 Organization: Highwayman Message-ID: <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PyXZoJSUA== Content-Language: en-gb X-MDF-HostID: 3 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 23:07:26 -0000 Jakob Heitz wrote (on Sat 08-Dec-2012 at 16:43 +0000): > The goal of "treat as withdraw" is not to reinterpret a broken > update message and continue the session, like nothing happened. > > IMO, the goal is to limit the disruption caused by a session reset, > while alerting a human to fix the problem that no machine can. I guess you are suggesting that it does not then matter if a broken UPDATE message results in some NLRI being missed, and so not "treated-as-withdraw", and hence the receiver continues with some invalid or out of date routes, for some time. Clearly session-reset is a less than perfect remedy. But in proposing an alternative treatment, perhaps "first do no harm" is as good a guide as any. I think that to achieve that, one needs to be sure that *all* NLRI in a broken update can be identified if "treat-as-withdraw" is to be applied. If the intention is to "treat-as-withdraw" any NLRI which is visible, but continue the session in any case (so, accepting the risks of invalid or out of date routes) then I think the draft should estimate the risks and set out a justification for this being a less-bad remedy than session-reset. Of course, a major issue with session-reset is that the error may well simply be repeated, creating a ghastly cycle session-reset/restart. It could well be better to avoiding session-reset, and continue with some invalid or out of date routes -- or a while, defined somehow ? I just don't know how to demonstrate that, or how to limit the downside of accepting that risk, etc. "Treat-as-withdraw" is an excellent and minimally disruptive response in those cases where all NLRI can be identified. But it is not the only alternative to session-reset. If there is doubt and uncertainty about some routes, the receiver could deem *all* routes learned from the peer in question to be "routes-of-last-resort", which it then uses if and only if it had nothing else, but would not advertise them to other peers. This is just short of a "session-reset", and avoids falling into a cycle of session-reset/restart. Chris From jakob.heitz@ericsson.com Sun Dec 9 15:37:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57B21F8CFA for ; Sun, 9 Dec 2012 15:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGgH-39by9ge for ; Sun, 9 Dec 2012 15:37:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4421F84BC for ; Sun, 9 Dec 2012 15:37:31 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB9NlVbR018308; Sun, 9 Dec 2012 17:47:32 -0600 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 9 Dec 2012 18:37:22 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Sun, 9 Dec 2012 18:37:22 -0500 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCqgAGK/gCAAJrggIAA4PUAgAAGNdyAAlGBgP//tAyw Date: Sun, 9 Dec 2012 23:37:21 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E10C90F@eusaamb109.ericsson.se> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> In-Reply-To: <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 23:37:35 -0000 IMO, another goal is not to require any change to the peer. Not even a little bit. Changing the peer behaviour (even a little bit) is an entirely different story. On Sunday, December 09, 2012 3:07 PM, Chris Hall wrote: > Jakob Heitz wrote (on Sat 08-Dec-2012 at 16:43 +0000): >> The goal of "treat as withdraw" is not to reinterpret a broken >> update message and continue the session, like nothing happened. >>=20 >> IMO, the goal is to limit the disruption caused by a session reset, >> while alerting a human to fix the problem that no machine can. >=20 > I guess you are suggesting that it does not then matter if a broken > UPDATE message results in some NLRI being missed, and so not > "treated-as-withdraw", and hence the receiver continues with some > invalid or out of date routes, for some time. >=20 > Clearly session-reset is a less than perfect remedy. But in proposing > an alternative treatment, perhaps "first do no harm" is as good a > guide as any. I think that to achieve that, one needs to be sure that > *all* NLRI in a broken update can be identified if > "treat-as-withdraw" is to be applied.=20 >=20 > If the intention is to "treat-as-withdraw" any NLRI which is visible, > but continue the session in any case (so, accepting the risks of > invalid or out of date routes) then I think the draft should estimate > the risks and set out a justification for this being a less-bad > remedy than session-reset.=20 >=20 > Of course, a major issue with session-reset is that the error may well > simply be repeated, creating a ghastly cycle session-reset/restart. > It could well be better to avoiding session-reset, and continue with > some invalid or out of date routes -- or a while, defined somehow ? I > just don't know how to demonstrate that, or how to limit the downside > of accepting that risk, etc.=20 >=20 > "Treat-as-withdraw" is an excellent and minimally disruptive response > in those cases where all NLRI can be identified. But it is not the > only alternative to session-reset. If there is doubt and uncertainty > about some routes, the receiver could deem *all* routes learned from > the peer in question to be "routes-of-last-resort", which it then uses > if and only if it had nothing else, but would not advertise them to > other peers. This is just short of a "session-reset", and avoids > falling into a cycle of session-reset/restart. >=20 > Chris --=20 Jakob Heitz.= From chris.hall@highwayman.com Sun Dec 9 15:45:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41E521F8D06 for ; Sun, 9 Dec 2012 15:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.961 X-Spam-Level: * X-Spam-Status: No, score=1.961 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igxof2YqpESF for ; Sun, 9 Dec 2012 15:45:00 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tbr.inty.net [91.221.168.45]) by ietfa.amsl.com (Postfix) with ESMTP id D937121F8D82 for ; Sun, 9 Dec 2012 15:44:59 -0800 (PST) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id 2A387A0C080; Sun, 9 Dec 2012 23:44:58 +0000 (GMT) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id F3CCEA0C07F; Sun, 9 Dec 2012 23:44:57 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tbr.inty.net (Postfix) with ESMTP; Sun, 9 Dec 2012 23:44:57 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ThqYK-0005fq-VE; Sun, 09 Dec 2012 23:44:57 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> In-Reply-To: Date: Sun, 9 Dec 2012 23:44:51 -0000 Organization: Highwayman Message-ID: <07e901cdd667$31c593e0$9550bba0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGYNqrRl3HDqJA= Content-Language: en-gb X-MDF-HostID: 9 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 23:45:00 -0000 Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000): > > I see the high-level problem Chris describes, and think maybe > it requires discussing possible ways of removing > doubt/ambiguity over successful parsing of such MP_REACH > and MP_UNREACH attributes. As I wrote earlier, given a new capability, it is possible to allow for arbitrarily broken attributes but still reliably "treat-as-withdraw" all NLRI in an UPDATE. This finesses the question of why one would need to allow for arbitrarily broken attributes, because in that scenario the degree of broken-ness is moot. To improve error handling -- in particular, avoid session-reset -- without requiring changes at the sender end, requires a deeper analysis. -------------------------------- For the avoidance of doubt: the following all relates to a receiver who cannot assume that the sender always sends NLRI attributes as the first attributes -- ie, it applies to senders with currently RFC compliant implementations (about whom the receiver has no special knowledge), and hence to senders who do not send the above mentioned new capability. I start from the position that it is essential to identify all NLRI if "treat-as-withdraw" is to be used. In the general case this means being able to identify the start of all attributes, and to be sure that no attributes have been missed. This rules out accepting arbitrarily broken attributes. For me, the first step in "parsing" attributes is to check the "framing" (which is sort of the "lexical" level). A set of attributes passes the framing check if the sum of all attribute lengths is equal to the 'Total Attributes Length'. A set of attributes which does not pass the framing check is, I suggest, too badly broken to allow all NLRI to be reliably identified, and therefore cannot be handled as "treat-as-withdraw". This allows for all sorts of broken attribute *except* for attributes with broken lengths. Now, in the framing check, the 'Total Attributes Length' is, effectively, a checksum -- but, not a very strong one. However, it may be considered sufficient to allow the attributes to be accepted, such that any further errors can trigger "treat-as-withdraw", apart from errors in the NLRI attributes. However, I am yet to be convinced of the value of accepting a well-known attribute (eg. ORIGIN) if it has invalid Flags or does not have (one of) the known valid Length(s). I assume that accepting such an attribute is designed to cope with for software issues at the far end. However, forming these attributes is very simple, well exercised, and easily tested code. It seems to me that this sort of anomaly is more likely to be symptomatic of a framing issue than it is to be a well-formed attribute which the sender has, for reasons unknown, decided to send with unexpected Flags and/or Length. Therefore, I think that the framing check should be augmented by some "semantic" checks (eg ORIGIN must be not-Optional, not-Transitive and must have Length == 1), to make up for (some of) the weakness of the simple checksum. This is partly because I feel the weakness of the checksum is a potential problem -- but I confess this is not evidence based. It is also partly because I don't feel a strong need to allow for such malformations in the well-known cases in any case -- this is also not evidence based, but I have seen no evidence to the contrary, either. So, if one states the problem as: 1) to qualify for "treat-as-withdraw" it must be possible to identify all NLRI attributes. And each NLRI attribute must be "well-formed". And repeated NLRI attributes are automatically cause for session-reset. 2) for (1) the receiver must be able to identify all attributes -- because otherwise it cannot be sure of identifying all the NLRI ones. 3) the test for being able to identify all attributes is that the attributes are properly "framed". 4) the framing test may be augmented by various semantic constraints, at least for well-known attributes. Then there is a debate to be had about each step in the argument from (1) to (3), and the extent to which (4) should apply (if at all) and which attributes it should apply to. I believe this would resolve the ambiguity/contradiction in the current draft, namely that: * "treat-as-withdraw" is mandated as a means to deal with arbitrarily broken attributes, * but cannot be used unless all NLRI can be identified, * which is not possible (in the general case) for arbitrarily broken attributes ! Resolution of the issue limits the degree of broken-ness which is acceptable. Note that semantic nonsense inside an Optional-Transitive attribute would be handled as "treat-as-withdraw"... which for me is the most important case. (I'm pretty happy dropping a session with a peer that cannot manage to construct a well-framed set of attributes, but dropping a session because the peer has innocently passed on a semantically invalid attribute does upset me.) I understand that in the well-known RIPE/Duke incident, which raised the profile of invalid Optional-Transitive attributes, the problem was that some routers mangled things such that the framing-check above would have failed. Which is a shame. Chris From rjs@rob.sh Sun Dec 9 15:46:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6613F21F8D82 for ; Sun, 9 Dec 2012 15:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVElrFXHgZGn for ; Sun, 9 Dec 2012 15:46:36 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 6077F21F8D06 for ; Sun, 9 Dec 2012 15:46:32 -0800 (PST) Received: from [46.65.174.228] (helo=[172.16.1.6]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1ThqWy-0003oD-H1; Sun, 09 Dec 2012 23:43:32 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rob Shakir In-Reply-To: <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> Date: Sun, 9 Dec 2012 23:46:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1499) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 23:46:37 -0000 Chris, In my opinion (and as per Jakob's comment earlier in the thread) you are = looking at the treat-as-withdraw behaviour in the wrong way. I have = written multiple messages about this previously, but let me reiterate = some of the discussions. The current BGP implementation of session reset optimises solely to make = sure it maintaining single device RIB consistency, and knowledge of = correct routing information being used by that local speaker. What this = misses out is the other dimension to the correctness, which is that of = whether services within the network as a system are functional. Where we = pursue anything around the revised error handling functionality that is = being discussed in this draft, we balance the correctness of the local = device's RIB, against the functionality of the overall network system. As such, I think we have to accept that the current protocol behaviour = can be *very* damaging to network deployments and hence operators of = real networks are prepared to tweak this balance somewhat. The = requirements draft that I am continuing to edit tries to lay out a = framework whereby one can limit the amount of time over which this = inconsistency may affect the network through having means by which RIB = consistency may be recovered. For example, these are: - A more selective means by which ROUTE REFRESH can be achieved (e.g., = one-time ORF, using rt-constrain to refresh a subset of routes, or = building upon the Enhanced GR UPDATE-VERSION message) - which allows the = individual speaker to recovery consistency of the RIB. - Better ways to be able to do session reset (the observation being that = the session-level error handling causes most problems due to forwarding = outages during it) - which is answered by GR based on NOTIFICATION, and = Enhanced GR. It strikes me that your analysis is aiming to ensure 100% consistency at = the device level - which I think is something that we have to accept is = incompatible with overall network system robustness. Can I suggest that = you contribute some text to the draft as to where there are caveats = (i.e., where the treat-as-withdraw mechanism may fail), and note that = these are positions where a device may wish to continue to implement = session level reset behaviours, or additional risk may be faced by the = device? My view is that we should *not* have a capability to indicate this = behaviour. I would like a means by which I am not reliant on 3rd party = actions (be it my peers in the dfz, or l3vpn deployments, or all device = vendors) to begin to address a risk within my network deployments. Kind regards, r. On 9 Dec 2012, at 23:07, Chris Hall wrote: > Jakob Heitz wrote (on Sat 08-Dec-2012 at 16:43 +0000): >> The goal of "treat as withdraw" is not to reinterpret a broken >> update message and continue the session, like nothing happened. >>=20 >> IMO, the goal is to limit the disruption caused by a session reset, >> while alerting a human to fix the problem that no machine can. >=20 > I guess you are suggesting that it does not then matter if a broken > UPDATE message results in some NLRI being missed, and so not > "treated-as-withdraw", and hence the receiver continues with some > invalid or out of date routes, for some time. >=20 > Clearly session-reset is a less than perfect remedy. But in proposing > an alternative treatment, perhaps "first do no harm" is as good a > guide as any. I think that to achieve that, one needs to be sure that > *all* NLRI in a broken update can be identified if "treat-as-withdraw" > is to be applied. =20 >=20 > If the intention is to "treat-as-withdraw" any NLRI which is visible, > but continue the session in any case (so, accepting the risks of > invalid or out of date routes) then I think the draft should estimate > the risks and set out a justification for this being a less-bad remedy > than session-reset. >=20 > Of course, a major issue with session-reset is that the error may well > simply be repeated, creating a ghastly cycle session-reset/restart. > It could well be better to avoiding session-reset, and continue with > some invalid or out of date routes -- or a while, defined somehow ? I > just don't know how to demonstrate that, or how to limit the downside > of accepting that risk, etc. >=20 > "Treat-as-withdraw" is an excellent and minimally disruptive response > in those cases where all NLRI can be identified. But it is not the > only alternative to session-reset. If there is doubt and uncertainty > about some routes, the receiver could deem *all* routes learned from > the peer in question to be "routes-of-last-resort", which it then uses > if and only if it had nothing else, but would not advertise them to > other peers. This is just short of a "session-reset", and avoids > falling into a cycle of session-reset/restart. >=20 > Chris >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From chris.hall@highwayman.com Sun Dec 9 16:12:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A59921F8D28 for ; Sun, 9 Dec 2012 16:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RQY67KRSQyf for ; Sun, 9 Dec 2012 16:12:41 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id 431BA21F8D22 for ; Sun, 9 Dec 2012 16:12:41 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 1B47D38407C; Mon, 10 Dec 2012 00:12:40 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id E318038406F; Mon, 10 Dec 2012 00:12:39 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 00:12:39 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Thqz8-0005ft-Cf; Mon, 10 Dec 2012 00:12:38 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10C90F@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E10C90F@eusaamb109.ericsson.se> Date: Mon, 10 Dec 2012 00:12:32 -0000 Organization: Highwayman Message-ID: <07ea01cdd66b$101ca590$3055f0b0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwLHrUJylz4438A= Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 00:12:42 -0000 Jakob Heitz wrote (on Sun 09-Dec-2012 at 23:37 +0000) > IMO, another goal is not to require any change to the peer. > Not even a little bit. Sure. It would be good to be able to improve error handling unilaterally. As discussed elsewhere, I think it is possible to do that, subject to some limitations. Without those limitations, the receiver is at risk of applying "treat-as-withdraw", but failing to identify all NLRI in the message, and hence continuing with some invalid and/or out of date routes. IMO that is best avoided. There may be a good argument for rejecting the limitations and accepting the risk of some invalid and/or out of date routes -- I look forward to considering it. > Changing the peer behaviour (even a little bit) > is an entirely different story. Hmmm. Section 3 of the draft states: "To facilitate the determination of the NLRI field in an UPDATE with a malformed attribute, the MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first..." which looks like a change in peer behaviour to me... but my eyesight is not what it was ? Chris > On Sunday, December 09, 2012 3:07 PM, Chris Hall > wrote: > > > Jakob Heitz wrote (on Sat 08-Dec-2012 at 16:43 +0000): > >> The goal of "treat as withdraw" is not to reinterpret a broken > >> update message and continue the session, like nothing happened. > >> > >> IMO, the goal is to limit the disruption caused by a session > reset, > >> while alerting a human to fix the problem that no machine can. > > > > I guess you are suggesting that it does not then matter if a > broken > > UPDATE message results in some NLRI being missed, and so not > > "treated-as-withdraw", and hence the receiver continues with some > > invalid or out of date routes, for some time. > > > > Clearly session-reset is a less than perfect remedy. But in > proposing > > an alternative treatment, perhaps "first do no harm" is as good a > > guide as any. I think that to achieve that, one needs to be sure > that > > *all* NLRI in a broken update can be identified if > > "treat-as-withdraw" is to be applied. > > > > If the intention is to "treat-as-withdraw" any NLRI which is > visible, > > but continue the session in any case (so, accepting the risks of > > invalid or out of date routes) then I think the draft should > estimate > > the risks and set out a justification for this being a less-bad > > remedy than session-reset. > > > > Of course, a major issue with session-reset is that the error may > well > > simply be repeated, creating a ghastly cycle session- > reset/restart. > > It could well be better to avoiding session-reset, and continue > with > > some invalid or out of date routes -- or a while, defined somehow > ? I > > just don't know how to demonstrate that, or how to limit the > downside > > of accepting that risk, etc. > > > > "Treat-as-withdraw" is an excellent and minimally disruptive > response > > in those cases where all NLRI can be identified. But it is not > the > > only alternative to session-reset. If there is doubt and > uncertainty > > about some routes, the receiver could deem *all* routes learned > from > > the peer in question to be "routes-of-last-resort", which it then > uses > > if and only if it had nothing else, but would not advertise them > to > > other peers. This is just short of a "session-reset", and avoids > > falling into a cycle of session-reset/restart. > > > > Chris > > > > -- > Jakob Heitz.= From jakob.heitz@ericsson.com Sun Dec 9 16:32:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD8221F8D92 for ; Sun, 9 Dec 2012 16:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiYORXj8brUn for ; Sun, 9 Dec 2012 16:32:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E487A21F8D3C for ; Sun, 9 Dec 2012 16:32:49 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBA0gohN019645; Sun, 9 Dec 2012 18:42:52 -0600 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 9 Dec 2012 19:32:41 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Sun, 9 Dec 2012 19:32:41 -0500 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCqgAGK/gCAAJrggIAA4PUAgAAGNdyAAlGBgP//tAywgABeLwD//7HQww== Date: Mon, 10 Dec 2012 00:32:41 +0000 Message-ID: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10C90F@eusaamb109.ericsson.se>, <07ea01cdd66b$101ca590$3055f0b0$@highwayman.com> In-Reply-To: <07ea01cdd66b$101ca590$3055f0b0$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 00:32:50 -0000 On Dec 9, 2012, at 4:12 PM, "Chris Hall" wrote: > Jakob Heitz wrote (on Sun 09-Dec-2012 at 23:37 +0000) >> IMO, another goal is not to require any change to the peer. >> Not even a little bit. >=20 > Sure. It would be good to be able to improve error handling > unilaterally. As discussed elsewhere, I think it is possible to do > that, subject to some limitations. >=20 > Without those limitations, the receiver is at risk of applying > "treat-as-withdraw", but failing to identify all NLRI in the message, > and hence continuing with some invalid and/or out of date routes. IMO > that is best avoided. There may be a good argument for rejecting the > limitations and accepting the risk of some invalid and/or out of date > routes -- I look forward to considering it. =20 >=20 >> Changing the peer behaviour (even a little bit) >> is an entirely different story. >=20 > Hmmm. Section 3 of the draft states: >=20 > "To facilitate the determination of the NLRI field > in an UPDATE with a malformed attribute, the > MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if > present) SHALL be encoded as the very first..." >=20 > which looks like a change in peer behaviour to me... but my eyesight > is not what it was ? That is not required. It is a SHALL. If the peer does it, great. If not, no= thing broke. It's different to requiring a protocol change.= From chris.hall@highwayman.com Sun Dec 9 17:06:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6A21F8DA3 for ; Sun, 9 Dec 2012 17:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcn2MImlL6m5 for ; Sun, 9 Dec 2012 17:06:35 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta010.mxout.tbr.inty.net [91.221.168.51]) by ietfa.amsl.com (Postfix) with ESMTP id EADD521F8DA4 for ; Sun, 9 Dec 2012 17:06:34 -0800 (PST) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 0C6536F813F; Mon, 10 Dec 2012 01:06:34 +0000 (GMT) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id E4EDB6F80DB; Mon, 10 Dec 2012 01:06:33 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tbr.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 01:06:33 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ThrpJ-0005fy-2r; Mon, 10 Dec 2012 01:06:33 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10C90F@eusaamb109.ericsson.se>, <07ea01cdd66b$101ca590$3055f0b0$@highwayman.com> In-Reply-To: Date: Mon, 10 Dec 2012 01:06:25 -0000 Organization: Highwayman Message-ID: <000301cdd672$9820e1c0$c862a540$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwLHrUJyAVfMhB0B3NGDJ5ckpxhw Content-Language: en-gb X-MDF-HostID: 3 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 01:06:35 -0000 Jakob Heitz wrote (on Mon 10-Dec-2012 at 00:33 +0000): > On Dec 9, 2012, at 4:12 PM, Chris Hall wrote: .... > > Hmmm. Section 3 of the draft states: > > > > "To facilitate the determination of the NLRI field > > in an UPDATE with a malformed attribute, the > > MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if > > present) SHALL be encoded as the very first..." > > > > which looks like a change in peer behaviour to me... but my > > eyesight is not what it was ? > That is not required. It is a SHALL. If the peer does it, great. If > not, nothing broke. It's different to requiring a protocol change. Dunno where this is getting us, but RFC2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. FWIW I loathe this use of SHALL -- MUST is more direct and obvious. Anyway, clearly it would be best if improvements can be made to error handling without requiring both ends to change. Chris From jsw@inconcepts.biz Sun Dec 9 18:25:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67E121F8DB7 for ; Sun, 9 Dec 2012 18:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubaZemTghoOZ for ; Sun, 9 Dec 2012 18:25:53 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5E21F8DB6 for ; Sun, 9 Dec 2012 18:25:53 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so7921971ieb.31 for ; Sun, 09 Dec 2012 18:25:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=i/BQG5ukIJAtekpRPXElzvWXQghzxktLGo0o+BhMeJw=; b=f72fo6ocbO7RXYz+3T27Jsxnl69bWZjYDnohoGQJDqxiEb3TDSPa9bQ60lvgkGsTaP BS3fH0e7rlLn9eF4LUsnynLPmygtbgI7/pWpX7c4d82X9dJZjYK94S3lbMd8toxPJVIy i49mpBoc8jg71U8IdEZDr4Var75SLjGPRFbfvjWY4sBozPeh0qQ0PIjKDkDtWVtdMgWJ KVw+2DFINeizh1tCZ124otyYEywsQ5+dcuTPY6tZYrnwLpM0GF1BX4OjpYUtYHJgHWwZ gvWRLaxzUGImvSm57L6b0DTjktosWKljvo5j871CY5CSPuaB1xtAFf1l4GIi102tyIkt DSzw== MIME-Version: 1.0 Received: by 10.42.180.65 with SMTP id bt1mr9891960icb.41.1355106353342; Sun, 09 Dec 2012 18:25:53 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sun, 9 Dec 2012 18:25:53 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <07e901cdd667$31c593e0$9550bba0$@highwayman.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <07e901cdd667$31c593e0$9550bba0$@highwayman.com> Date: Sun, 9 Dec 2012 21:25:53 -0500 Message-ID: From: Jeff Wheeler To: Chris Hall Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnYBmoN0y7s9Dq71x1WGR0WMkegf4AVGYlJIv9BXCy9HwUJMgDjmv6pLqvJWdJf0ltzOTK3 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 02:25:54 -0000 On Sun, Dec 9, 2012 at 6:44 PM, Chris Hall wrote: > end. However, forming these attributes is very simple, well > exercised, and easily tested code. It seems to me that this sort of > anomaly is more likely to be symptomatic of a framing issue than it is > to be a well-formed attribute which the sender has, for reasons > unknown, decided to send with unexpected Flags and/or Length. Here is an example from two weeks ago of some routes injected to the DFZ with malformed attribute flags. The result was that everyone running OpenBGPd more than a few months old, and some networks with Alcatel routers, and who knows what else, had their BGP sessions resetting endlessly. http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html BGP continues to be extended for purposes it was not intended to serve. MBGP is really terrible, and I am sure we all know that. Capabilities have some caveats. Secure BGP is genuinely scary. Soon, BGP will be used for MAC learning in datacenter and WAN networks. Sadly there is no improved, more robust BGP, with better sanity checks and/or more flexibility when handling faulty messages or buggy software. BGP must become more robust because people continue to extend its use with more code, and more bugs. On Sun, Dec 9, 2012 at 6:46 PM, Rob Shakir wrote: > It strikes me that your analysis is aiming to ensure 100% consistency at the device level - which I think is something that we have to accept is incompatible with overall network system robustness. I agree. I hope vendors will think hard about what default configurations they ship, but giving operators some knobs may save them a lot of money and stress when things go bad at 2am and they have got to find a work-around to their problem until their vendor TAC or in-house experts can find out what is wrong. BGP is mission-critical for everyone. If it stops working, you start losing money, instantly. The BGP protocol is the single point of failure that we all live with. Increasing its robustness is highly important. It should be done with the goal of allowing operators, without much knowledge, to potentially work around problems until they can actually be solved. This should be true whether malformed updates are the result of wrong flags, length/type errors, or ascii-art unicorns dancing in RPKI signatures. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From bruno.decraene@orange.com Mon Dec 10 01:48:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8429321F8E0D for ; Mon, 10 Dec 2012 01:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERqV143fmv0O for ; Mon, 10 Dec 2012 01:48:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B8D5321F8E0B for ; Mon, 10 Dec 2012 01:48:32 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id EF647324290; Mon, 10 Dec 2012 10:48:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C7C91238056; Mon, 10 Dec 2012 10:48:31 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 10:48:31 +0100 From: To: Rob Shakir , Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHN1MWZeU4CoZjya0yWTAtLlzW0N5gOsdgAgABaBgCAAf2wgIAACv8AgAC3CIA= Date: Mon, 10 Dec 2012 09:48:30 +0000 Message-ID: <4909_1355132911_50C5AFEF_4909_7548_1_53C29892C857584299CBF5D05346208A1161D5@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> In-Reply-To: <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.10.81217 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:48:33 -0000 Hi all, Some personal comments on the thread/subject=20 1) When we see an error, we need to balance the risk of having a few NLRI u= nreachable (the ones in the erroneous UPDATE) and the risk of having all NL= RI from that session unreachable. Some people assumes that a session can be= shutdown because there will be another path for the NLRIs. Unfortunately, = the alternate path may also suffer from the same issue. How much the altern= ate path may experience the same error MAY (SHOULD?) be a point to consider= in the solution. 2) Let's evaluate the case where we are not 100% sure we extracted all NLTI= from an erroneous UPDATE. In general, when a single UPDATE is faulty, the error is due to a specific = attribute set by the originator. Then if we assume that both MP_REACH & MP_= UNREACH are not present in the same update, then only the NLRIs from the or= iginator are impacted. Given that this is the one who played with the attri= bute, this seems fair to me that the originator is the one who assume that = risk. This may call for not mixing both MP_REACH & MP_UNREACH in the same UPDATE = message. 3) We need a short term solution which is local, i.e. not requiring change = on peers, in order to be able to deploy it (soon). That being done, if this turn out to be too limiting/risky, IMO we could al= so explore a more long term solution requiring a cooperation from the peer.= GR based notification & enhanced GR are examples. IMO solutions requiring = interop with peers are also deployable, especially within an AS, which is t= he aspects which concern me the most (i.e. loosing both iBGP client session= s). 4) >However, I am yet to be convinced of the value of accepting a >well-known attribute (eg. ORIGIN) if it has invalid Flags or does not >have (one of) the known valid Length(s). I assume that accepting such >an attribute is designed to cope with for software issues at the far >end. However, forming these attributes is very simple, well >exercised, and easily tested code.=20=20 I could agree if and only if we are 100% sure to only kill the "far end" wh= ich is responsible for the error. On the contrary, once the attribute has propagated, deciding to shut down t= he session could affect losts of NLRI on both the nominal and backup sessio= ns. So I don't think a single (bit) error should have such consequences. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Mon Dec 10 01:50:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D9221F8E47 for ; Mon, 10 Dec 2012 01:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApYB4RUu6QDD for ; Mon, 10 Dec 2012 01:50:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 423FB21F8E45 for ; Mon, 10 Dec 2012 01:50:31 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8A94818C302; Mon, 10 Dec 2012 10:50:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6BCAA35C045; Mon, 10 Dec 2012 10:50:30 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 10:50:30 +0100 From: To: Jeff Wheeler , Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHN1MWZeU4CoZjya0yWTAtLlzW0N5gN5nqAgAMtk4CAACz+gIAAiPOA Date: Mon, 10 Dec 2012 09:50:29 +0000 Message-ID: <15157_1355133030_50C5B066_15157_708_1_53C29892C857584299CBF5D05346208A1161FF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <07e901cdd667$31c593e0$9550bba0$@highwayman.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:50:32 -0000 >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff >Wheeler > >On Sun, Dec 9, 2012 at 6:44 PM, Chris Hall wro= te: >> end. However, forming these attributes is very simple, well >> exercised, and easily tested code. It seems to me that this sort of >> anomaly is more likely to be symptomatic of a framing issue than it is >> to be a well-formed attribute which the sender has, for reasons >> unknown, decided to send with unexpected Flags and/or Length. > >Here is an example from two weeks ago of some routes injected to the >DFZ with malformed attribute flags. The result was that everyone >running OpenBGPd more than a few months old, and some networks with >Alcatel routers, and who knows what else, had their BGP sessions >resetting endlessly. >http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html In that specific case, it was not a BGP protocol error, but a bug in the ro= uter receiving the UPDATE. i.e. draft-ietf-idr-error-handling would not cha= nge this. However, this is an example that error in flags, including in well known at= tributes, may happen. And in general, I agree with Jeff & Rob: BGP is mission critical to network= s. Shutting it down for a wrong flag/bit should not be the first option. > >BGP continues to be extended for purposes it was not intended to >serve. MBGP is really terrible, and I am sure we all know that. >Capabilities have some caveats. Secure BGP is genuinely scary. Soon, >BGP will be used for MAC learning in datacenter and WAN networks. > >Sadly there is no improved, more robust BGP, with better sanity checks >and/or more flexibility when handling faulty messages or buggy >software. BGP must become more robust because people continue to >extend its use with more code, and more bugs. > >On Sun, Dec 9, 2012 at 6:46 PM, Rob Shakir wrote: >> It strikes me that your analysis is aiming to ensure 100% consistency at= the >device level - which I think is something that we have to accept is >incompatible with overall network system robustness. > >I agree. I hope vendors will think hard about what default >configurations they ship, but giving operators some knobs may save >them a lot of money and stress when things go bad at 2am and they have >got to find a work-around to their problem until their vendor TAC or >in-house experts can find out what is wrong. > >BGP is mission-critical for everyone. If it stops working, you start >losing money, instantly. The BGP protocol is the single point of >failure that we all live with. Increasing its robustness is highly >important. It should be done with the goal of allowing operators, >without much knowledge, to potentially work around problems until they >can actually be solved. This should be true whether malformed updates >are the result of wrong flags, length/type errors, or ascii-art >unicorns dancing in RPKI signatures. > >-- >Jeff S Wheeler >Sr Network Operator / Innovative Network Concepts >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jsw@inconcepts.biz Mon Dec 10 02:40:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9482421F8E5F for ; Mon, 10 Dec 2012 02:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrgWEjROsEuB for ; Mon, 10 Dec 2012 02:40:46 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id B117E21F8E5E for ; Mon, 10 Dec 2012 02:40:46 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so7592916iea.10 for ; Mon, 10 Dec 2012 02:40:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+LdJuzowiyCQGtrRIOtB6Py2DEjiIvA3g39v2BZwZ7w=; b=biJndYkG13N+nvu0MTmPb4fvwj6HXjVyNa0HHsTkjZv2QaFB2OfvfHh1JzATth0qun GDWyMbvTV1hfg3IesGBZjMjSJKkLVogQddAaBrvvdGIdxolwNF5h4UqpWnNXcJhl/JtO Z6OvTJ/22kN4rUl7VP2r24Zqd1+Z1VmyxKuLRfib2+kXTc97aja7w3B2HH/b7plGYiC3 X+hsdO3vvY3xY9YX6LKNArotzMd5NOXBXy7Qq7ywbMxC0Ng0mNSKPAwFSoKA4UhFbx/N 5kXLvrGVhCsC3+LO/siHW9Mam3zB14lAwuThyIlq7MyP/hAXdhqG73TiNpLuscfjJ+H9 +Ayg== MIME-Version: 1.0 Received: by 10.50.242.73 with SMTP id wo9mr6221766igc.36.1355136045581; Mon, 10 Dec 2012 02:40:45 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 10 Dec 2012 02:40:45 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <15157_1355133030_50C5B066_15157_708_1_53C29892C857584299CBF5D05346208A1161FF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <07e901cdd667$31c593e0$9550bba0$@highwayman.com> <15157_1355133030_50C5B066_15157_708_1_53C29892C857584299CBF5D05346208A1161FF@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Mon, 10 Dec 2012 05:40:45 -0500 Message-ID: From: Jeff Wheeler To: bruno.decraene@orange.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkN/IjeuHsyD5nyHXW8QdjcwBHEDLLDpRTQ8kbQ6R+XuaPq8/VYHHBg3OacleofIQdzdkqr Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 10:40:47 -0000 On Mon, Dec 10, 2012 at 4:50 AM, wrote: >>http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html > > In that specific case, it was not a BGP protocol error, but a bug in the router receiving the UPDATE. i.e. draft-ietf-idr-error-handling would not change this. > However, this is an example that error in flags, including in well known attributes, may happen. It is also an example of when more choices for fault handling would have significantly reduced the operational impact on networks who had the buggy routers. If my customers who had OpenBGPd could simply configure their router like, "bgp fault-tolerance attribute-malformed treat-as-withdraw" they could have got themselves back online. Because this is not allowed by the current BGP protocol, vendors have disincentive to provide such flexibility, even though it could sometimes help customers. I understand why vendors do not want to give their customers "too much rope" but as the uses for BGP continue to expand, and more new code and new vendors continue to use it within the network, vendors are likely to find that customers demand more choices for handling malfunctions. > And in general, I agree with Jeff & Rob: BGP is mission critical to networks. Shutting it down for a wrong flag/bit should not be the first option. I would like to show a detailed example of a mistake that is not in a TYPE or LENGTH field can make it impossible for the router to know what prefixes are in an UPDATE. Chris's post focused on "framing errors" but these are unfortunately not the only kind of errors that are serious. Imagine if a route is originated with MPLS labels in the reachability, and the bottom-of-stack bit is not set on any of the labels. Do you know what happens? Receiving routers are not only unable to decide what to do with this update, they can't even figure out what prefixes the update is for, because the bottom-of-stack bit indicates to the receiver where the prefixes actually begin. In effect, the label data is part of the framing. I have made notes and illustrations on RFC3107 Pg3: http://inconcepts.biz/~jsw/img/1120824-rfc3107pg3.jpg Sorry this is hand-drawn and scanned into the computer but it is legible. What should your router do if it can't even figure out what prefixes are being updated? It can't "treat as withdraw" but some option better than close the session should be permissible. I really think a wholesale modification to the BGP protocol will eventually be necessary because of all the new uses for BGP. Yes, MP-BGP is allowing it to do new things, but not with the kind of fault tolerance that customers should expect. Improving the choices for handling faults is clearly a good effort. However, it is unfortunate that there are so many kinds of bugs which require the router to make potentially unsafe guesses. Until there is a BGPv5 with an improved approach to length encoding and more resilience against faulty implementation on one device cascading to others in the network, we will continue to have questionable solutions to bad problems. I think it's important to realize this so myopia about BGPv4's limits does not discourage anyone from wanting to make it as robust as possible If The Operator decides to configure his router using vendor-supplied robustness options. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From chris.hall@highwayman.com Mon Dec 10 05:27:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE6021F8C1A for ; Mon, 10 Dec 2012 05:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juny6cKSZL6T for ; Mon, 10 Dec 2012 05:27:05 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tbr.inty.net [91.221.168.45]) by ietfa.amsl.com (Postfix) with ESMTP id 376AB21F8C14 for ; Mon, 10 Dec 2012 05:27:04 -0800 (PST) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id 8D423A0C08B; Mon, 10 Dec 2012 13:27:03 +0000 (GMT) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id 5F545A0C089; Mon, 10 Dec 2012 13:27:03 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tbr.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 13:27:02 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Ti3Nu-0005gY-0i; Mon, 10 Dec 2012 13:27:02 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> In-Reply-To: <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> Date: Mon, 10 Dec 2012 13:26:56 -0000 Organization: Highwayman Message-ID: <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwCjhW3Cl09w78A= Content-Language: en-gb X-MDF-HostID: 9 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:27:06 -0000 Rob Shakir wrote (on Sun 09-Dec-2012 at 23:47 +0000): .... > In my opinion (and as per Jakob's comment earlier in the thread) you > are looking at the treat-as-withdraw behaviour in the wrong way. I > have written multiple messages about this previously, but let me > reiterate some of the discussions. It seems to me that "treat-as-withdraw" is "safe" if, and only if, all NLRI in a broken UPDATE can be identified. I suggest that this can be achieved in two ways: a) if the sender always sends the NLRI attributes as the first attributes -- as per the draft, AND the receiver knows that is the case -- for which a capability would serve. or: b) if the receiver requires (at a minimum) all attributes to be correctly "framed". The advantage of (a) is that one no longer really cares how badly broken the attributes are. The disadvantage of (a) is that it requires a small change to the protocol (a much smaller change than the improved error handling, but nevertheless an extra change). The advantage of (b) is that it can be applied without any change at the sender end. The disadvantage of (b) is that it will not accept every conceivable form of broken attribute. The advantage of "safe" "treat-as-withdraw" is that it does not introduce any new inconsistency in the RIB -- "first do no harm". I am not arguing that safety is essential -- I am trying to be precise about how safety may be achieved, and what the compromises are in doing so. If those compromises are unacceptable, then we need to be clear on the impact of removing the safety belt, so that it is clear whether things are better or worse: under some circumstances we may be thrown clear of the pile-up and avoid being burnt to a crisp, or we may sail through the windscreen and kiss our backsides goodbye, while on the other hand, an air-bag may be better all round; who can tell ? > The current BGP implementation of session reset optimises solely to > make sure it maintaining single device RIB consistency, and > knowledge of correct routing information being used by that local > speaker. What this misses out is the other dimension to the > correctness, which is that of whether services within the network as > a system are functional. Where we pursue anything around the revised > error handling functionality that is being discussed in this draft, > we balance the correctness of the local device's RIB, against the > functionality of the overall network system. Sure... session-reset is an extreme measure, and can be positively destructive... cue sound of many babies being ejected with bathwater. I'm happy to be counted as a fan of "safe" "treat-as-withdraw". And yes, that would preserve the correctness of the RIB, or at least avoid incorrectness thereof. In case (b) the safety of "treat-as-withdraw" means that there is an error for which session-reset would continue to be the result -- namely a "framing" error. For all other errors, case (b) avoids session-reset -- hurrah ! Over time case (b) would be overtaken by case (a), as more devices are upgraded to the new error handling. So, the residual session-reset cases would dwindle away. If "framing errors" are determined to be a significant risk, then I guess that's an incentive for the deployment of case (a). But, "unsafe" "treat-as-withdraw" may still be better than session-reset, which we are agreed is simply ghastly. Inconsistencies in the RIB may, as you say, be tolerable in the larger context of the network, and treatable at an operational level -- getting away from the tedious bits and stuff that I keep droning on about. I note that the inconsistencies which may be introduced by "unsafe" "treat-as-withdraw" are perhaps different to other inconsistencies: in particular, the operator can no longer tell which routes are good and which are bad. In "unsafe" "treat-as-withdraw", each broken UPDATE may or may not have contained some NLRI which should have been withdrawn, or which are now out of date, but the receiver does not know which (if any) NLRI are in that (inconsistent) state ! I note also that Appendix A of the draft waxes lyrical on the subject of "Why not Discard UPDATE Messages". With "unsafe" "treat-as-withdraw" the effect is to discard *part* of the UPDATE message -- the part which may or may not (and you cannot tell which) contain NLRI attribute(s) which have been obscured by earlier broken attribute(s). I do not know how to assess the possible impact of "unsafe" "treat-as-withdraw"... but Appendix A appears to argue against ? It is perfectly possible that I have my hands clenched firmly around the wrong end of this stick. If the risk of "unsafe" "treat-as-withdraw" is understood and it is determined that the cure is (generally) not worse than the disease, then I can let go (yay !). > As such, I think we have to accept that the current protocol > behaviour can be *very* damaging to network deployments and hence > operators of real networks are prepared to tweak this balance > somewhat. The requirements draft that I am continuing to edit tries > to lay out a framework whereby one can limit the amount of time over > which this inconsistency may affect the network through having means > by which RIB consistency may be recovered. For example, these are: > > - A more selective means by which ROUTE REFRESH can be achieved > (e.g., one-time ORF, using rt-constrain to refresh a subset of > routes, or building upon the Enhanced GR UPDATE-VERSION message) - > which allows the individual speaker to recovery consistency of the > RIB. That appears to require the receiver to know which NLRI are no longer consistent, which is not entirely possible with "unsafe" "treat-as-withdraw". > - Better ways to be able to do session reset (the observation being > that the session-level error handling causes most problems due to > forwarding outages during it) - which is answered by GR based on > NOTIFICATION, and Enhanced GR. This would not help with "unsafe" "treat-as-withdraw", since the session-reset has been avoided in any case. However, it would help in case (b). So, for "framing" errors a session-reset is required if "unsafe" "treat-as-withdraw" is to be avoided, but that session-reset would be mitigated along with all other (residual) session-resets. Mind you, changes in GR will require changes at both ends, and I suspect rather larger changes than those required for case (a) "safe" "treat-as-withdraw" -- but I guess those GR changes are more generally a Good Thing. .... > My view is that we should *not* have a capability to indicate this > behaviour. I would like a means by which I am not reliant on 3rd > party actions (be it my peers in the dfz, or l3vpn deployments, or > all device vendors) to begin to address a risk within my network > deployments. OK... to try to summarise succinctly, I think there are two levels at which "safe" "treat-as-withdraw" may be implemented, as above: a) where the sender sends NLRI attributes as required by section 3 of the draft... ...PLUS a capability... without which the receiver cannot *know* that the sender is being helpful, and has to assume otherwise. This can tolerate any (non-NLRI attribute related) aberrations. b) without any change at the sender end, ...OR where the receiver does not *know* that the sender is being helpful. This can tolerate anything except "framing" errors (as defined elsewhere). Ruling out (a) limits the choice to: i) case (b) "safe" "treat-as-withdraw" ii) "unsafe" "treat-as-withdraw" Since "unsafe" "treat-as-withdraw" gives me the screaming hab-dabs, my view would be that starting with case (b) is a reasonable compromise, as a first step towards case (a). There is obviously an incentive to deploy improved error handling. Let us assume (for a moment) that improved error handling includes the case (a) sender behaviour. Early adopters reap the benefit of case (b) improved error handling immediately on the devices where new software is deployed. And they reap the benefit of case (a) improved error handling for their iBGP just as quickly as new software is deployed across their network. For eBGP, availability of case (a) improved error handling depends on the strength of the incentive -- but good coverage requires only that the relatively small number of Transit Providers adopt reasonably quickly. However, given some way of determining the (likely ?) impact of "unsafe" "treat-as-withdraw", then one could assess whether that is better or worse than session-reset (under some circumstances ?) -- in the (unlikely ?) event that some particularly dim BGP implementation fails to correctly frame a set of attributes. I wish I knew where to start to untangle this problem. Chris From jsw@inconcepts.biz Mon Dec 10 08:13:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FF421F8525 for ; Mon, 10 Dec 2012 08:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbf4ZuEeGFt8 for ; Mon, 10 Dec 2012 08:13:28 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09A21F8523 for ; Mon, 10 Dec 2012 08:13:28 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so8818668ieb.33 for ; Mon, 10 Dec 2012 08:13:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2yPvhEfpeg165hlCL6WP+bHAn/P/kzXpCr3AtUoQIOs=; b=k0DDo2EPWfpJ0ZektyEEjgKz0zjcTZeK1joMo6nYqmdQqrwWAxodldF9hBiHy1iRai kGgsOjOSBIpIwcYDmwHM2jrn6QX6EG57GECpq7Y5kiqT2QfG6hpw0/EGyjIStgjmNjla eoFJRB02xM4m6DYlEfMNu9ytBpBvFV1WyOllmHcpTmvjyAxCy3Ek12eFJ4kuPv3SCNml Yq9UqnJQPFX7V+XtuHAc72xUXhJzMUk/pqoJYgQCgsHM9vp0RPDlFlaQ6wTZBKYv77su B0LwykEWJPiz1481wcMbUi8WSnXVF43h+udFIQB5eFktIzXBNxNGf+hu5K3JBuRqAe2F WdMQ== MIME-Version: 1.0 Received: by 10.50.36.198 with SMTP id s6mr7164461igj.23.1355156007584; Mon, 10 Dec 2012 08:13:27 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 10 Dec 2012 08:13:26 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> Date: Mon, 10 Dec 2012 11:13:26 -0500 Message-ID: From: Jeff Wheeler To: Chris Hall Content-Type: multipart/alternative; boundary=14dae9340f6d72840204d081d8c8 X-Gm-Message-State: ALoCoQlB6WvyZr+WTfW3GKuPhMfiCP14W2TlbyrsttZPWOT4oOAsVQtcSVGiFQj/AZVbyPXr+g/Z Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:13:29 -0000 --14dae9340f6d72840204d081d8c8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 10, 2012 at 8:26 AM, Chris Hall wrote: > However, given some way of determining the (likely ?) impact of > "unsafe" "treat-as-withdraw", then one could assess whether that is > better or worse than session-reset (under some circumstances ?) -- in Why is the question not answerable by one of three options? 1# ignore 2# treat-as-withdraw 3# session-reset 1# IGNORE is hazardous but probably only to the prefixes in that update (or withdraw) which means the scope of malfunction is relatively small. If someone announces a bad route to the DFZ, or a buggy switch announces wrong L3VPN information, this will not "spill over" to any other prefixes, as long as you honor any withdraw that happened to be in the same Message but before the damaged UPDATE. Yes, perhaps reachability to the affected prefixes will be gone. There could be a loop created and packets will have to expire due to TTL until this loop is resolved. But either way, I think the scope of the malfunction is only prefixes that were in the bad UPDATE. Even if they weren't packed into the same UPDATE they will share the same Attributes and so the sender is likely to make the same mistake. The exception here is if an MP_UN?REACH_NLRI Attribute is corrupt but the native NLRI in the outside part of the Message are not damaged. You would be ignoring them and causing a little bit more RIB inconsistency. 2# TREAT-AS-WITHDRAW is hazardous. Loops could be created in a native forwarding path (IPv4/IPv6 with no labels) but in MPLS VPNs or when using labeled-unicast, there will not be any loops. Reachability may be lost but if any undamaged path is available then it will be selected as best and installed. The great risk is, how do you guess what the prefixes are, if the framing is wrong? In my view, here is one way that is rather thorough for finding MP NLRIs: Beginning with or following the damaged Attribute (which one?), scan for MP_REACH_NLRI: *AttrFlags AttrType AttrLen* AFI SAFI NextHopLen NH *0x00* PfxLen Pfx (PfxLen Pfx){0,} You know what AFI, SAFI you are willing to support on this BGP session because this was determined when the session established. If you find 0x0e AFI SAFI sequences you will hope the next octet is NextHopLen and then look forward that many octets, hoping to find a 0x00 which is a handy reserved field.* If you found that 0x00 you can see if a PfxLen follows that is a sane length for this AFI SAFI -- you know it won't be >= 33 for IPv4 or >= 128 for IPv6, for example. After that you expect to skip the Pfx and keep looking for more sequences like this until you run out of AttrLen. * for information on this reserved field, see RFC4760 Pg4; for history, RFC2283 Pg3 "Number of SNPAs" So for updates to prefixes you might be able to find the MP NLRIs with a good degree of confidence even if another Attribute is damaged. With MP_UNREACH_NLRI you can similarly search for a known pattern and hope to find the MP NLRIs. If you DO get tricked by the damaged packet, you will cause yourself to withdraw routes that had nothing to do with the malfunction. This is unfortunate just to avoid the chance of loops on what is hopefully a limited number of prefixes. If the MP_REACH_NLRI or MP_UNREACH_NLRI itself is damaged then you will have a hard time finding the prefixes. Maybe they won't even be there at all, so no clever pattern match to look for them would be helpful. Whatever the sending side did to send this bad message is unknown. For problems with native, non-MP Messages, you really do not have as much context while you are looking for the NLRI. It will be hard to find them without false-positives. Fortunately you still have the opportunity for a fairly good sanity check if you simply look from the end of the Message backwards, and do a bit of consistency checking. This sounds computationally-expensive but I think it actually isn't. It would not be very hard to write an implementation of this search and test its speed. In any case, this code will not be executed except when damaged updates are encountered, and at that point, you can compare the computational expense of guessing around the problem, to the expense of resetting sessions over and over and potentially creating work all through your network. 3# SESSION-RESET everyone understands what this behavior does. If my analysis above is correct, you could easily make an argument for un-safe ignore. I think un-safe withdraw is a good OPTION because I usually believe in giving vendors lots of flexibility to offer knobs to the operator. The vendor can certainly decide how robust his un-safe withdraw checks will be. Operators can turn the knob whatever way they want, but probably IGNORE will be smart in almost all cases. If I could only have one of those two things I would rather have IGNORE. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --14dae9340f6d72840204d081d8c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 8:26 AM, Chris Hall <chris.hall@highwayman.com> wrote:
> However,= given some way of determining the (likely ?) impact of
> "unsaf= e" "treat-as-withdraw", then one could assess whether that i= s
> better or worse than session-reset (under some =A0circumstances ?) -- = in

Why is the question not answerable by one of three options?
1#= ignore
2# treat-as-withdraw
3# session-reset

1# IGNORE is haz= ardous but probably only to the prefixes in that update (or withdraw) which= means the scope of malfunction is relatively small. =A0If someone announce= s a bad route to the DFZ, or a buggy switch announces wrong L3VPN informati= on, this will not "spill over" to any other prefixes, as long as = you honor any withdraw that happened to be in the same Message but before t= he damaged UPDATE.

Yes, perhaps reachability to the affected prefixes will be gone. =A0The= re could be a loop created and packets will have to expire due to TTL until= this loop is resolved. =A0But either way, I think the scope of the malfunc= tion is only prefixes that were in the bad UPDATE. =A0Even if they weren= 9;t packed into the same UPDATE they will share the same Attributes and so = the sender is likely to make the same mistake. =A0The exception here is if = an MP_UN?REACH_NLRI Attribute is corrupt but the native NLRI in the outside= part of the Message are not damaged. =A0You would be ignoring them and cau= sing a little bit more RIB inconsistency.

2# TREAT-AS-WITHDRAW is hazardous. =A0Loops could be created in a nativ= e forwarding path (IPv4/IPv6 with no labels) but in MPLS VPNs or when using= labeled-unicast, there will not be any loops. =A0Reachability may be lost = but if any undamaged path is available then it will be selected as best and= installed.

The great risk is, how do you guess what the prefixes are, if the frami= ng is wrong? =A0In my view, here is one way that is rather thorough for fin= ding MP NLRIs:

Beginning with or following the damaged Attribute (wh= ich one?), scan for MP_REACH_NLRI:
= AttrFlags AttrType AttrLen AFI SAFI NextHopLen NH 0x00 PfxLen= Pfx (PfxLen Pfx){0,}

You know what AFI, SAFI you are willing= to support on this BGP session because this was determined when the sessio= n established. =A0If you find 0x0e AFI SAFI sequences you will hope the nex= t octet is NextHopLen and then look forward that many octets, hoping to fin= d a 0x00 which is a handy reserved field.* =A0If you found that 0x00 you ca= n see if a PfxLen follows that is a sane length for this AFI SAFI -- you kn= ow it won't be >=3D 33 for IPv4 or >=3D 128 for IPv6, for example= . =A0After that you expect to skip the Pfx and keep looking for more sequen= ces like this until you run out of AttrLen.

* for information on this reserved field, see RFC4760 Pg4; f= or history, RFC2283 Pg3 "Number of SNPAs"

So for updates to prefixes you might be able to find the MP NLRIs with a = good degree of confidence even if another Attribute is damaged.

With MP_UNREACH_NLRI you can similarly search for a kno= wn pattern and hope to find the MP NLRIs.

If you DO get trick= ed by the damaged packet, you will cause yourself to withdraw routes that h= ad nothing to do with the malfunction. =A0This is unfortunate just to avoid= the chance of loops on what is hopefully a limited number of prefixes.

If the MP_REACH_NLRI or MP_UNREACH_NLRI itself is damag= ed then you will have a hard time finding the prefixes. =A0Maybe they won&#= 39;t even be there at all, so no clever pattern match to look for them woul= d be helpful. =A0Whatever the sending side did to send this bad message is = unknown.

For problems with native, non-MP Messages, you really d= o not have as much context while you are looking for the NLRI. =A0It will b= e hard to find them without false-positives. =A0Fortunately you still have = the opportunity for a fairly good sanity check if you simply look from the = end of the Message backwards, and do a bit of consistency checking. =A0This= sounds computationally-expensive but I think it actually isn't. =A0It = would not be very hard to write an implementation of this search and test i= ts speed.

In any case, this code will not be executed except when= damaged updates are encountered, and at that point, you can compare the co= mputational expense of guessing around the problem, to the expense of reset= ting sessions over and over and potentially creating work all through your = network.

3# SESSION-RESET everyone understands what this behavio= r does.

If my analysis above is correct, you could= easily make an argument for un-safe ignore. =A0I think un-safe withdraw is= a good OPTION because I usually believe in giving vendors lots of flexibil= ity to offer knobs to the operator. =A0The vendor can certainly decide how = robust his un-safe withdraw checks will be. =A0Operators can turn the knob = whatever way they want, but probably IGNORE will be smart in almost all cas= es. =A0If I could only have one of those two things I would rather have IGN= ORE.

--=A0
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator =A0/ = =A0Innovative Network Concepts
--14dae9340f6d72840204d081d8c8-- From chris.hall@highwayman.com Mon Dec 10 08:18:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03CE21F8541 for ; Mon, 10 Dec 2012 08:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.216 X-Spam-Level: ** X-Spam-Status: No, score=2.216 tagged_above=-999 required=5 tests=[AWL=-2.245, BAYES_00=-2.599, GB_SUMOF=5, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MazEA3PyvSZG for ; Mon, 10 Dec 2012 08:18:48 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id B785321F853D for ; Mon, 10 Dec 2012 08:18:47 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 4E77BA64451; Mon, 10 Dec 2012 16:18:46 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 2A5FCA64435; Mon, 10 Dec 2012 16:18:46 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 16:18:45 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Ti644-0005gk-D2; Mon, 10 Dec 2012 16:18:44 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <07e901cdd667$31c593e0$9550bba0$@highwayman.com> In-Reply-To: Date: Mon, 10 Dec 2012 16:18:39 -0000 Organization: Highwayman Message-ID: <007801cdd6f2$069cc720$13d65560$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGYNqrRARMQrlQBmj3n7ZddXMMQ Content-Language: en-gb X-MDF-HostID: 8 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:18:51 -0000 Jeff Wheeler wrote (on Mon 10-Dec-2012 at 02:26 +0000): > On Sun, Dec 9, 2012 at 6:44 PM, Chris Hall > wrote: > > end. However, forming these attributes is very simple, well > > exercised, and easily tested code. It seems to me that this > > sort of anomaly is more likely to be symptomatic of a framing > > issue than it is to be a well-formed attribute which the > > sender has, for reasons unknown, decided to send with > > unexpected Flags and/or Length. > Here is an example from two weeks ago of some routes injected to the > DFZ with malformed attribute flags. Evidence :-) > The result was that everyone > running OpenBGPd more than a few months old, and some networks with > Alcatel routers, and who knows what else, had their BGP sessions > resetting endlessly. > http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html It would seem that some BGP implementation(s) managed to send an attribute with a Flags octet with a bit set in the LS part (which by RFC it MUST not do) and some implementation failed to ignore that (which by RFC it MUST do). [I guess the originator is using the LS bits for its own nefarious purposes.] So, we have two bugs, in a trivial operation which is common to all attribute handling. The evidence is clear: even trivially silly bugs happen. What's more, such bugs can happen in code which is intended to improve robustness. So... the evidence suggests that adding more code, with the intent of improving robustness, also adds opportunities for more bugs. I wonder whether the requirement to ignore the meaningless bits has improved or reduced robustness. By tolerating meaningless rubbish, the system manages to sweep under the carpet a failure at the sender end. If the rubbish was not tolerated, then one of these bugs would never have made it out of the lab -- unless, of course, there was a bug in the receiving code used during testing ! But the real lesson here is not so much that fault tolerance fails to reveal faults, but that *silent* fault tolerance does. The draft goes further, and requires that some bits which *do* have meaning should be ignored if their "true" value can be deduced from other parts of the attribute. In the light of the above, this doesn't give me a warm feeling. What's worse, the extra code required by the draft is in exception paths, which 99.9...9% of the time are not exercised. The bugs in your example are on the main path for goodness sake ! ... > BGP is mission-critical for everyone. If it stops working, you > start losing money, instantly. The BGP protocol is the single > point of failure that we all live with. Increasing its > robustness is highly important. Amen to that. The problem with any discussion of how to handle errors in attributes is that it tends to start with the unspoken assumption that the attributes in question have been correctly identified -- which means that the discussion starts with a false or at least doubtful premise. For example: we all know that a LOCAL_PREF attribute is neither use nor ornament when received from an eBGP peer. So, we honestly don't care what the attribute says, or whether its length is correct, we can just throw it on the floor and get on with the business of keeping the network running. Further, LOCAL_PREF is a well-known attribute, so we know it's not Optional and it is Transitive, so it seems daft to worry about the state of those bits (also the Partial bit). BUT: to arrive at the octets which appear to be a LOCAL_PREF attribute, unless it is the first attribute, we have stepped over one or more earlier attributes, on the basis that each one's length is correct. So... what we seem to feel happy treating as a malformed LOCAL_PREF, may actually be some part of some other attribute(s), because some earlier attribute length is broken and we either did not realise that, or we chose to ignore the problem (in the interests of rubustness !). There is no complete way to resolve this for all attributes. For "treat-as-withdraw", however, the key thing is to be able to identify just the NLRI. If any NLRI attributes are guaranteed by the sender to be the first attributes, then the problem is finessed -- the receiver doesn't need to care which attribute is malformed or how, it can just "treat-as-withdraw" and move on, leaving the session running and (presumably) the operational layer running round trying to resolve the root cause. Otherwise, we must consider ways to achieve an acceptable compromise between (a) accurately identifying every attribute the sender sent, and (b) the risk of proceeding with an incomplete set of attributes, some of which are malformed in some way. Noting that the goal is to at least identify the NLRI attributes or be comfortable assuming that one or both of MP_REACH_NLRI and MP_UNREACH_NLRI are not visible because they are not there (and not because they are buried under a heap of broken attribute(s)). I'm sorry to keep harping on about this balls-aching detail, when the real aim is to keep the network running... But, to resolve the broken attributes problem we have to decide which part of each attribute to trust, given that all parts may be broken. As discussed elsewhere, if the sum of the (apparent) attribute lengths is correct, then prima facie we can identify all the attributes. But, suppose we then find (say) something which appears to be LOCAL_PREF, but whose flags or length are incorrect, or which should not be there in the first place. Now we must decide, on the balance of probabilities, whether this really a broken LOCAL_PREF or actually a symptom of a more serious problem, namely that the length(s) of some earlier attribute(s) are, in fact, broken, and we have failed to correctly identify all attributes. If we have failed to identify all attributes, we may be failing to find all the NLRI. If we fail to find all the NLRI we may me in more or less trouble network-state-wise. It's a bleedin' nightmare. Anyway... bad cases make bad law, as they say. So, the incident you reference certainly says that there is no such thing as a bug which is too trivial to make it out into the wild. However, when faced with deciding whether some anomaly is the symptom of a trivial bug, or the symptom of something more serious, then (a) one might give the sending software the benefit of the doubt, and assume it's not a trivial bug, particularly as (b) assuming a trivial bug may well be the more dangerous option. > It should be done with the goal of allowing operators, > without much knowledge, to potentially work around problems > until they can actually be solved. This should be true > whether malformed updates are the result of wrong flags, > length/type errors, or ascii-art unicorns dancing in RPKI > signatures. Well, perhaps what you really want is not some improved way for BGP to automagically work around these issues, but for: * significantly better diagnostic information, so that the operator can properly assess a given problem, * knobs, switches and dials to patch up particular broken UPDATE messages, pro tem. >From my (software) perspective, that's a more interesting challenge. Certainly more interesting than trying to solve the intractable problem of parsing the unparsable to some acceptable extent, TBD. And possibly more robust than layering more edge-cases onto the attribute handling code ! Mind you, I suspect that operational remedies will also depend on the accurate identification of all affected NLRI, which is the horse I rode in on :-( Chris From jakob.heitz@ericsson.com Mon Dec 10 08:31:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1B21F84EE for ; Mon, 10 Dec 2012 08:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SMc2b4MC3bT for ; Mon, 10 Dec 2012 08:31:12 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 43B1621F84ED for ; Mon, 10 Dec 2012 08:31:12 -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 qBAGfFhe022013; Mon, 10 Dec 2012 10:41:16 -0600 Received: from EUSAAHC007.ericsson.se (147.117.188.93) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Dec 2012 11:31:00 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 11:31:00 -0500 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCqgAGK/gCAAJrggIAA4PUAgAAGNdyAAlGBgIAACv4AgADlMQD//9+bDQ== Date: Mon, 10 Dec 2012 16:30:58 +0000 Message-ID: <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh>, <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> In-Reply-To: <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 16:31:13 -0000 If, at the time a bgp speaker detects a malformation in a received UPDATE, = it has completely parsed at least one of: . Withdrawn routes section . NLRI . MP_REACH . MP_UNREACH then it assumes that there are no more of these following. A capability to say so adds nothing. The router will behave exactly the same way. Either way, human intervention is required to restore correct routing. -- Jakob Heitz. On Dec 10, 2012, at 5:27 AM, "Chris Hall" wrote= : > Rob Shakir wrote (on Sun 09-Dec-2012 at 23:47 +0000): > .... >> In my opinion (and as per Jakob's comment earlier in the thread) you >> are looking at the treat-as-withdraw behaviour in the wrong way. I >> have written multiple messages about this previously, but let me >> reiterate some of the discussions. >=20 > It seems to me that "treat-as-withdraw" is "safe" if, and only if, all > NLRI in a broken UPDATE can be identified. >=20 > I suggest that this can be achieved in two ways: >=20 > a) if the sender always sends the NLRI attributes > as the first attributes -- as per the draft, >=20 > AND >=20 > the receiver knows that is the case -- for which > a capability would serve. >=20 > or: >=20 > b) if the receiver requires (at a minimum) all > attributes to be correctly "framed". >=20 > The advantage of (a) is that one no longer really cares how badly > broken the attributes are. The disadvantage of (a) is that it > requires a small change to the protocol (a much smaller change than > the improved error handling, but nevertheless an extra change). >=20 > The advantage of (b) is that it can be applied without any change at > the sender end. The disadvantage of (b) is that it will not accept > every conceivable form of broken attribute. >=20 > The advantage of "safe" "treat-as-withdraw" is that it does not > introduce any new inconsistency in the RIB -- "first do no harm". >=20 > I am not arguing that safety is essential -- I am trying to be precise > about how safety may be achieved, and what the compromises are in > doing so. If those compromises are unacceptable, then we need to be > clear on the impact of removing the safety belt, so that it is clear > whether things are better or worse: under some circumstances we may be > thrown clear of the pile-up and avoid being burnt to a crisp, or we > may sail through the windscreen and kiss our backsides goodbye, while > on the other hand, an air-bag may be better all round; who can tell ? >=20 >> The current BGP implementation of session reset optimises solely to >> make sure it maintaining single device RIB consistency, and >> knowledge of correct routing information being used by that local >> speaker. What this misses out is the other dimension to the >> correctness, which is that of whether services within the network as >> a system are functional. Where we pursue anything around the revised >> error handling functionality that is being discussed in this draft, >> we balance the correctness of the local device's RIB, against the >> functionality of the overall network system. >=20 > Sure... session-reset is an extreme measure, and can be positively > destructive... cue sound of many babies being ejected with bathwater. >=20 > I'm happy to be counted as a fan of "safe" "treat-as-withdraw". And > yes, that would preserve the correctness of the RIB, or at least avoid > incorrectness thereof. >=20 > In case (b) the safety of "treat-as-withdraw" means that there is an > error for which session-reset would continue to be the result -- > namely a "framing" error. For all other errors, case (b) avoids > session-reset -- hurrah ! Over time case (b) would be overtaken by > case (a), as more devices are upgraded to the new error handling. So, > the residual session-reset cases would dwindle away. >=20 > If "framing errors" are determined to be a significant risk, then I > guess that's an incentive for the deployment of case (a). >=20 > But, "unsafe" "treat-as-withdraw" may still be better than > session-reset, which we are agreed is simply ghastly. Inconsistencies > in the RIB may, as you say, be tolerable in the larger context of the > network, and treatable at an operational level -- getting away from > the tedious bits and stuff that I keep droning on about. >=20 > I note that the inconsistencies which may be introduced by "unsafe" > "treat-as-withdraw" are perhaps different to other inconsistencies: in > particular, the operator can no longer tell which routes are good and > which are bad. In "unsafe" "treat-as-withdraw", each broken UPDATE > may or may not have contained some NLRI which should have been > withdrawn, or which are now out of date, but the receiver does not > know which (if any) NLRI are in that (inconsistent) state ! >=20 > I note also that Appendix A of the draft waxes lyrical on the subject > of "Why not Discard UPDATE Messages". With "unsafe" > "treat-as-withdraw" the effect is to discard *part* of the UPDATE > message -- the part which may or may not (and you cannot tell which) > contain NLRI attribute(s) which have been obscured by earlier broken > attribute(s). >=20 > I do not know how to assess the possible impact of "unsafe" > "treat-as-withdraw"... but Appendix A appears to argue against ? >=20 > It is perfectly possible that I have my hands clenched firmly around > the wrong end of this stick. If the risk of "unsafe" > "treat-as-withdraw" is understood and it is determined that the cure > is (generally) not worse than the disease, then I can let go (yay !).=20 >=20 >> As such, I think we have to accept that the current protocol >> behaviour can be *very* damaging to network deployments and hence >> operators of real networks are prepared to tweak this balance >> somewhat. The requirements draft that I am continuing to edit tries >> to lay out a framework whereby one can limit the amount of time over >> which this inconsistency may affect the network through having means >> by which RIB consistency may be recovered. For example, these are: >>=20 >> - A more selective means by which ROUTE REFRESH can be achieved >> (e.g., one-time ORF, using rt-constrain to refresh a subset of >> routes, or building upon the Enhanced GR UPDATE-VERSION message) - >> which allows the individual speaker to recovery consistency of the >> RIB. >=20 > That appears to require the receiver to know which NLRI are no longer > consistent, which is not entirely possible with "unsafe" > "treat-as-withdraw". >=20 >> - Better ways to be able to do session reset (the observation being >> that the session-level error handling causes most problems due to >> forwarding outages during it) - which is answered by GR based on >> NOTIFICATION, and Enhanced GR. >=20 > This would not help with "unsafe" "treat-as-withdraw", since the > session-reset has been avoided in any case. >=20 > However, it would help in case (b). So, for "framing" errors a > session-reset is required if "unsafe" "treat-as-withdraw" is to be > avoided, but that session-reset would be mitigated along with all > other (residual) session-resets. >=20 > Mind you, changes in GR will require changes at both ends, and I > suspect rather larger changes than those required for case (a) "safe" > "treat-as-withdraw" -- but I guess those GR changes are more generally > a Good Thing. >=20 > .... >> My view is that we should *not* have a capability to indicate this >> behaviour. I would like a means by which I am not reliant on 3rd >> party actions (be it my peers in the dfz, or l3vpn deployments, or >> all device vendors) to begin to address a risk within my network >> deployments. >=20 > OK... to try to summarise succinctly, I think there are two levels at > which "safe" "treat-as-withdraw" may be implemented, as above: >=20 > a) where the sender sends NLRI attributes as required by > section 3 of the draft... >=20 > ...PLUS a capability... without which the receiver > cannot *know* that the sender is being helpful, and > has to assume otherwise. >=20 > This can tolerate any (non-NLRI attribute related) > aberrations. =20 >=20 > b) without any change at the sender end, >=20 > ...OR where the receiver does not *know* that the > sender is being helpful. >=20 > This can tolerate anything except "framing" errors (as > defined elsewhere). >=20 > Ruling out (a) limits the choice to: >=20 > i) case (b) "safe" "treat-as-withdraw" >=20 > ii) "unsafe" "treat-as-withdraw" >=20 > Since "unsafe" "treat-as-withdraw" gives me the screaming hab-dabs, my > view would be that starting with case (b) is a reasonable compromise, > as a first step towards case (a). =20 >=20 > There is obviously an incentive to deploy improved error handling. > Let us assume (for a moment) that improved error handling includes the > case (a) sender behaviour. Early adopters reap the benefit of case > (b) improved error handling immediately on the devices where new > software is deployed. And they reap the benefit of case (a) improved > error handling for their iBGP just as quickly as new software is > deployed across their network. For eBGP, availability of case (a) > improved error handling depends on the strength of the incentive -- > but good coverage requires only that the relatively small number of > Transit Providers adopt reasonably quickly. >=20 > However, given some way of determining the (likely ?) impact of > "unsafe" "treat-as-withdraw", then one could assess whether that is > better or worse than session-reset (under some circumstances ?) -- in > the (unlikely ?) event that some particularly dim BGP implementation > fails to correctly frame a set of attributes. I wish I knew where to > start to untangle this problem. >=20 > Chris >=20 From kbriley@cisco.com Fri Dec 7 07:46:28 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5421F87DC for ; Fri, 7 Dec 2012 07:46:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIv2U+JnEwpU for ; Fri, 7 Dec 2012 07:46:28 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4733E21F8781 for ; Fri, 7 Dec 2012 07:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=430; q=dns/txt; s=iport; t=1354895188; x=1356104788; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OO7W+C19AYv4BaZhNbK35taXcXZ7+u/u04XZdRB4/6w=; b=eVwqwI2LP1u7WoyeC2wYye90VQrESwfCOiQbADNGaK6O9FKcZD3hgj0C FdgEOnUNjknYdWb9jod70lcX1HrylIeO7Hb6Bn7gj1dxh1O0gi5H1+6eJ j6NGhhvxcNOvvJSNtPM0QkdeGc8uDq9m+zXY6l2XdS4aYaHsE/oZnfZrX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FAMUMwlCtJXG8/2dsb2JhbABEhW64SBZzgh8BAQQBAQE3NAsQAgEWFBQQJwslAgQOBQiICQzCGQSQIWEDpk2Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150557304" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 07 Dec 2012 15:46:27 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB7FkQgq027118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 15:46:26 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.162]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 09:46:26 -0600 From: "Ken Briley (kbriley)" To: John Scudder Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: AQHN1A4v0/JuGNkUpEmk+Qvhdi/zgpgNe4xg Date: Fri, 7 Dec 2012 15:46:26 +0000 Message-ID: <86F388E211EF594EAD75A00AEF6AA12001937BE2@xmb-aln-x07.cisco.com> References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.234.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Dec 2012 08:47:26 -0800 Cc: "idr@ietf.org" Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 16:24:15 -0000 Support On 12/6/12 2:39 PM, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-svshah-interdomain-sla-exchange-03 as a working group document. > >Please send any comments to the list by the Winter Solstice (December 21). > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Mon Dec 10 09:12:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB52521F850D for ; Mon, 10 Dec 2012 09:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FVeOp4LOpLo for ; Mon, 10 Dec 2012 09:12:10 -0800 (PST) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id AA96521F84E4 for ; Mon, 10 Dec 2012 09:12:10 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so6091209iag.39 for ; Mon, 10 Dec 2012 09:12:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=A/PuVYJhjaMDgkuLRm+Q408XQBpenCRo9/R16MKbWPQ=; b=TNs/txOBYErG0fv9sts+meGe9n/hivEcGjWg+2zy4g1TmwIA3XgjQEmAQlhUloIWdA Q7PEiEeb+d/wYitdLihgrrmpwjaRZBZLpw0sADiBBVdSX+NUdQQ9wqov7ohtLWdQWIgN YzLHDYDYC5grC9n+NHI5SBIWtEMo1kCUD95oGYWSBDPI6V7/2TIUWs7AGXuX3Q4Q1v87 ZKdKATJHh5cM6C5hGYujAc9ED7C0xtKH+E4zCdnN0aUKJxm4ZlBAbjOJ0uyFm557Hajk ayBshfODnrNO9KLl3rkyeomBgNvRF+qQd3luI3d5Dw9LN/YTP+jJsH4Rud7/o2MGZx8/ Uj7g== MIME-Version: 1.0 Received: by 10.50.209.65 with SMTP id mk1mr7209878igc.8.1355159530223; Mon, 10 Dec 2012 09:12:10 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 10 Dec 2012 09:12:09 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <007801cdd6f2$069cc720$13d65560$@highwayman.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <07e901cdd667$31c593e0$9550bba0$@highwayman.com> <007801cdd6f2$069cc720$13d65560$@highwayman.com> Date: Mon, 10 Dec 2012 12:12:09 -0500 Message-ID: From: Jeff Wheeler To: Chris Hall Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmi/+PAMBbWq+jx5S67aI1GudxclbOoHM4k9apNixKDuU+suQ+IssOZcPbpm95BKOgyXUlx Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:12:14 -0000 On Mon, Dec 10, 2012 at 11:18 AM, Chris Hall wrote: > Mind you, I suspect that operational remedies will also depend on the > accurate identification of all affected NLRI, which is the horse I > rode in on :-( Yes, but I think removing the need to quickly identify the affected NLRI, in order to get the network functioning again, is a good goal. Most operators do not have the necessary knowledge to figure these things out on their own. Maybe the software can't exactly figure out which NLRI are affected either, but it can still work around the problem if IGNORE is one of the available options. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From chris.hall@highwayman.com Mon Dec 10 09:21:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79921F8552 for ; Mon, 10 Dec 2012 09:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpdhPhis84CQ for ; Mon, 10 Dec 2012 09:21:14 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5F23221F855C for ; Mon, 10 Dec 2012 09:21:14 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id EB3BB384084; Mon, 10 Dec 2012 17:21:12 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id D128138406F; Mon, 10 Dec 2012 17:21:12 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 17:21:12 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Ti72V-0005gp-T9; Mon, 10 Dec 2012 17:21:11 +0000 From: "Chris Hall" To: "'Jeff Wheeler'" References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> In-Reply-To: Date: Mon, 10 Dec 2012 17:21:06 -0000 Organization: Highwayman Message-ID: <008501cdd6fa$c04f8f60$40eeae20$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwCjhW3CAl9IPxQCSWR95ZcrKnUQ Content-Language: en-gb X-MDF-HostID: 4 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:21:15 -0000 Jeff Wheeler wrote (on Mon 10-Dec-2012 at 16:13 +0000) > On Mon, Dec 10, 2012 at 8:26 AM, Chris Hall wrote: >> However, given some way of determining the (likely ?) impact of >> "unsafe" "treat-as-withdraw", then one could assess whether that is >> better or worse than session-reset (under some =A0circumstances ?) -- in > Why is the question not answerable by one of three options? > 1# ignore > 2# treat-as-withdraw > 3# session-reset > 1# IGNORE is hazardous but probably only to the prefixes in that > update (or withdraw) which means the scope of malfunction is > relatively small. .... I haven't considered IGNORE because the draft appears to vote against that pretty strongly. .... > 2# TREAT-AS-WITHDRAW is hazardous.... .... > The great risk is, how do you guess what the prefixes are, > if the framing is wrong? Absolutely. > In my view, here is one way that is rather thorough for > finding MP NLRIs: > > Beginning with or following the damaged Attribute (which one?), > scan for MP_REACH_NLRI: AttrFlags AttrType AttrLen AFI > SAFI NextHopLen NH 0x00 PfxLen Pfx (PfxLen Pfx){0,} ....snip further description of scanning attributes to find ....MP_REACH_NLRI and MP_UNREACH_NLRI. Well, that's an interesting idea :-) If the only important thing to extract from a broken set of attributes is the NLRI, then why not scan for it and assume that there is sufficient redundancy to effectively rule out false positives. Interesting :-) Chris From chris.hall@highwayman.com Mon Dec 10 09:52:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ADF21F8594 for ; Mon, 10 Dec 2012 09:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oPtWWp1d47V for ; Mon, 10 Dec 2012 09:52:33 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tch.inty.net [91.221.169.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1107E21F857B for ; Mon, 10 Dec 2012 09:52:32 -0800 (PST) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id B8738AC4390; Mon, 10 Dec 2012 17:52:25 +0000 (GMT) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 8D05EAC438F; Mon, 10 Dec 2012 17:52:25 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tch.inty.net (Postfix) with ESMTP; Mon, 10 Dec 2012 17:52:25 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Ti7Wi-0005gu-IW; Mon, 10 Dec 2012 17:52:24 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh>, <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> In-Reply-To: <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> Date: Mon, 10 Dec 2012 17:52:19 -0000 Organization: Highwayman Message-ID: <009001cdd6ff$1c982530$55c86f90$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwCjhW3CAl9IPxQBWty0zZcyouFA Content-Language: en-gb X-MDF-HostID: 17 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:52:35 -0000 Jakob Heitz wrote (on Mon 10-Dec-2012 at 16:31 +0000); > If, at the time a bgp speaker detects a malformation in a received > UPDATE, it has completely parsed at least one of: > . Withdrawn routes section > . NLRI Sure. The draft states that the 'Message Length', 'Withdrawn Routes Length' and 'Total Attributes Length' must be consistent -- ie correctly "framed". And anything in the (vanilla IPv4 Unicast) Withdrawn Routes and the NLRI sections must be internally consistent prefixes. So, if there is anything there, it can be parsed entirely separately from the attributes. > . MP_REACH > . MP_UNREACH For the receiver to have parsed one or both of these, the sender must have sent them before the first malformed attribute. If the sender is unchanged (which I recall you were keen on) how is it certain that either or both these attributes will precede the first broken one ? > then it assumes that there are no more of these following. So, the presence, say, of an MP_REACH_NLRI attribute is deemed to guarantee that no MP_UNREACH_NLRI will follow ? I can quite believe that, in practice, few BGP implementations (if any) send more than one of the above forms of NLRI in a single UPDATE message. But that is not a requirement of the RFC or the draft -- so the receiver is not (strictly speaking) entitled to assume it. What is the receiver supposed to do if it has not found any NLRI at the point that it hits a malformed attribute ? > A capability to say so adds nothing. > The router will behave exactly the same way. So, the receiver scans the attributes, and on the first malformed one it stops. Yes ? Or, perhaps it ploughs on to the end stepping past malformed attributes, and truncating the final attribute if it overruns the 'Total Attributes Length'. Yes ? If there are any NLRI visible (and valid), then they can all be "treated-as-withdraw". Yes ? Any NLRI that might be in the UPDATE, but are not visible because of the malformed attributes, are simply ignored. Yes ? OK... if that is the procedure, the capability is redundant. [I take issue with the procedure, but won't rehearse that, again, here.] However, the draft comes out strongly against simply ignoring the NLRI in a broken update. The draft also requires session-reset if the NLRI found in the UPDATE are not 100% valid. The procedure I understand you to be describing (and correct me if I have misunderstood) does not appear to be consistent with that. > Either way, human intervention is required to restore correct > routing. Sure. I think the issue is how to avoid/minimise incorrect routeing in the meantime. Also, I kinda suspect that the human bean will be greatly assisted if it is clear which NLRI have been affected (and which definitely have not). Chris From jakob.heitz@ericsson.com Mon Dec 10 10:09:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5246621F8596 for ; Mon, 10 Dec 2012 10:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoURIwsjzxE7 for ; Mon, 10 Dec 2012 10:09:08 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE3C21F853B for ; Mon, 10 Dec 2012 10:09:08 -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 qBAIJ7YF014564; Mon, 10 Dec 2012 12:19:12 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Dec 2012 13:08:58 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 13:08:58 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt Thread-Index: AQHNyBxqy9fEwUYlVUSnx1DosT0Aspf0/iwAgBcupYCAADNcgP//yMCqgAGK/gCAAJrggIAA4PUAgAAGNdyAAlGBgIAACv4AgADlMQD//9+bDYAAaouA//+t2dA= Date: Mon, 10 Dec 2012 18:08:56 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E10DD99@eusaamb109.ericsson.se> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh>, <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> In-Reply-To: <009001cdd6ff$1c982530$55c86f90$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:09:09 -0000 On Monday, December 10, 2012 9:52 AM, Chris Hall wrote: > Jakob Heitz wrote (on Mon 10-Dec-2012 at 16:31 +0000); >> If, at the time a bgp speaker detects a malformation in a received >> UPDATE, it has completely parsed at least one of: >> . Withdrawn routes section >> . NLRI >=20 > Sure. The draft states that the 'Message Length', 'Withdrawn Routes > Length' and 'Total Attributes Length' must be consistent -- ie > correctly "framed". And anything in the (vanilla IPv4 Unicast) > Withdrawn Routes and the NLRI sections must be internally consistent > prefixes. So, if there is anything there, it can be parsed entirely > separately from the attributes. >=20 >> . MP_REACH >> . MP_UNREACH >=20 > For the receiver to have parsed one or both of these, the sender must > have sent them before the first malformed attribute. >=20 > If the sender is unchanged (which I recall you were keen on) how is it > certain that either or both these attributes will precede the first > broken one ?=20 It is not certain. Once you have a malformed update, NOTHING is certain. We limit the damage and call for human intervention. >=20 >> then it assumes that there are no more of these following. >=20 > So, the presence, say, of an MP_REACH_NLRI attribute is deemed to > guarantee that no MP_UNREACH_NLRI will follow ? No. >=20 > I can quite believe that, in practice, few BGP implementations (if > any) send more than one of the above forms of NLRI in a single UPDATE > message.=20 >=20 > But that is not a requirement of the RFC or the draft -- so the > receiver is not (strictly speaking) entitled to assume it. It assumes the best it can to limit the damage. >=20 > What is the receiver supposed to do if it has not found any NLRI at > the point that it hits a malformed attribute ? Reset the session. >=20 >> A capability to say so adds nothing. >> The router will behave exactly the same way. >=20 > So, the receiver scans the attributes, and on the first malformed one > it stops. Yes ? Or, perhaps it ploughs on to the end stepping past > malformed attributes, and truncating the final attribute if it > overruns the 'Total Attributes Length'. Yes ? It doesn't stop. If the malformation is when reading NLRI in any of the places, it resets the session. >=20 > If there are any NLRI visible (and valid), then they can all be > "treated-as-withdraw". Yes ?=20 No. If an NLRI type attribute is completely parsed and the malformation is not in a subsequent one and the other conditions in the draft, then we treat as withdraw. >=20 > Any NLRI that might be in the UPDATE, but are not visible because of > the malformed attributes, are simply ignored. Yes ? yes. Again: Once you have a malformed update, NOTHING is certain. We limit the damage and call for human intervention. >=20 > OK... if that is the procedure, the capability is redundant. [I take > issue with the procedure, but won't rehearse that, again, here.] >=20 > However, the draft comes out strongly against simply ignoring the NLRI > in a broken update. The draft also requires session-reset if the NLRI > found in the UPDATE are not 100% valid. The procedure I understand > you to be describing (and correct me if I have misunderstood) does not > appear to be consistent with that. >=20 >> Either way, human intervention is required to restore correct >> routing. >=20 > Sure. I think the issue is how to avoid/minimise incorrect routeing > in the meantime. Also, I kinda suspect that the human bean will be > greatly assisted if it is clear which NLRI have been affected (and > which definitely have not).=20 The human bean will not rely on ANY routes or information from the broken session. >=20 > Chris --=20 Jakob Heitz. From jrmitche@puck.nether.net Mon Dec 10 10:40:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B521F85F5 for ; Mon, 10 Dec 2012 10:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op1Hn3GYrQVq for ; Mon, 10 Dec 2012 10:40:11 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id ED34921F85EA for ; Mon, 10 Dec 2012 10:40:10 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBAIeAP3030606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 13:40:10 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBAIeARi030604; Mon, 10 Dec 2012 13:40:10 -0500 Date: Mon, 10 Dec 2012 13:40:10 -0500 From: Jon Mitchell To: Jeff Wheeler Message-ID: <20121210184009.GA20478@puck.nether.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 10 Dec 2012 13:40:10 -0500 (EST) Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:40:11 -0000 First up front, this is the text with the current range and sizing suggested to IANA in the draft, which some people seem to have missed based on other threads: [Note to IANA, NOT for publication: The IANA should update the "16- bit Autonomous System Numbers" registry to reference this RFC (when published) for the existing private use reservation. Further, to maintain consistency from an operator standpoint, it is suggested that the end of the "32-bit Autonomous System Numbers" range be reserved for Private Use, and a size of 16777215 (value to replace TBD1 below) is suggested corresponding to the range of 4278190080 (value to replace TBD2 below) to 4294967294 (value to replace TBD3 below).] Other comments inline... Jon On Sun, Dec 09, 2012 at 04:07:23AM -0500, Jeff Wheeler wrote: > On Wed, Nov 28, 2012 at 4:26 PM, John Scudder wrote: > > We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > > I did some searching to try and find if there has been any discussion > on the recommended range of values that IANA should reserve. I didn't > find any, but admittedly, my searching skills may have simply been > poor. > > I mentioned this draft to two colleagues, and our discussion was > immediately that it would be nice if the range of newly reserved > values were easier for humans to read. If it simply extended from > 4,000,000,000 until 2**32-2 this would be a little nicer. > > If there has been discussion about this, could someone point me to it? The draft originally was more human/decimal boundary friendly before it was a WG doc. There has been some on list, some on meeting (Vancouver) and some out of meeting discussions I did before we moved from nice decimal boundary to nice bit or asplain friendly boundary). Here is one of the emails: http://www.ietf.org/mail-archive/web/idr/current/msg06468.html In the Vancouver meeting the draft was presented, and on range structure a show of hands poll was done, and from my memory (meeting minutes does not capture result unfortunately) it was overwhelmingly for bit/asplain friendly boundary (about 10:1). Others I talked to subsequently preferred this approach as well (I think Tony's comment earlier about hex friendly numbers can be grouped similarly). I'd also point out that the existing range is more bit friendly than human friendly so this is not a change in approach. Sizing has also been discussed a bit on and off list with more preferring we aren't having this debate again in 10 years due to some new novel use of BGP, and based on that feedback the current 24 bit text was implemented, at this point unless a wide number of folks have a specific change we can all agree to, I'm inclined to leave both as is. Although I agree the resource we are using is really large, it seems that reserving over 6% of the total space for private use is a step too far to me. Jon > > Operators care about what things look like in the CLI or the NMS. A > bunch of private ASN all beginning with 427xxxxxxx 428xxxxxxx > 429xxxxxxx is a little confusing, especially because 4278190080 would > be a private ASN but 4278190079 is not. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bvenkata@cisco.com Mon Dec 10 10:57:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66B21F8578 for ; Mon, 10 Dec 2012 10:57:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+sFdjlrk6+x for ; Mon, 10 Dec 2012 10:57:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CE91C21F856B for ; Mon, 10 Dec 2012 10:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=620; q=dns/txt; s=iport; t=1355165872; x=1356375472; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=o+3qAaUOjNkoPEwvryuXbcZHLS2QU5dKw4OUpPyCk2Q=; b=eXhDiNdMTkOQm6nEtoRXqqte2Qmlfw8QZOt8NRw0gg8PaCS7KP1YWDCb Jfjow9nhtRHe5EP6Dn0rZY3VCfHKhyEx18QTDk0jf+AnhicBoBkdluzjy 3lqvY3IwE05SNjkzeZFCiWtyFqr+FVbzpO9ULtubSpO7OKMwMTCX+Xa4b 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAFIwxlCtJXG+/2dsb2JhbABFhXC5DRZzgh4BAQEEAQEBNzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEgiICQy3ZgSMP4NiYQOmToJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151340562" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2012 18:57:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBAIvplO006890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Dec 2012 18:57:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 12:57:51 -0600 From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: AQHN1AL37B1zozEFE0WMcQPt0L6hJJgSaFpQ Date: Mon, 10 Dec 2012 18:57:51 +0000 Message-ID: References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> In-Reply-To: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.210.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:57:52 -0000 support -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = Scudder Sent: Thursday, December 06, 2012 2:39 PM To: idr@ietf. org Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-excha= nge-03 Folks, The authors have requested IDR adopt draft-svshah-interdomain-sla-exchange-= 03 as a working group document. Please send any comments to the list by the Winter Solstice (December 21). Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Mon Dec 10 11:54:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0621F861B for ; Mon, 10 Dec 2012 11:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clh25eABSYYU for ; Mon, 10 Dec 2012 11:54:40 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6FF721F860A for ; Mon, 10 Dec 2012 11:54:39 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so3035354obc.31 for ; Mon, 10 Dec 2012 11:54:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BqHAzORNNV4KqhVU/7+U1QnTGJzzFWe5JBJwGbcDDQw=; b=MJz/RNPMOdqjTlrV3do1KzluYkKHo18Oz2lGBInb360wyCYHvFbzk34gDQMcUowxxR DKEJ7xnPY4SrOGZ3NIEeDyfnhHPUh8DKRc66u0YgSamOLdIVYgYd5MikktP1YYDeFAN8 PsCnqS5tplo8ie+ki7imrTDJrdrKrh+Kb5542lPaPeF9gxtySJZuhZQI3gDBWWtYubcb tCTDwFvNQ7ZS9ICU5jvf3DLmQYmt7CpTamQbZ3HvNgOj2TvFCaduFbsjJb7g/UvP7t9B ArhjG6ZTBdmjAhG5QLCBD0dY6NYUolM8JkYyCZAzPfnqRdiHqqkT2GVDYRthXei2s7MT IN0Q== MIME-Version: 1.0 Received: by 10.182.36.8 with SMTP id m8mr2432385obj.93.1355169279422; Mon, 10 Dec 2012 11:54:39 -0800 (PST) Received: by 10.76.13.201 with HTTP; Mon, 10 Dec 2012 11:54:39 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <009001cdd6ff$1c982530$55c86f90$@highwayman.com> References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> Date: Mon, 10 Dec 2012 14:54:39 -0500 Message-ID: From: Jeff Wheeler To: Chris Hall Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlc+wdzk6Tjnz9qoptfUT+gZVqDaxusdBN3t9sBt8qc3dGPecWTGdMRTS1Vc1kW7V34PJ/H Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 19:54:40 -0000 On Mon, Dec 10, 2012 at 12:52 PM, Chris Hall wrote: >> . MP_REACH >> . MP_UNREACH > > If the sender is unchanged (which I recall you were keen on) how is it > certain that either or both these attributes will precede the first > broken one ? Actually RFC4271 Pg24 says: "The sender of an UPDATE message SHOULD order path attributes within the UPDATE message in ascending order of attribute type. The receiver of an UPDATE message MUST be prepared to handle path attributes within UPDATE messages that are out of order." The same text is also in RFC1771. So the MP_UN?REACH_NLRI Attribute type codes are 14 and 15 which is larger than most things like as_path, aggregator, and so on. I have not tried to collect any data on what implementations are actually doing. I could collect some by packet dumping my BGP sessions on an IXP in a few weeks when I have a chance to setup the necessary equipment to make the dump. It would be much more helpful if someone who runs a large IXP route-server could do this analysis, but if no such person volunteers and the data would be useful, I will do some work on this around the holiday or in early-January. On Mon, Dec 10, 2012 at 12:21 PM, Chris Hall wrote: > I haven't considered IGNORE because the draft appears to vote against > that pretty strongly. I think maybe some folks haven't imagined the failure modes of IGNORE vs WITHDRAW, and what is actually possible to do with WITHDRAW depending on the nature of the malformation. Really, the inconsistencies created by IGNORE are not too bad. You would hope Acme Router Co won't ship that as the default configuration of their products and that networks won't just turn that knob on a routine basis without understanding it. However, in a pinch, it will actually do only minimal damage to unrelated prefixes. Honestly, if Messages would not pack so much unrelated changes together, IGNORE would be fantastic. Simply separating nominal BGP withdraws from updates would make IGNORE quite safe. I think many people would argue that discouraging, or disallowing, a mixture of withdraws and updates in a single Message will be costly, but in fact it won't be. You wouldn't even need to discourage or forbid this though, vendors could choose to provide a knob to avoid mixing withdraws and updates together with no changes to the BGP specification. This would be ideal but it's hard to imagine customers actually requesting it as a feature, because vendors spent some years convincing customers that larger TCP MSS was going to improve converge performance, etc. Anyway, at least vendors have this choice if they wanted to do it. There are some consequences relating to the frequency of Message transmissions but I do not think anyone really obeys that text because it is stupid. > Well, that's an interesting idea :-) If the only important thing to > extract from a broken set of attributes is the NLRI, then why not scan > for it and assume that there is sufficient redundancy to effectively > rule out false positives. Interesting :-) I don't know what other way would be sensible. The other attribute information is not needed to effect a withdraw, only the NLRIs themselves. The troubling thing is that false positives could be created. For example, if you had a broken MP attribute toward the end of the Message (and the RFC effectively recommends that it be put toward the end, see above) then you can make a really big mistake and think that some MP NLRI are native NLRI. This means your Internet IPv4 RIB gets withdraws from prefixes that happened to be updated or withdrawn in a VRF within the same Message. That is why I mentioned that BGP is continually being extended to do new things that it is not good at. So you can see, the false positive problem is worth thinking about in-depth. I am sure that's why the draft wants to move the MP attribute to the beginning of the Message instead of the end. It is a smart idea if everyone would actually do it, but it isn't helpful if the peer doesn't. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From brian.peter.dickson@gmail.com Mon Dec 10 12:25:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5621F8646 for ; Mon, 10 Dec 2012 12:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip4OitfEse2U for ; Mon, 10 Dec 2012 12:25:19 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDBC221F8643 for ; Mon, 10 Dec 2012 12:25:18 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1347458eaa.31 for ; Mon, 10 Dec 2012 12:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Lbu2cgEyEfbUK/dt4+X73rL9EXP+xybcJydQg2XHOE=; b=vVZoRa78/xZnbEbI2qLuUxjleu4UjKqfCJCNzGuVAkizMHPI/HJ3Ge13Mucp90Bsbd cRpCjFQEjxUEEiMfQteKmqYyT5Pi3U27WS3W4/6NQ+wLd/OzTdfn972yzv37nAIpMmkQ 33oXXV4AGn5Nshb1twTsHmn+Y+E/MxFuo27+EEeloWk7cDL5cBPDpsI3Szpyyu2/sxDT K8yPCLHN1mAGvsmSTDh/nYRmfhfbXPDcq3fiQBRH7rXW58VaGT1BDsUlXLqgalXGPFSh 1rQrv9afASwwysgE1dL4GGYWIQltnKcfQWWmVYc9+61bIMk0yPgXb4FAjRVSbA9DGWZ3 WZ2w== MIME-Version: 1.0 Received: by 10.14.173.69 with SMTP id u45mr53236803eel.21.1355171116639; Mon, 10 Dec 2012 12:25:16 -0800 (PST) Received: by 10.223.173.199 with HTTP; Mon, 10 Dec 2012 12:25:16 -0800 (PST) In-Reply-To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> Date: Mon, 10 Dec 2012 15:25:16 -0500 Message-ID: From: Brian Dickson To: Jeff Wheeler Content-Type: multipart/alternative; boundary=047d7b6039f404672a04d0855d0d Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:25:20 -0000 --047d7b6039f404672a04d0855d0d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 10, 2012 at 2:54 PM, Jeff Wheeler wrote: > On Mon, Dec 10, 2012 at 12:52 PM, Chris Hall > wrote: > > > Well, that's an interesting idea :-) If the only important thing to > > extract from a broken set of attributes is the NLRI, then why not scan > > for it and assume that there is sufficient redundancy to effectively > > rule out false positives. Interesting :-) > > I don't know what other way would be sensible. The other attribute > information is not needed to effect a withdraw, only the NLRIs > themselves. > > It is unfortunate that UPDATE messages do not have any sort of identifier. It would be nice to be able to have the receiver send a NOTIFICATION that says, in effect, UPDATE #foo was garbled, please send JUST the afi/safi & NLRI so I know what to ignore. Maybe this could be handled via another UPDATE Attribute - the identification for an UPDATE itself? Then refer to this in the appropriate NOTIFICATION, type 3, new subtype, with parameter identifying the problem UPDATE? Then there is the question of the original UPDATE (generally on-the-fly data). If the error happens soon enough, maybe the sender still has the UPDATE in his/her outgoing TCP buffer? Otherwise, this would mean having to hold onto UPDATEs for possibly longer than desired. (LRU for buffer management is so very convenient when it is available, of course. Pack rat coding rules.) And of course, this pushes the "ACK" further up the stack, from TCP to the parent application (BGP). Again, maybe not that bad an idea, but definitely non-trivial. Thoughts? (I think this is more reliable, but again requires changes to both ends. The net benefit can be substantial, in terms of not having to "just guess" when the UPDATE is already known to be busted.) Brian --047d7b6039f404672a04d0855d0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 10, 2012 at 2:54 PM, Jeff Wh= eeler <jsw@inconcepts.biz> wrote:
On Mon, Dec 10, 2012 at 12:52 PM, Chris Hall <chris.hall@highwayman.com> wrote:

> Well, that's an interesting idea :-) =A0If the only important thin= g to
> extract from a broken set of attributes is the NLRI, then why not scan=
> for it and assume that there is sufficient redundancy to effectively > rule out false positives. =A0Interesting :-)

I don't know what other way would be sensible. =A0The other attri= bute
information is not needed to effect a withdraw, only the NLRIs
themselves.


It is unfortunate that = UPDATE messages do not have any sort of identifier.

It would be nice to be able to have the receiver send a NOTIFICATION that= says, in effect, UPDATE #foo was garbled, please send JUST the afi/safi &a= mp; NLRI so I know what to ignore.

Maybe this could be handled via another UPDATE Attribut= e - the identification for an UPDATE itself?
Then refer to this i= n the appropriate NOTIFICATION, type 3, new subtype, with parameter identif= ying the problem UPDATE?

Then there is the question of the original UPDATE (gene= rally on-the-fly data). If the error happens soon enough, maybe the sender = still has the UPDATE in his/her outgoing TCP buffer?

Otherwise, this would mean having to hold onto UPDATEs for possibly lo= nger than desired.
(LRU for buffer management is so very convenie= nt when it is available, of course. Pack rat coding rules.)

And of course, this pushes the "ACK" further up the stac= k, from TCP to the parent application (BGP). Again, maybe not that bad an i= dea, but definitely non-trivial.

Thoughts?

(I think this is more reliable, but again requires chan= ges to both ends. The net benefit can be substantial, in terms of not havin= g to "just guess" when the UPDATE is already known to be busted.)=

Brian
--047d7b6039f404672a04d0855d0d-- From jrmitche@puck.nether.net Mon Dec 10 13:13:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D161421F8523 for ; Mon, 10 Dec 2012 13:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxSHbcdmL+2n for ; Mon, 10 Dec 2012 13:13:00 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A7FCD21F85A7 for ; Mon, 10 Dec 2012 13:13:00 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBALCuoF024742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 16:12:56 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBALCuw6024741; Mon, 10 Dec 2012 16:12:56 -0500 Date: Mon, 10 Dec 2012 16:12:56 -0500 From: Jon Mitchell To: Jared Mauch Message-ID: <20121210211256.GB20478@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 10 Dec 2012 16:12:58 -0500 (EST) Cc: idr wg , Tony Li , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:13:01 -0000 Inline some specific comments.. in no way meaning to change your position on the draft. On Thu, Nov 29, 2012 at 12:50:44PM -0500, Jared Mauch wrote: > Robert, > > On Nov 29, 2012, at 12:36 PM, Robert Raszuk wrote: > > > I think this is yet one more case where the "Internet BGP" is trying > > to fight with "Private_Use of BGP". > > > > There are multiple applications BGP can serve and we have single > > protocol and single resource pool of ASes used by that protocol. Leave > > alone types of communities, attributes etc ... > > > > Internet folks will say "Do not trash our environment" > > As an operator, I feel this is a fair thing for me to say. :) > > This isn't about private use of bgp vs public use of bgp. It's about the engineering decisions that went into using BGP as the tool in the first place, and the implementation secondary. The added requirement of a larger space isn't unreasonable, but looking for a reservation (and the side-effects this will have on vendor code, deployability, usability, etc..) are not insignificant and to be outright dismissed. > > Picking on Cisco - The configuration directive is listed here: > > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f27.shtml > > remove-private-as > > Will there be remove-private-as [oh-yeah-and-that-extended-space-too] ? How will this be incrementally deployed and used? For some it will not need to be (they don't use the command today). For others, it will need to be updated ONLY IF they intend to allow transit for prefixes from private ASNs in the new range. This can easily be enforced by having egress filters recognize the new range, which I have yet to find a vendor that doesn't support AS_PATH filtering, although maybe someone will correct me with their own personal implementation! They worst case, which already happens today, is that a prefix originating from the person taking the risk (using a Private ASN or a new range Private ASN) does not have full Internet connectivity due to downstream filtering. I think something the folks for and against this draft can all agree on is our lack of sorrow for them. I don't expect to need multiple variants of remove-private-as, one variant that recognizes both ranges is probably enough for the operator community (although I can't speak for all of them). BGP features are being added everyday, I think this update is fairly minor as others have pointed out. > > If the goal is something like "I have 5000 racks of gear, want a top-of-rack-switch with a /64 on each of them", this is a solvable problem in current running code today. You use rfc2270 and allow-as-in with the existing space outlined in rfc1930. It's a bit more complex then this actually in practice, but generally agreed that re-using private ASNs at some level with that vendor specific knob and other vendor specific knobs makes this possible as some of my colleagues have shared. > > If the goal is to use the ASN as that identifier, eg: encoding the POP/ROW/RACK in the ASN, then I will be the first to say this is a misapplication of technology. That should either be encoded in your addressing plan or your network documentation. BGP can't be the place for each need to find the solution fulfilled. (note lowercase "need"). I think people have taken a leap to think that a BGP design used internally to some MSFT DC's is the primary motivation of this draft rather than unique number of sites (or organization/site) in a large organization. I don't have any forseeable plans to encode row and rack location information into AS numbers and guarentee uniqueness for such when this draft passes (although I'm not against the possibility or any other use of private ASNs people may have WITHIN THEIR OWN NETWORK). I think if you use BGP as a routing protocol many organizations are creating an eBGP boundary per site or sub-organization for various reasons related to implementing policy controls and creating segmented routing domains, where using a single ASN at all sites does not provide the necessary connectivity requirements (i.e. I need more than default) depending on how these sites are interconnected w/o using a number of complex routing tricks, many of which would require non-standarized implementation specific features that vary. I'd like to have a simpler path forward in the long run... Jon > > > > Applications and services folks will say "We just find BGP useful to > > our application, why not use it - we have nothing in common with big > > I" > > > > On that basis I see no harm in allowing some bigger AS space for personal use. > > > > In fact I just looked at various RIR policies (some of them written by > > Geoff ;) which say that given LIR can get only single AS number > > allocation - even for experiments. Moreover RIRs get 1K AS pools from > > IANA and there are clear rules where the subsequent pool can be > > requested. > > These policies are community driven, and could be changed. I'm not saying they are right or wrong, but if you have collisions in numbering, you should get unique space to properly work around it vs using a hack. > > > Yes Jared is right that RFC2270 or similar techniques can be used. In > > fact I spoke with John offline today about one of such cases where > > private as just get's stripped immediately. But those ideas are just > > moving the issue and not really solving it - making the internal > > network troubleshooting more complex. > > I'm not convinced that the AS(4)_PATH is the right place to encode this information. Numerous elements go into a network and site documentation. If your premise rises or falls based on this individual element, perhaps it was poorly conceived in the first place? > > - Jared > > > > > Regards, > > R. > > > >> On Thu, Nov 29, 2012 at 5:53 PM, Jared Mauch wrote: > >> > >> Greetings, > >> > >> Jon pointed me to this draft earlier today so please be kind (for the first 5 minutes after this is delivered in your mailbox.). > >> > >> After reading the list history back a few months or so on this topic, I must express the same reservation that Randy and Geoff have raised. > >> > >> I do not feel this is a problem space that needs to be addressed. Vendors easily disable loop-detection in current running code, and rfc2270 seems to clearly apply in the problem space this is attempting to address. > >> > >> The issue of ASN collisions were raised, and I feel can be dismissed easily by one party engaging with their local RIR for a nominal "cost of running BGP" threshold. The recurring annual cost is likely a budgetary "rounding error" and is not a barrier to entry IMHO. > >> > >> I have other concerns should this move forward that would impact operations. I will comment on them in private should folks desire. > >> > >> I do not feel this draft can be supported. > >> > >> - Jared > >> > >> > >> On Nov 29, 2012, at 11:40 AM, Tony Li wrote: > >> > >>> > >>> Support. > >>> > >>> Editorial nit: I would find it MUCH more helpful if the constants were also expressed in hex. > >>> > >>> Tony > >>> > >>> > >>> On Nov 28, 2012, at 1:26 PM, John Scudder wrote: > >>> > >>>> Folks, > >>>> > >>>> We have received a request for a working group last call on draft-ietf-idr-as-private-reservation-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > >>>> > >>>> Please send comments to the list by December 14. [*] > >>>> > >>>> Thanks, > >>>> > >>>> --John > >>>> > >>>> [*] Unless the world ends on December 12, in which case send them by December 12. > >>>> _______________________________________________ > >>>> Idr mailing list > >>>> Idr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/idr > >>> > >>> _______________________________________________ > >>> Idr mailing list > >>> Idr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/idr > >> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Mon Dec 10 13:18:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657AD21F8686 for ; Mon, 10 Dec 2012 13:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVRIxRlD4ibs for ; Mon, 10 Dec 2012 13:18:33 -0800 (PST) Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5434F21F8681 for ; Mon, 10 Dec 2012 13:18:33 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id y25so4884288iay.19 for ; Mon, 10 Dec 2012 13:18:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=W3VeSvYqHdR+YYzafY+2zdX3+hP7tcKAgJ2OpCggzKs=; b=TtAJKIlMTdNrt2vWPqfiLHHIhxtU2HgJExn1hbQm1LGFRgGHNn3WnIkLjqAXBLNrey QqOubFIE9EcOlXX2MLJQI97zx6Lr5B2Z7i21EvhpyzK9ejt6TZSdjzp1036vujZ53jYh SrtuwGr3vfTBNodNUPws2sr0P1rItJLzmq6Z6N8jCpiA/vlSyo2KOxwsaw7/JGaYWCy2 m4jL7YBmpF1LVadvvcRU4WoRdq4YmBanfD6H/3EFDNc/uIpkAdXI2KgSm9taa+Q5Orus +NS6i13OzMnLq/dVjKZpA4Su9hWvma4h+3QZnp4eQL/1YDvCxWx9DwZVGvZVp7Q65JYd jqRA== MIME-Version: 1.0 Received: by 10.50.36.198 with SMTP id s6mr8037974igj.23.1355174312831; Mon, 10 Dec 2012 13:18:32 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 10 Dec 2012 13:18:32 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20121210184009.GA20478@puck.nether.net> References: <20121210184009.GA20478@puck.nether.net> Date: Mon, 10 Dec 2012 16:18:32 -0500 Message-ID: From: Jeff Wheeler To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmM0rpVI3MINvuK/noTq4V8tSMN60UYkLRBIGunp004iMH9XTdWVWZfrz1lcUgpDngbm171 Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:18:34 -0000 On Mon, Dec 10, 2012 at 1:40 PM, Jon Mitchell wrote: > The draft originally was more human/decimal boundary friendly before it > was a WG doc. There has been some on list, some on meeting (Vancouver) > and some out of meeting discussions I did before we moved from nice > decimal boundary to nice bit or asplain friendly boundary). Here is one > of the emails: I read the mail thread you linked, but it did not give me any understanding why folks prefer a bit-boundary instead of a human-readable boundary. I will ask some more operator colleagues to give their opinions. I am surprised anyone would think bit-boundary is the smartest choice if one of the alternatives looks nicer in the CLI/NMS. I understand what you mean if the CLI/NMS allows you to customize and create multiple prefixes like PRIVATEn and this might be nice for some applications. However, VPLS has clearly figured this out with label blocks. The applications for making numerous PRIVATEn prefixes within a network are likely to have conceptually similar demands, in so far as the management of number ranges is concerned. Even if they aren't, though, it seems clear that router software developers have mastery of subtraction and addition, along with the bit-wise operators. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From brian.peter.dickson@gmail.com Mon Dec 10 13:58:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7AC21F8566 for ; Mon, 10 Dec 2012 13:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEI4lw0+ruSz for ; Mon, 10 Dec 2012 13:58:26 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD7F521F8496 for ; Mon, 10 Dec 2012 13:58:17 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1381520eaa.31 for ; Mon, 10 Dec 2012 13:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3c9UJvRP3+MWd+hBsZJ+pjDGiKbG5M2SCWE4KBUbVCc=; b=UchSOtAMnSvwOyW1x+pEnz1He8ErUVGmX/JllN5veRPg81KanKr1Y6qvdGj5QZVmcr ZheVddDH3h+/zD2yN2o0lRideELoRe+pHVbxNbe89mM0JMVpV13Wwp/Cf49XgxGAGRtA bYgvZXD6/5AT9N+XSIYjM/CmR7RhbPgfL9mYfeWrK2aB5rP1Sbc0cJKTCCv8POqmypVU 6tiRd7U2+qHwJ9h5ss+eSZA+KbNZtQdO+Vk3v9Tk19oBTxCwqfU4CMaLApthSiEnw8UJ rfAQrY0Y0III8FLzvWysWOI2qSKPs5ZiK3m7/qK66a131Fc87nUI7lnUdgdX/TkdKPOO Ui2g== MIME-Version: 1.0 Received: by 10.14.225.194 with SMTP id z42mr54004721eep.22.1355176696856; Mon, 10 Dec 2012 13:58:16 -0800 (PST) Received: by 10.223.173.199 with HTTP; Mon, 10 Dec 2012 13:58:16 -0800 (PST) In-Reply-To: References: <20121210184009.GA20478@puck.nether.net> Date: Mon, 10 Dec 2012 16:58:16 -0500 Message-ID: From: Brian Dickson To: Jeff Wheeler Content-Type: multipart/alternative; boundary=047d7b66f24b9fc24f04d086a9ec Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:58:27 -0000 --047d7b66f24b9fc24f04d086a9ec Content-Type: text/plain; charset=ISO-8859-1 The as-dot/bit-boundary style typically uses a lot less space, and there are several "nice" candidates: 64512.0 = 4227858432 (same start, shifted 16 bits left) 64850.0 = 4250009600 (the 4250000000 and up range is more human-friendly without eating too much) 65000.0 = 4259840000 (has a bunch of zeros at the end, more asplain-obvious?) 65280.0 = 4278190080 (currently in the draft) Of course, it may also be reasonable to set aside a third range: 4000000000 through TBD2 as Reserved (not part of new range, nor part of Public range, just "off limits", as a kind of DMZ). That range can be freed up if need be later, e.g. once we have colonized the galaxy. :-) Brian On Mon, Dec 10, 2012 at 4:18 PM, Jeff Wheeler wrote: > On Mon, Dec 10, 2012 at 1:40 PM, Jon Mitchell > wrote: > > The draft originally was more human/decimal boundary friendly before it > > was a WG doc. There has been some on list, some on meeting (Vancouver) > > and some out of meeting discussions I did before we moved from nice > > decimal boundary to nice bit or asplain friendly boundary). Here is one > > of the emails: > > I read the mail thread you linked, but it did not give me any > understanding why folks prefer a bit-boundary instead of a > human-readable boundary. I will ask some more operator colleagues to > give their opinions. I am surprised anyone would think bit-boundary > is the smartest choice if one of the alternatives looks nicer in the > CLI/NMS. > > I understand what you mean if the CLI/NMS allows you to customize and > create multiple prefixes like PRIVATEn and this might be nice for some > applications. However, VPLS has clearly figured this out with label > blocks. The applications for making numerous PRIVATEn prefixes within > a network are likely to have conceptually similar demands, in so far > as the management of number ranges is concerned. Even if they aren't, > though, it seems clear that router software developers have mastery of > subtraction and addition, along with the bit-wise operators. > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b66f24b9fc24f04d086a9ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The as-dot/bit-boundary style typically uses a lot less space, and there ar= e several "nice" candidates:

64512.0 =3D= =A04227858432 (same start, shifted 16 bits left)
64850.0 = =3D=A04250009600 (the 4250000000 and up range is more human-friendly withou= t eating too much)
65000.0 =3D=A04259840000 (has a bunch of zeros at the end, more asplai= n-obvious?)
65280.0 =3D=A04278190080 (currently in the draft)

Of course, it may also be reasonable to set aside a t= hird range:
4000000000 through TBD2 as Reserved (not part of new range, nor part o= f Public range, just "off limits", as a kind of DMZ).
<= br>
That range can be freed up if need be later, e.g. once we hav= e colonized the galaxy. :-)

Brian

On Mon, = Dec 10, 2012 at 4:18 PM, Jeff Wheeler <jsw@inconcepts.biz> = wrote:
On Mon, Dec 10, 2012 at 1:= 40 PM, Jon Mitchell <jrmitch= e@puck.nether.net> wrote:
> The draft originally was more human/decimal boundary friendly before i= t
> was a WG doc. =A0There has been some on list, some on meeting (Vancouv= er)
> and some out of meeting discussions I did before we moved from nice > decimal boundary to nice bit or asplain friendly boundary). =A0Here is= one
> of the emails:

I read the mail thread you linked, but it did not give me any
understanding why folks prefer a bit-boundary instead of a
human-readable boundary. =A0I will ask some more operator colleagues to
give their opinions. =A0I am surprised anyone would think bit-boundary
is the smartest choice if one of the alternatives looks nicer in the
CLI/NMS.

I understand what you mean if the CLI/NMS allows you to customize and
create multiple prefixes like PRIVATEn and this might be nice for some
applications. =A0However, VPLS has clearly figured this out with label
blocks. =A0The applications for making numerous PRIVATEn prefixes within a network are likely to have conceptually similar demands, in so far
as the management of number ranges is concerned. =A0Even if they aren't= ,
though, it seems clear that router software developers have mastery of
subtraction and addition, along with the bit-wise operators.
--
Jeff S Wheeler <jsw@inconcepts.biz= >
Sr Network Operator =A0/ =A0Innovative Network Concepts
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b66f24b9fc24f04d086a9ec-- From internet-drafts@ietf.org Mon Dec 10 14:14:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4839A21F8616; Mon, 10 Dec 2012 14:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8JweXupkW19; Mon, 10 Dec 2012 14:14:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0F21F85B3; Mon, 10 Dec 2012 14:14:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121210221446.29921.82835.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 14:14:46 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-dpa-etal-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:14:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Deprecation of BGP Path Attributes DPA, ADVERTISER and R= CID_PATH / CLUSTER_ID Author(s) : John Scudder Filename : draft-ietf-idr-deprecate-dpa-etal-00.txt Pages : 3 Date : 2012-12-10 Abstract: This document requests IANA to deprecate the BGP path attributes DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet Draft and a Historic RFC, respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-deprecate-dpa-etal-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jrmitche@puck.nether.net Mon Dec 10 14:50:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4F721F86C3 for ; Mon, 10 Dec 2012 14:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjlObTlu-lQ9 for ; Mon, 10 Dec 2012 14:50:47 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id BF46421F86C1 for ; Mon, 10 Dec 2012 14:50:23 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBAMoKaI005653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 17:50:20 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBAMoKrj005652; Mon, 10 Dec 2012 17:50:20 -0500 Date: Mon, 10 Dec 2012 17:50:20 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121210225019.GA24937@puck.nether.net> References: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <50B986F2.5060405@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B986F2.5060405@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 10 Dec 2012 17:50:20 -0500 (EST) Cc: idr wg , Tony Li Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:50:50 -0000 David / Randy - thoughts inline... On Fri, Nov 30, 2012 at 10:26:26PM -0600, David Farmer wrote: > On 11/30/12 19:49 , Randy Bush wrote: > >>the data center community has, for better or worse, decided that BGP > >>is their protocol of choice. Frankly, I find it mildly nauseating, > >>but it's very clear that they are going to use BGP regardless of what > >>you and I say. > > > >agreed > > > >but this is not what is in the ID or was not the discussion (that i > >remember, with large caveats on my memory). it has been about hiding > >isp customers behind private asns, which we know how to do already. > > > >while nauseating, this is a more compelling argument. and i note that > >it does not have the merger problem the isp model has. or, more > >precisely, when it has the merger problem, it falls only on the fools > >who made it. > > I guess that's why we've been arguing past each other, for me its > always been about enterprise and data centers use of BGP, not ISP > customer access use of BGP. > > I personally know of 2 or 3 large scale enterprises that are on the > verge of having issues. They are currently just under a 1000 sites > and would prefer to keep using unique (within their domain) ASNs for > each site to avoiding the problems with loop detection hacks. The > burden for the hacks doesn't fall on the backbone SPs they fall on > the customer edge sites. > > Those hacks can be easily managed in a single backbone SP > environment. However, when you start using multiple backbone SPs > either for more cost effective reach or for redundancy, the topology > can get complicated quickly. There is a reason BGP has loop > detection and in highly complicated environments those hacks can > burn even the most experienced network engineers. And in only > moderately complicated environments, the junior engineers that many > enterprises have are frequently in over their head with those hacks. > > Large scale enterprise BGP-VPNs, Data Center BGP uses, and other > newer applications of BGP that are not generally visible to the > big-I topology are what is driving this, not ISP customer access > BGP. > > >update the draft to make these arguments, i will support it, and i > >suspect other dissidents will as well. Actually Randy, to be fair, I think a number of dissendents will not over a philosophical objection to private use space, and I'm quite shocked at this development since previously I asked you specifically if there was anything in the wording that could be changed that would allow you to support it and you declined. Trying to do a neutral re-reading of the draft (I think you naturally read it from an ISP providing Internet access point of view), I see the last sentence in the introduction which was meant to be a broad statement on why BGP has proliferated to so many organizations (which includes provider redundancy) could be confused to be meaning that "provider assigned asn" is the target of this draft. In a general sense, I'd rather expose any issues with private use asns and then allow operators to make their own problems in so much as they don't affect others unnecessarily which you seem to agree with. I'd be willing to delete that line if you think appropriate? > > In the first paragraph of the introduction there is already a > reference to BGP/MPLS IP VPNs [RFC4364], do you want Data Centers > explicitly added with reference to > draft-lapukhov-bgp-routing-large-dc too? Are there other references Brian - As much as marketing is important, I don't think including a reference a draft that we haven't yet found a home for that documents Microsoft use of BGP within some DC's is a good idea for something that applies generically to multiple sites within a single organization. I think many can agree they have seen DC's be in a seperate AS (public/private/confed) than the core networks which attach them, I have seen this as a normal configuration in multiple networks over the last 12 years personally.... I unfortunatley tried to capture this as large content providers and may have more generically said DC operators (either within or between DC's where they determine the connectivity), but I don't think one sentence in the introduction is worth re-opening the draft text during WGLC. I'd be open to considering this past WGLC as a minor change however, along with striking the last sentence of the introduction if you both think this is appropriate. I'd like to re-iterate overall that the purpose the draft is primarly to make an IANA reservation, not to dictate or recommend to others what to do with it, except in the operational considerations lay out the changes to consider to continue to play nice with the broader Internet. Jon From jrmitche@puck.nether.net Mon Dec 10 14:57:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4326121F863C for ; Mon, 10 Dec 2012 14:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNIWEBnSUv+0 for ; Mon, 10 Dec 2012 14:57:03 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 51B8B21F8507 for ; Mon, 10 Dec 2012 14:57:03 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBAMuv9k006085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 17:56:58 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBAMuvsQ006084; Mon, 10 Dec 2012 17:56:57 -0500 Date: Mon, 10 Dec 2012 17:56:57 -0500 From: Jon Mitchell To: Brian Dickson Message-ID: <20121210225657.GB24937@puck.nether.net> References: <20121210184009.GA20478@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 10 Dec 2012 17:56:58 -0500 (EST) Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:57:04 -0000 Jeff / Brian - yes, there are a million combinations, I've put one in the draft that seems to be relatively machine and human friendly (but only when looking at it in asdot notation). I'm not willing to consider 8 other options with the draft in WGLC unless there appears to be a widespread concensus in the WG to change to one specific other option. I think overall, we can say things like 4,000,000,000 are not easy to make human friendly in the CLI when you remove the commas, so I'm not as convinced that these are less opertionally error prone or human consumable. Seems more likely everyone re-uses that number if we decided on it (not that uniqueness is an attribute that is useful in private ASNs) and misconfigures it half the time to be 400M. Jon On Mon, Dec 10, 2012 at 04:58:16PM -0500, Brian Dickson wrote: > The as-dot/bit-boundary style typically uses a lot less space, and there > are several "nice" candidates: > > 64512.0 = 4227858432 (same start, shifted 16 bits left) > 64850.0 = 4250009600 (the 4250000000 and up range is more human-friendly > without eating too much) > 65000.0 = 4259840000 (has a bunch of zeros at the end, more > asplain-obvious?) > 65280.0 = 4278190080 (currently in the draft) > > Of course, it may also be reasonable to set aside a third range: > 4000000000 through TBD2 as Reserved (not part of new range, nor part of > Public range, just "off limits", as a kind of DMZ). > > That range can be freed up if need be later, e.g. once we have colonized > the galaxy. :-) > > Brian > > On Mon, Dec 10, 2012 at 4:18 PM, Jeff Wheeler wrote: > > > On Mon, Dec 10, 2012 at 1:40 PM, Jon Mitchell > > wrote: > > > The draft originally was more human/decimal boundary friendly before it > > > was a WG doc. There has been some on list, some on meeting (Vancouver) > > > and some out of meeting discussions I did before we moved from nice > > > decimal boundary to nice bit or asplain friendly boundary). Here is one > > > of the emails: > > > > I read the mail thread you linked, but it did not give me any > > understanding why folks prefer a bit-boundary instead of a > > human-readable boundary. I will ask some more operator colleagues to > > give their opinions. I am surprised anyone would think bit-boundary > > is the smartest choice if one of the alternatives looks nicer in the > > CLI/NMS. > > > > I understand what you mean if the CLI/NMS allows you to customize and > > create multiple prefixes like PRIVATEn and this might be nice for some > > applications. However, VPLS has clearly figured this out with label > > blocks. The applications for making numerous PRIVATEn prefixes within > > a network are likely to have conceptually similar demands, in so far > > as the management of number ranges is concerned. Even if they aren't, > > though, it seems clear that router software developers have mastery of > > subtraction and addition, along with the bit-wise operators. > > -- > > Jeff S Wheeler > > Sr Network Operator / Innovative Network Concepts > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > From jrmitche@puck.nether.net Mon Dec 10 14:59:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8662421F8507 for ; Mon, 10 Dec 2012 14:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXYS3VoYi-Fb for ; Mon, 10 Dec 2012 14:59:05 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0D21F862E for ; Mon, 10 Dec 2012 14:59:05 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBAMwxkf006242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 17:58:59 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBAMwwTk006241; Mon, 10 Dec 2012 17:58:58 -0500 Date: Mon, 10 Dec 2012 17:58:58 -0500 From: Jon Mitchell To: "Pradosh Mohapatra (pmohapat)" Message-ID: <20121210225858.GC24937@puck.nether.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 10 Dec 2012 17:58:59 -0500 (EST) Cc: "idr@ietf.org" , Jay Borkenhagen , Tony Tauber , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:59:06 -0000 Pradosh / Randy / et al - although Robert has pointed out already that in the end someone who knows that these routes need to go to the Internet needs to peer with said Enterprise in your example, and this ISP is ultimately responsible for allowing the routes to reach the Internet (and can consider the operational considerations that is already fairly clear in my opinion), I think this is a moot point. However, thinking about your inter-as use case if combined with Internet access gateway type functionality or other random topologies, I can certainly create some that allow an ISP that allows BYOA (bring your own asn?) to accept routes from an ASN that is private (old range) and provide transit to a new range ASN behind that old range. I actually think this problem is not a large operational concern as it already is an artificat of mis-configurations and mis-understandings of said vendor implementations in the existing range. Those using private ASNs and leaking them to the Internet do not get a lot of tear drops when their prefixes are dropped based on ingress filters or as-path loop detection by other networks. I think a large part of the debate on this draft has been due to the implication that these would be used by organizations that allocate ASNs to others outside their organization, such as ISPs, versus internal use within very large organizations. After WGLC, if the draft proceeds, I may propose small changes to the operational considerations section as there does seem to be sufficient angst, especially from the ISP community on behavior changes (to use private ASNs in more networks or applications that otherwise wouldn't have I guess) that may be induced by operators based on there being an expanded range. Are there others who think that the following modification(s) would be useful (whether or not you support the draft)? (from the last sentence of 1st paragraph and total of second paragraph is the new proposed text, ignore sp or grammer errors) --- If private use ASNs are used and prefixes are originated from these private use ASNs which are destined to the Internet, private use ASNs must be removed from the AS_PATH before being advertised to the global Internet. Prior to making use of the second, numerically higher, range of these ASNs network operators should be confident any implementation specific features or filters that recognize private use ASNs have been updated to recognize both ranges correctly so that no unintended announcement of private use ASNs to the Internet occurs. Specifically, any implementation specific features should treat both ranges similarly and there is no need to differentiate between the existing and new ranges. Networks that provide Internet connectvity for prefixes originated in other ASNs should be cautious about allocating the new range or ever guarenteeing transport of prefixes originating from private ASNs especially if alternative approaches can suffice for their needs, for instance as described in RFC2270. Certain topologies, whether using the existing or new range, can cause vendor specific implementations of features that recognize the private ASN range to not remove all instances of the Private ASNs from the AS_PATH, resulting in a prefix that may not be reachable from all of the Internet due to containing a Private ASN. Private ASNs also introduce additional complexity especially during network mergers and consolidations and careful consideration should be given to their use versus a globally unique ASN from a Regional Internet Registries (RIR). --- Let me know your thoughts on this... Thanks, Jon On Wed, Dec 05, 2012 at 09:45:14PM +0000, Pradosh Mohapatra (pmohapat) wrote: > >I think both Tony and Jay forgot that routing and reachability is not > >about originator AS .. it is about prefixes they advertise. > > > >If peering ISP AS chooses to peer with private as or remove private as > >from AS-PATH or for completeness substitute with their own it is all > >ok. He takes responsibility to route data to such customer(s). > > > >Any subsequent removal of private as in the path also results in the > >same responsibility of the provider who permits private AS for > >peering. > > > >I am not sure why there is concern with it on the list. > > > Not sure you understood the issue Jay was pointing to - but it is a > problem worth talking about if we are serious about advancing this draft. > > Say an enterprise starts using ASN 4278190081. It already has a bunch of > ASNs from the 16-bit private AS range and relies on the correct behavior > of "remove-private-as" from the ISP. The ISP routers are not upgraded to > understand 4278190081 is a private ASN. We get into all sorts of > interesting scenarios based on the connectivity graph (changes in traffic > pattern come to mind as I know folks compare AS_PATH length taking into > account remove-private-as). > > The 'operational considerations' section does talk about this - but I > would like it described in more detail. > > - Pradosh > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Mon Dec 10 15:16:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3E921F86C3 for ; Mon, 10 Dec 2012 15:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajBMjdDN4N-4 for ; Mon, 10 Dec 2012 15:16:05 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6821F86B9 for ; Mon, 10 Dec 2012 15:16:05 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so9795020iea.24 for ; Mon, 10 Dec 2012 15:16:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1OotLk1t/nSX/ZUZQ8611XPoq3jvxyDq68ANNO8cgGU=; b=YXCjJ8Q7wZNCubIo/nuGKf1PJiLfPinU1j22kcuWpb3vndSt+KE3oDHWAvxLZCrYWk 7oi/TgAj6LyylkYEM1UtQ7lhprwqEWjNBe1M3PQRaN2eZ21KBKCRgJIbFmLVrwYJERal ih1hj/yJTAZouZYngSC1c6zX/Ajgfq0NXc6x9uhddffOMmJiTc7nsaCoYMt6GSHPq/yv 4eYCWehFObeD9K4Z2+Vdm/3BI4JHLfQsXgAVC2Dhyp9AWNbrT17t53a9pVZ/WOnZqQ8t kKGO3pmETlBXBEFp0osjim5s441fkQj3qLvdpNFwu05nXqqcofqOoE++Y/LPRMJw4gcC byVg== MIME-Version: 1.0 Received: by 10.50.157.130 with SMTP id wm2mr11072865igb.0.1355181364651; Mon, 10 Dec 2012 15:16:04 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 10 Dec 2012 15:16:04 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> Date: Mon, 10 Dec 2012 18:16:04 -0500 Message-ID: From: Jeff Wheeler To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkpkeA3YPt9ckwVKI3Hmh1rcxYA7LyAaa4TrTGPeLWww1YbLjd+9WBRPYiN0XbDWM9nTMbo Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 23:16:06 -0000 On Mon, Dec 10, 2012 at 3:25 PM, Brian Dickson wrote: > It is unfortunate that UPDATE messages do not have any sort of identifier. My knee-jerk is that I am not very excited about your idea, but it is useful to point out that LDP has message identifiers. LDP needs to keep more state around about pending LSP setup to support ordered mode, merge, and downstream on demand, but there are also useful diagnostic messages that will include the original message ID when various fault conditions are observed. > It would be nice to be able to have the receiver send a NOTIFICATION that > says, in effect, UPDATE #foo was garbled, please send JUST the afi/safi & > NLRI so I know what to ignore. If this happens the NOTIFICATION should be responded to not with an ordinary UPDATE but with one that is either a new Message Type or else an UPDATE that has a very unambigious field which is sure not to be confused or corrupted, signaling that this is a re-try of a previous UPDATE and, if it can't be parsed, don't make that same NOTIFICATION again. But if your ultimate attempt is to ask the peer for the information you need to effect a WITHDRAW, then you could just invent a way to demand the peer send you that WITHDRAW. The cool thing about that is, then the peer can actually have knowledge of what route is broken. It could save that information to support investigation of the problem on both sides of what may be an eBGP session. At minimum, it could mark the RIB entry so it knows that route is not advertised to you, and this could be available on the CLI. Now, I am not thinking that anyone will jump to implement your idea, but my knee-jerk was "oh no!" and really, your idea has real serious technical advantages. Of course you observe that it has some disadvantages too (more state on sender side.) If one were inventing "BGP 5" surely this ability would be sensible. Maybe it is even a sensible Capability for BGP today. After all, the vendor can always allow the operator to deactivate the Capability if they wish. > Maybe this could be handled via another UPDATE Attribute - the > identification for an UPDATE itself? > Then refer to this in the appropriate NOTIFICATION, type 3, new subtype, > with parameter identifying the problem UPDATE? As long as the sender doesn't respond with another UPDATE that gets confused and results in another NOTIFICATION in a loop. But that is fixable like I describe above. > Then there is the question of the original UPDATE (generally on-the-fly > data). If the error happens soon enough, maybe the sender still has the > UPDATE in his/her outgoing TCP buffer? The sender won't have the UPDATE in his TCP buffer because it is basically guaranteed the receiver will already ACK that segment, either before or when sending the NOTIFICATION, unless some deep TCP stack tweaking is done to effect this. Since the segment is ACK'd then it will be free'd on the sender side, as there is no reason to keep it around. Also, extracting the *malformed* UPDATE NLRI out of the TCP send buffer to then try to re-send it sounds like a good way for both the sender and receiver to get confused. But even if your specific notion of reaching into TCP is bad, your concept is good and fooling around with TCP just isn't a very good way to implement it. The vendors can of course choose to implement it however they please. > Otherwise, this would mean having to hold onto UPDATEs for possibly longer > than desired. I guess there is no free lunch, but what costs does your idea have other than spending some RAM to be capable of re-sending the NLRI from a recent UPDATE, and a little bit of CPU to manage the structure storing these recent UPDATEs? > And of course, this pushes the "ACK" further up the stack, from TCP to the > parent application (BGP). Again, maybe not that bad an idea, but definitely > non-trivial. Either it provides a fault tolerance mechanism at the cost of some RAM+CPU and the sender evicts the information needed to re-send NLRI after some timeout or memory limit has been reached, or else BGP Advertisements become less of a simple advertisement and a little closer to a request/response, except the response isn't anything more than "understood," not like LDP where responses are requests for LSP setup, etc. Anyway, I think your idea is clever, but has about zero chance of being liked by most people, because it is not that easy to implement and the frequency of need for it to actually mitigate or prevent an outage is extremely low. If I were inventing "BGP 5" I would not include the requirement for a sender to be able to re-transmit information from an already-transmitted Message because this could really be difficult on route-reflectors after major events, certainly on ASBRs at IXPs or with many eBGP customers receiving DFZ, IXP route-servers, and so on. Instead I would just invent BGP 5 to have a more robust Message structure and be done with silly errors that are difficult to recover from. By the time you go to the effort to program your feature, you might as well just program a superior Message structure and not have any CPU/RAM expense for already-transmitted data. Just my $0.02. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From randy@psg.com Mon Dec 10 15:37:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E0321F86CB for ; Mon, 10 Dec 2012 15:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbyVUoKP7Q1d for ; Mon, 10 Dec 2012 15:37:54 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DCA1521F8758 for ; Mon, 10 Dec 2012 15:37:53 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TiCv2-000Ae1-SI; Mon, 10 Dec 2012 23:37:53 +0000 Date: Tue, 11 Dec 2012 08:37:51 +0900 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20121210225858.GC24937@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 23:37:54 -0000 this misses my point entirely. we know not to announce private ASs. my point was o i do not accept the use example in the draft as justification for an allocation of more private ASs. in fact, i object to it and specifically object to the draft being advanced. we do this already without your requested allocation which then can only be viewed as an end-run around the IR system. o i can see tli's point about use in large datacenter deployments. if the draft is changed to use that (or a similar real need) as the motivation, i would reconsider my objection. apologies, but i do not know how to be more clear. randy From farmer@umn.edu Mon Dec 10 17:06:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F23D21F870F for ; Mon, 10 Dec 2012 17:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs1CBQU9ruz0 for ; Mon, 10 Dec 2012 17:06:03 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 84F4921F870E for ; Mon, 10 Dec 2012 17:06:02 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 10 Dec 2012 19:05:52 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f70.google.com [209.85.219.70] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f70.google.com with SMTP id k14so17208827oag.9 for ; Mon, 10 Dec 2012 17:05:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=opieea8gX/pyWDyA4yDInTLkpshCReTYKjGVGvBJqFQ=; b=SLHTAdMdpsxcbM9z5wYrxdK7gwF9hnjWok3HhNr1gVgBSDfwUB3YmriTwYdVSJgVP3 KWSMLqscjRw60GruzACjTaFa/X+ro0I/oPCnlxD+qP1xKxdM2gqNFvxJqEHtC85fXZw/ 9jmBcZ/0LRK+EdDiuz5aD3Ztu3DbF5JjXRRVwGn9dkbY3+jcpBbdxNDasFH+czysbe4A 9zz9vTJiZDVzWj3kVv4cwFHzHDHwN/NaLAVDjMQMnFm7z8b/74lJIvrfYsLrykWsoG+c Ra1qRQgqOfqNk96Y5459yGtEAiZ9VDJ357CbsuoFVODM98ha7kkyug5zr0VHoGgv1Oae YnOg== Received: by 10.50.194.132 with SMTP id hw4mr8514354igc.37.1355187951748; Mon, 10 Dec 2012 17:05:51 -0800 (PST) Received: by 10.50.194.132 with SMTP id hw4mr8514353igc.37.1355187951623; Mon, 10 Dec 2012 17:05:51 -0800 (PST) Received: from x-128-101-232-153.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:4037:65e9:fe88:a5e]) by mx.google.com with ESMTPS id yf6sm8192597igb.0.2012.12.10.17.05.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2012 17:05:50 -0800 (PST) Message-ID: <50C686F3.9030100@umn.edu> Date: Mon, 10 Dec 2012 19:05:55 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jon Mitchell References: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <50B986F2.5060405@umn.edu> <20121210225019.GA24937@puck.nether.net> In-Reply-To: <20121210225019.GA24937@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlyAqwOlfBIfUZzNa0c+TmgRsEzfjVyCqjwKq+Kgo5PSMyRe+iaXJU/e1zEGsmlsY7ZyYUp1O2KKWm6lKzFjtZLgKAoGS1jRP6AR1gHp8SfjPNBErmLb9uBdiTjDLzDSG518mA6 Cc: Tony Li , idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 01:06:04 -0000 On 12/10/12 16:50 , Jon Mitchell wrote: > > David / Randy - thoughts inline... > ... >>> update the draft to make these arguments, i will support it, and i >>> suspect other dissidents will as well. > > Actually Randy, to be fair, I think a number of dissendents will not > over a philosophical objection to private use space, and I'm quite > shocked at this development since previously I asked you specifically if > there was anything in the wording that could be changed that would allow > you to support it and you declined. Trying to do a neutral re-reading > of the draft (I think you naturally read it from an ISP providing > Internet access point of view), I see the last sentence in the > introduction which was meant to be a broad statement on why BGP has > proliferated to so many organizations (which includes provider > redundancy) could be confused to be meaning that "provider assigned asn" > is the target of this draft. In a general sense, I'd rather expose any > issues with private use asns and then allow operators to make their own > problems in so much as they don't affect others unnecessarily which you > seem to agree with. I'd be willing to delete that line if you think > appropriate? > >> >> In the first paragraph of the introduction there is already a >> reference to BGP/MPLS IP VPNs [RFC4364], do you want Data Centers >> explicitly added with reference to >> draft-lapukhov-bgp-routing-large-dc too? Are there other references > > Brian - As much as marketing is important, I don't think including a > reference a draft that we haven't yet found a home for that documents > Microsoft use of BGP within some DC's is a good idea for something that > applies generically to multiple sites within a single organization. I > think many can agree they have seen DC's be in a seperate AS > (public/private/confed) than the core networks which attach them, I have > seen this as a normal configuration in multiple networks over the last > 12 years personally.... I unfortunatley tried to capture this as large > content providers and may have more generically said DC operators > (either within or between DC's where they determine the connectivity), > but I don't think one sentence in the introduction is worth re-opening > the draft text during WGLC. I'd be open to considering this past WGLC > as a minor change however, along with striking the last sentence of the > introduction if you both think this is appropriate. In the introduction I believe you do a good job motivating that the uses of BGP have expanded significantly since RFC 1930 and this is what justifies the expansion. I'm including the relevant text from the draft; ... Since the time when that range was reserved, BGP has seen much wider deployment in service provider, enterprise and content provider networks. The places in these networks where private use ASNs are in use include networks that are attached to the Internet, utilizing implementation specific features to remove them upon advertisement to Internet peers, and networks that are not attached to the Internet. The displacement of Frame Relay and ATM based VPNs by BGP/MPLS IP VPNs [RFC4364] has also increased the deployment of BGP to a larger number of sites, especially in networks with requirements for multi-homing or provider redundancy. But I will note that large scale data center use of BGP is not explicitly mentioned, maybe it should be added, at least as another anticipated use case of more than 1023 ASNs within a single private use ASN domain, with or without a reference to the aforementioned draft. But, this is the only draft or RFC that I can find that explicitly motivates the need for more that 1023 private use ASNs, so not including the draft weakens the argument for why we need more that 1023 ASNs, in fact I would suggest explicitly referencing section 7.2.2 of the draft where the issue is discussed. Also, I suggest including that BGP/MPLS IP VPNs [RFC4364] for enterprises with more than 1023 sites can't use the fairly common practice of assigning a private use ASN per site, and is another use case for more that 1023 private use ASNs. A similar example is a large private BGP cloud, not necessarily using MBGP, with fairly complicated internal routing policy amongst a large number of sites. I guess what I'm trying to get at is; You should add specific examples of where the current 1023 private use ASNs are not enough, to help motivate why more are needed. This is not to say where private use ASNs should or shouldn't be used, but that there exist real world cases that justify more than 1023 private use ASNs. Furthermore, these reasons are also motivations for some network operators to squat on public ASNs, if there is not a larger space of private use ASNs assigned. Tony's argument was basically the Data Center guys are going to do this whether we want them to or not and that it is better for there to be an assigned a block than have them squat on public ASNs, I think that is the argument Randy is asking to be included in the draft. I think this argument also applies to BGP/MPLS IP VPNs and internal enterprise use of BGP; I've had a couple enterprises ask me about more that 1023 private use ASNs and could/should they use some of the 4-byte ASN space. I've told them to hold off and wait for this draft to assign a larger private use block from the 4-byte ASNs, rather than squat on public ASNs. But, in the long-run they are going to squat on public ASNs, if there isn't a larger block of private use ASNs for them to use. Also, even if we revise RFC 1930 and/or the RIR's revise their policies, to easily allow large publicly registered ASN blocks; There is a perception that many enterprises have that a private use block is better and more secure than a registered block. It makes my head hut, and we can tell them all the reasons they are wrong, but that is their perception and it is their network they will be using them in. > I'd like to re-iterate overall that the purpose the draft is primarly to > make an IANA reservation, not to dictate or recommend to others what to > do with it, except in the operational considerations lay out the changes > to consider to continue to play nice with the broader Internet. I agree we don't want to tell people where or where not to use private use ASNs in the draft. However, it is not unreasonable to make sure we have a consensus on why 1023 private use ASNs are not enough, that there is justification to expand there numbers, and to document the reasons. And, from what I'm hearing this is what needs to be added to the Draft. Especially, the data center argument above. > Jon > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From shane@castlepoint.net Mon Dec 10 22:55:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1292021F856B for ; Mon, 10 Dec 2012 22:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsC6iTL4gAxe for ; Mon, 10 Dec 2012 22:55:47 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4226121F8568 for ; Mon, 10 Dec 2012 22:55:46 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 24990300036 for ; Tue, 11 Dec 2012 06:55:46 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 6D5E3300035; Mon, 10 Dec 2012 23:55:45 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Mon, 10 Dec 2012 23:55:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0242C631-5898-46DB-B325-8118D56C2F60@castlepoint.net> References: <20121210225858.GC24937@puck.nether.net> To: Randy Bush X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Dec 10 23:55:46 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50c6d8f2199637057511983 X-DSPAM-Factors: 27, Idr+ietf, 0.01000, Subject*Re+#+WGLC, 0.01000, the+#+#+#+to, 0.01000, mailing+list, 0.01000, Idr+#+#+https, 0.01000, Subject*Idr+WGLC, 0.01000, 2012+at, 0.01000, Subject*on+draft-ietf-idr-as-private-reservation-00, 0.01000, at+#+#+PM, 0.01000, and+#+the, 0.01000, list+#+ietf, 0.01000, mailing+#+#+ietf, 0.01000, Url*org/mailman/listinfo/idr, 0.01000, On+Dec, 0.01000, Subject*Idr+#+#+draft-ietf-idr-as-private-reservation-00, 0.01000, list+Idr, 0.01000, Cc*idr+ietf.org, 0.01000, Randy+Bush, 0.01000, mailing+#+Idr, 0.01000, Idr+#+list, 0.01000, the+#+#+of, 0.01000, Dec+#+#+at, 0.01000, Dec+#+2012, 0.01000, Url*www, 0.01000, Subject*Re+#+#+on, 0.01000, the+#+of, 0.01000, in+the, 0.01000 Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 06:55:48 -0000 On Dec 10, 2012, at 4:37 PM, Randy Bush wrote: > this misses my point entirely. we know not to announce private ASs. >=20 > my point was >=20 > o i do not accept the use example in the draft as justification > for an allocation of more private ASs. in fact, i object to > it and specifically object to the draft being advanced. we do > this already without your requested allocation which then can > only be viewed as an end-run around the IR system. May I ask how you are 100% confident that there are 0 deployments of = IPVPN's, today, that have no need for more than 1,023 private ASN's = (64,512 - 65,535)? And, while I'm here, may I also ask why you believe = it better that operators be forced to _continue_ to play games with = 'as-override'[1] and/or 'loops'[2] to overwrite and ignore, = (respectively), duplicative private ASN's in the AS_PATH in such large = IPVPN's, breaking BGP's fundamental loop detection mechanism, due to the = limited space of private ASN's, ultimately making troubleshooting for = said operators more complicated? (Oh, and increasing the complexity of = the BGP codebase, associated regression test cases run by vendors & = operators, etc.)? -shane [1] = http://www.juniper.net/techpubs/en_US/junos10.2/topics/reference/configura= tion-statement/as-override-edit-protocols-bgp.html [2] = http://www.juniper.net/techpubs/en_US/junos10.2/topics/reference/configura= tion-statement/local-as-edit-protocols-bgp.html > o i can see tli's point about use in large datacenter deployments. > if the draft is changed to use that (or a similar real need) as > the motivation, i would reconsider my objection. >=20 > apologies, but i do not know how to be more clear. >=20 > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From chris.hall@highwayman.com Tue Dec 11 03:37:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40721F8496 for ; Tue, 11 Dec 2012 03:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.34 X-Spam-Level: ** X-Spam-Status: No, score=2.34 tagged_above=-999 required=5 tests=[AWL=-2.121, BAYES_00=-2.599, GB_SUMOF=5, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOsdaS8JChUv for ; Tue, 11 Dec 2012 03:37:24 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tch.inty.net [91.221.169.50]) by ietfa.amsl.com (Postfix) with ESMTP id 452BC21F8488 for ; Tue, 11 Dec 2012 03:37:15 -0800 (PST) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id A7136128416; Tue, 11 Dec 2012 11:37:14 +0000 (GMT) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 7AE84128415; Tue, 11 Dec 2012 11:37:14 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tch.inty.net (Postfix) with ESMTP; Tue, 11 Dec 2012 11:37:14 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TiO9A-0005hj-Gj; Tue, 11 Dec 2012 11:37:12 +0000 From: "Chris Hall" To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> , <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh>, <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10DD99@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E10DD99@eusaamb109.ericsson.se> Date: Tue, 11 Dec 2012 11:37:07 -0000 Organization: Highwayman Message-ID: <013301cdd793$dcac5be0$960513a0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwJ9rDNhpCAk7gfRWZlMlTSLUu6QFwpw6KAjDRnx0CVlUcVAFHaBeAARUnQBoBYBPk8QGjHInVAU6Z2PwCWugrJwCjhW3CAl9IPxQBWty0zQCWm32nAay9fNuXIKxf4A== Content-Language: en-gb X-MDF-HostID: 22 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:37:25 -0000 Jakob Heitz wrote (on Mon 10-Dec-2012 at 18:09 +0000): > On Monday, December 10, 2012 9:52 AM, Chris Hall wrote: .... > Once you have a malformed update, NOTHING is certain. > We limit the damage and call for human intervention. OK. That's the "mission statement". As we get into the detail I think I see where my disconnect is. The draft gets very picky about NLRI and NLRI attributes. The moment it sees any malformation in those, it throws up its hands and hits the session-reset button. The draft allows repeat attributes of the same type, except for NLRI attributes. The draft uses a fair amount of pencil explaining why simply discarding UPDATE messages is unsafe, which suggests that "treat-as-withdraw" is the minimum requirement if session-reset is to be avoided. [BTW, why are repeat NLRI attributes deemed a cardinal sin (session-reset, already) ? If they are valid, the semantics are entirely clear... here are some more prefixes to be updated/withdrawn.] The introduction to the draft states: "The goal ... is to minimise the impact on routing ... while maintaining protocol correctness .... removing the routes carried in the malformed UPDATE from the routing system." >From all that, I have been working on the assumption that "limit the damage" implies, at a minimum, not proceeding unless all NLRI have been identified, and can therefore be "treated-as-withdraw" -- or, at least, not proceeding unless reasonable steps (TBD) have been taken to identify all NLRI most of the time (also TBD). As you say, with a malformed update "NOTHING is certain", so this is Tricky, and the receiver has to take some view on what are reasonable steps. I have suggested verifying the attribute "framing" as a minimum requirement for that. It has also been suggested that, having found a malformed attribute, the receiver should stop stepping through attributes by attribute length, and scan octet-wise looking for NLRI attribute(s). However, if the sender is helpful, and places NLRI attributes ahead of all others (as required by the draft) then the receiver can stop worrying about trying to deal with attributes where "NOTHING is certain", and can process the NLRI (effectively) separately -- provided the receiver has some means of knowing the sender is being helpful. However, it seems that identifying all the NLRI is not as important as I had understood it to be, so the receiver need take no special steps to extract the NLRI. So, if the sender is helpful, things will generally work better, but otherwise it makes no difference to the receiver. I don't agree, but that seems to be the approach. > > I can quite believe that, in practice, few BGP implementations (if > > any) send more than one of the above forms of NLRI in a single > > UPDATE message. > > > > But that is not a requirement of the RFC or the draft -- so the > > receiver is not (strictly speaking) entitled to assume it. > It assumes the best it can to limit the damage. What do you suggest that should be ? In a world were "NOTHING is certain", does it matter if different implementations make different assumptions ? Or should the specification require consistent behaviour in the face of uncertainty, if nothing else, to avoid increasing that uncertainty ? > > What is the receiver supposed to do if it has not found any NLRI > > at the point that it hits a malformed attribute ? > Reset the session. We have established that the error-handling is not required to find all NLRI. That is, we are happy proceeding with a session where there are some NLRI which we would prefer to have "treated-as-withdraw", but could not. In effect, we are prepared to tolerate a measure of "UPDATE-discard" (Appendix A of the draft, notwithstanding). I suppose there is a difference between knowing that we have missed some NLRI and not knowing whether we have found all NLRI. However, given the pain associated with session-reset, is there a good reason for accepting one degree of "UPDATE-discard" and not another ? > > So, the receiver scans the attributes, and on the first malformed > > one it stops. Yes ? Or, perhaps it ploughs on to the end > > stepping past malformed attributes, and truncating the final > > attribute if it overruns the 'Total Attributes Length'. Yes ? > It doesn't stop. So the parsing of attributes takes the Attribute Length of a malformed attribute at face value. Since "NOTHING is certain", it doesn't have much choice. If the final attribute overruns the 'Total Attributes Length' (or there is an incomplete attribute header at the end) one thing is certain, the attributes are badly broken -- the sender has been unable to complete the simple task of correctly "framing" the attributes. I think the draft expects this case to be taken as a malformation of the attribute. The draft delegates the definition of malformation to the relevant documentation for each Type of attribute. If there is intended to be a general or default way of dealing with this case, then I think the draft needs to specify. If the sum of the Attribute Lengths is exactly the 'Total Attributes Length' (but some attribute is malformed) then "NOTHING is certain", but it is possible/probable that all attributes have been identified. [The degree of confidence may be increased if the Flags and Length of known and well-known attributes are correct, and there are no repeated attribute types, and perhaps other "semantic" information is taken into account.] This all matters rather more if one is trying to identify all NLRI attributes, but not one jot or iota otherwise apart from the diagnostics. The draft has a binary approach to attributes, they are either malformed or not malformed (well-formed). Is there room for a "semantic error" ? That is, an attribute which is well-formed as far as its Flags, Type, Length and, perhaps, internal structure are concerned, but make no sense at all. The result may still be "treat-as-withdraw" (say) but the error does not cast doubt on the attributes which follow. The distinction would improve the diagnostics. So, it appears that the draft is taking a pretty relaxed view of what is acceptable -- since "NOTHING is certain" why sweat it ? I am worried by the option to "attribute discard". If things are not certain, is "treat-as-withdraw" not the safer option ? An ATOMIC_AGGREGATE attribute, for example, is considered malformed if it has any length other than 0. Since nobody gives a rodent's posterior about this attribute, it seems to make perfect sense to throw it on the floor if it is malformed. Except, except, the length of an attribute also affects the attributes around it. An ATOMIC_AGGREGATE attribute with a length of (say) 700 octets is such obvious nonsense ! And that's to simply be discarded ? Surely either the sender has departed the reservation in something of a hurry, or some earlier (possibly undetected) attribute error has thrown the parser off track ? The balance of probabilities has to be that this is a symptom of some problem deeper than a meaningless value for a meaningless attribute... surely ? If the attribute length is indeed invalid, then the sum of all the attribute lengths is probably going to be wrong, so this will decay into "treat-as-withdraw". Nevertheless, I struggle to see the point of applying "attribute discard" in any case of attribute malformation. IMO "attribute discard" will be appropriate for some "semantic errors", only. .... > > Any NLRI that might be in the UPDATE, but are not visible > > because of the malformed attributes, are simply ignored. > > Yes ? > yes. > Again: > Once you have a malformed update, NOTHING is certain. > We limit the damage and call for human intervention. Well, as above, this means it is OK to let (some, indeterminate) NLRI fall into a state where they should have been withdrawn or are now out of date. So, why should session-reset *ever* be required ? Damage-limitation-wise, avoiding session-reset is the big win... so why not keep going no matter what, and let the human beans deal with it... much better than falling into a cycle of session-reset/restart/reset/... ? >> ... Also, I kinda suspect that the human bean will be >> greatly assisted if it is clear which NLRI have been affected >> (and which definitely have not). > The human bean will not rely on ANY routes or information > from the broken session. Well, even more reason to stop being picky at the protocol level, and hence: "treat-as-withdraw" where you can, and "UPDATE-discard" the rest ? Chris From jsw@inconcepts.biz Tue Dec 11 03:37:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B721F87BC for ; Tue, 11 Dec 2012 03:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlDP41mdTTCC for ; Tue, 11 Dec 2012 03:37:42 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B7A21F8532 for ; Tue, 11 Dec 2012 03:37:42 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so7409044iaz.31 for ; Tue, 11 Dec 2012 03:37:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/0sTxSJNA9O8kuutrMiXz5TVFxDgTyk50SrZxlfuD78=; b=YcvuqkHU4lFcfOsUItWoFUKTfYuLFjGkDlQXJP73lXlfgCrYpsPlpFJAdm504vQEJ4 cBTGjbUanOAnBZE2rUwF6behgXjXviqlpPrXLkn6+4DicX6e6qokP+JoKX6L4OAll9da f8JV8ljX6u9E67xjlXLIkzROUJDPXVXJFaMAcgqLu/XUwuxREz88r7eYYysxxBdGQuzG BkDI7zscytsDo4xFpgJVW4ROYS/1gZFR9Z5Q9mY04+tRpmdtIz+aCyuSFDeDTavMT7BE oOy2ZI5T4+Poa/bNfBhYy6+WLC+C11nO0R1TZRtU+yWhzthqPpwO6+k87o6g7MiZLxXl BkYg== MIME-Version: 1.0 Received: by 10.42.180.65 with SMTP id bt1mr13688067icb.41.1355225858822; Tue, 11 Dec 2012 03:37:38 -0800 (PST) Received: by 10.64.132.33 with HTTP; Tue, 11 Dec 2012 03:37:38 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <50C686F3.9030100@umn.edu> References: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> <50B986F2.5060405@umn.edu> <20121210225019.GA24937@puck.nether.net> <50C686F3.9030100@umn.edu> Date: Tue, 11 Dec 2012 06:37:38 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmrB2r8auF3faocKVcXJl1qLzgLitcaIpQvUnMXr6PYe2OHxxBtpMMfLAEOh8gLt743bDWb Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 11:37:43 -0000 On Mon, Dec 10, 2012 at 8:05 PM, David Farmer wrote: > Also, even if we revise RFC 1930 and/or the RIR's revise their policies, to > easily allow large publicly registered ASN blocks; There is a perception I have read that argument a few times. I don't think it would be wise to try to invent RIR policy for handing out potentially large blocks of ASNs to orgs without a lot of specific debate about what uses are "acceptable" and what aren't, which will ultimately result in RIR policy that does one of two things: * limits applications by making it hard to get huge ranges * makes it easy to get huge ranges, so everyone will ask for a huge one, and then we will face a 32-bit ASN depletion problem, and decide to revise the policy, but there will be a bunch of early-adopters who have these gigantic blocks; and then a huge block of private ASNs will be created ANYWAY as a half-way measure to "level the playing field" and avoid squatting My view is that changing RIR policy to address this is quite stupid, and it is unrealistic to think that the RIR membership would be stupid enough to do it without first saying, "why isn't the private ASN space expanded?" There are some reasons why you may want unique public ASNs instead of private, re-usable ASNs inside of service provider L3VPNs but only if you can convince your customers to actually utilize them, and then hand-hold your customers through requesting those blocks so they can be assigned to sites. Randy has plenty of history trying to force his view of what is "optimal" to become the only possible option, instead of offering choices and flexibility. RIRs can still decide to give big ASN blocks out if their memberships want that, whether the private ASN range is expanded or not. In fact, proposing to RIR membership that a private resource is being exhausted thus it must be made easier to acquire public resources for private uses, is not a smart way to convince RIR members to vote in favor of that proposal. $0.02. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jsw@inconcepts.biz Tue Dec 11 05:52:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C5C21F8499 for ; Tue, 11 Dec 2012 05:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFVncR+BRRqN for ; Tue, 11 Dec 2012 05:52:25 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 93FA621F847D for ; Tue, 11 Dec 2012 05:52:25 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e13so17373478iej.18 for ; Tue, 11 Dec 2012 05:52:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=oAkwLEypQhSaIYIQH2OoRmRhmXtNmKCy77SNYXsf+LE=; b=X4ZkipaNLokOTN5iX9TLCAaDAQfcT1rOVG89WoNfiPR7HxIVCTmdsuDtzDLmwTMghz qhoNrd62eLqVnn4EtE8ZIPf/cy4J4LZQwr5TZLh54MQQs68/oAzCuwKvWCIMXUNc1Rxi Yv/BV0N9l2rRmd2iOkgWWugr7S+GBuTWG2EiK19fiFQttw6/zTQg+JOPOVJjHBAOgVhv zOB/pB+Z1UeRChBvV2idQRRU3SuAcf2CLTIdK4SENNKLfaHdLaMKx3hbxkHVzhvuBhTg Z6M+ykjvgUmNrNh1LgBwSVxI8AIUf/1v2xy/598HV7EqfDpmkdVok8Qs3HLpkjm7cENK Mwdw== MIME-Version: 1.0 Received: by 10.50.214.97 with SMTP id nz1mr10095968igc.36.1355233945036; Tue, 11 Dec 2012 05:52:25 -0800 (PST) Received: by 10.64.132.33 with HTTP; Tue, 11 Dec 2012 05:52:24 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> <50AD2986.90705@cisco.com> <058b01cdd3b4$9f5193b0$ddf4bb10$@highwayman.com> <8ED5B0B0F5B4854A912480C1521F973A0F4940@xmb-rcd-x13.cisco.com> <94913EE5-2864-4EE2-B474-9631430B1E22@ericsson.com> <068701cdd478$2cf01cf0$86d056d0$@highwayman.com> <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10DD99@eusaamb109.ericsson.se> <013301cdd793$dcac5be0$960513a0$@highwayman.com> Date: Tue, 11 Dec 2012 08:52:24 -0500 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQniPnnbIeZa5ArGy6jp7fiFkgFcieCGW3JRMN6maRoEzjvBRnEimPdLzBZSGLqGqQTTZl4b Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 13:52:26 -0000 On Tue, Dec 11, 2012 at 8:40 AM, Jeff Wheeler wrote: > That part of the draft is limited to analyzing the reachability or > fault state of individual prefixes. It doesn't even consider that > screwing up one prefix is potentially much worse than resetting the > session just to maintain correctness. Basically, it is a myopic Oops, I meant to write, "screwing up one prefix is potentially much BETTER than resetting the session." -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rraszuk@gmail.com Tue Dec 11 08:54:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D768221F8762 for ; Tue, 11 Dec 2012 08:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCwlHCi+1zhP for ; Tue, 11 Dec 2012 08:54:03 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 665E121F871A for ; Tue, 11 Dec 2012 08:54:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3380137lah.31 for ; Tue, 11 Dec 2012 08:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nZBiKqE9eC17sDMJfJprqpebcTavVeeHdvNptALD8aU=; b=aWvc/F+TlxrXelblVP768OxcGngPYs6oAvDelp9pyZXIg29K+AkpOiiOmex7tmV3Ht 0OM54PzET+OKZmBXfr9USqOxNQ2UFqdl2j6ur07DaYH/SeoD4A5uwktVgkXqep6IILsp JTYxGa8H/FPBroLdk4XeaK16ZbtVb7R9OvU+UBP+wziAELKIXpgwa84Aijszokb0s6ak VF+960bU1wMT49RbdMlQ9E3tJ+3i/hp8EWFbXsPY0pxibECxe3NZ9e8Msd1vsnwlYnHN 9t+KmoqM/ltJHSe3EuqJ9Yw04ZkDyN+BBGOGUA001TdJ10LnoZ81vY8RtEzhP977gc/4 qLXw== MIME-Version: 1.0 Received: by 10.152.104.226 with SMTP id gh2mr2543065lab.24.1355244842243; Tue, 11 Dec 2012 08:54:02 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.133.41 with HTTP; Tue, 11 Dec 2012 08:54:02 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> Date: Tue, 11 Dec 2012 17:54:02 +0100 X-Google-Sender-Auth: WSy0f-DPRi6v_PAqfwRU_PuDtH0 Message-ID: From: Robert Raszuk To: idr wg Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 16:54:06 -0000 All, I think Jon should remove any use case examples from the draft as there is no way one could enforce that the new range will _only_ be used in those use cases. I think Jon in fact already said it very clearly that the point of the draft is to get IANA registration. That' it - no more no less. It would be up to individual operators to use such new range in L3VPNs as Shane points out, in DCs or for that matter in ISPs. Also it seems that it could be useful for dynamically routed home gateways and in that respect I think the current range may be in fact too small so I am sympathetic to broaden this space. If this is bit boundary aligned or human aligned I think is secondary .. I have no personal preference. Many thx, R. On Tue, Dec 11, 2012 at 12:37 AM, Randy Bush wrote: > this misses my point entirely. we know not to announce private ASs. > > my point was > > o i do not accept the use example in the draft as justification > for an allocation of more private ASs. in fact, i object to > it and specifically object to the draft being advanced. we do > this already without your requested allocation which then can > only be viewed as an end-run around the IR system. > > o i can see tli's point about use in large datacenter deployments. > if the draft is changed to use that (or a similar real need) as > the motivation, i would reconsider my objection. > > apologies, but i do not know how to be more clear. > > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From russw@riw.us Tue Dec 11 10:26:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F57821F8812 for ; Tue, 11 Dec 2012 10:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJV+CgWAQMpR for ; Tue, 11 Dec 2012 10:26:06 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5003F21F8802 for ; Tue, 11 Dec 2012 10:26:04 -0800 (PST) Received: from nat1.corp-fo.iad1.verisign.com ([216.168.230.7] helo=[10.88.68.144]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1TiUWp-0007iS-C2; Tue, 11 Dec 2012 10:26:03 -0800 References: <20121210225858.GC24937@puck.nether.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> X-Mailer: iPad Mail (10A523) From: Russ White Date: Tue, 11 Dec 2012 13:26:03 -0500 To: Robert Raszuk X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:26:07 -0000 +1 Lets steer away from the justifications in a draft, as they might well chang= e over the next 5 years anyway. The justification seems well supported o lis= t, so make the draft simple... :-) Russ <>< russw@riw.us riwhite@verisign.com On Dec 11, 2012, at 11:54 AM, Robert Raszuk wrote: > All, >=20 > I think Jon should remove any use case examples from the draft as > there is no way one could enforce that the new range will _only_ be > used in those use cases. >=20 > I think Jon in fact already said it very clearly that the point of the > draft is to get IANA registration. That' it - no more no less. >=20 > It would be up to individual operators to use such new range in L3VPNs > as Shane points out, in DCs or for that matter in ISPs. >=20 > Also it seems that it could be useful for dynamically routed home > gateways and in that respect I think the current range may be in fact > too small so I am sympathetic to broaden this space. If this is bit > boundary aligned or human aligned I think is secondary .. I have no > personal preference. >=20 > Many thx, > R. >=20 >=20 >=20 > On Tue, Dec 11, 2012 at 12:37 AM, Randy Bush wrote: >> this misses my point entirely. we know not to announce private ASs. >>=20 >> my point was >>=20 >> o i do not accept the use example in the draft as justification >> for an allocation of more private ASs. in fact, i object to >> it and specifically object to the draft being advanced. we do >> this already without your requested allocation which then can >> only be viewed as an end-run around the IR system. >>=20 >> o i can see tli's point about use in large datacenter deployments. >> if the draft is changed to use that (or a similar real need) as >> the motivation, i would reconsider my objection. >>=20 >> apologies, but i do not know how to be more clear. >>=20 >> randy >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From edc@google.com Tue Dec 11 10:43:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5626721F8543 for ; Tue, 11 Dec 2012 10:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcX8B7jrv-1h for ; Tue, 11 Dec 2012 10:43:20 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76A0521F8485 for ; Tue, 11 Dec 2012 10:43:20 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so3261937qan.10 for ; Tue, 11 Dec 2012 10:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ST2Z4Ysn5OmNUNafuDT4dN9cfWeQok/qaZPa2G9mPRI=; b=MXPP08xJDhzcYSD7kLS9MgHWFDRcbcyZkW4376MObVCroxu8hW0YEiBIb9yWkUeRuf lVNK3gz3SC7JfR+8vAO2+t2lmLWOZoQWfw66TB9b+NL+Cm+nF1/Jgl/QulVFKcJMr5Bs gbd2zp9wQM/unCyWBb8Lv5mbzWfK57vYrbyx98CxiHdFlWcBgXmcQ5QtCk2FmzbtX/00 ZtrTea5LbP3PxhsMz8AZPYPmpw+tvV4XubiOCm522Ot8KOBe4+XEs6EcFA07DToqGNAQ PpRSPBMwAS0n0iKRBO/0sBePVnVx01lHRmnzA3lByBZ/vCb4ADrhO0SpL37o3s7gt8nc pHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ST2Z4Ysn5OmNUNafuDT4dN9cfWeQok/qaZPa2G9mPRI=; b=bG6qUVIqSKjZjHZEuGQ8s1VS2wfsXB0LiYVbYhTz42R7roPZ72KM5A7Z6sLPqRNpCQ iQTe4zHstQ541XGEFjpOyrchxvrW8T9RS0VW6LL2aT+GZWWeFudIxSYETHuSVyQqba6t cJAB1ZqZlPRoNaQ1H3jFmT+oizMxDOmCsCPbB76KY5+30bjo293dj1hSmVd8hEHBGI/3 qWqO1yN6YX8P7AVUtAhZGzkUrgk/qrJIShoWK7Pn0VEBt8mzelP0hn3EuY6tnzZefMij YG9NEjnJnXsBfXCKOTvSynrfgV5DezciHppBZQbL5oaBXIr+vC/OHC6ExjVKX6R9BR0w QLUg== Received: by 10.224.33.135 with SMTP id h7mr35161702qad.26.1355251398779; Tue, 11 Dec 2012 10:43:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.48.17 with HTTP; Tue, 11 Dec 2012 10:42:37 -0800 (PST) In-Reply-To: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> From: Edward Crabbe Date: Tue, 11 Dec 2012 10:42:37 -0800 Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=20cf306f770434a25f04d0980ea6 X-Gm-Message-State: ALoCoQl5fE7GIhYEelNo73U8YYkN902l+Y+1wJyhxyVVKUsM02zx91cXcaGo8YwpozAnXA2rpCny5EywME+WXQJEWeOVgu8cObkLew8jvA7SZh40JIaQDWHB8Acu7b0dKuxs7BGus/YeCcpgkYEeZ1Vbzbi2UN4Pce5WcnCyIRfGDnx7zPffJKUEGY9k3nUonwtZyWELQYrf Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:43:21 -0000 --20cf306f770434a25f04d0980ea6 Content-Type: text/plain; charset=ISO-8859-1 +1 I'm for removing them. On Tue, Dec 11, 2012 at 10:26 AM, Russ White wrote: > > +1 > > Lets steer away from the justifications in a draft, as they might well > change over the next 5 years anyway. The justification seems well supported > o list, so make the draft simple... > > :-) > > Russ > > <>< > russw@riw.us > riwhite@verisign.com > > On Dec 11, 2012, at 11:54 AM, Robert Raszuk wrote: > > > All, > > > > I think Jon should remove any use case examples from the draft as > > there is no way one could enforce that the new range will _only_ be > > used in those use cases. > > > > I think Jon in fact already said it very clearly that the point of the > > draft is to get IANA registration. That' it - no more no less. > > > > It would be up to individual operators to use such new range in L3VPNs > > as Shane points out, in DCs or for that matter in ISPs. > > > > Also it seems that it could be useful for dynamically routed home > > gateways and in that respect I think the current range may be in fact > > too small so I am sympathetic to broaden this space. If this is bit > > boundary aligned or human aligned I think is secondary .. I have no > > personal preference. > > > > Many thx, > > R. > > > > > > > > On Tue, Dec 11, 2012 at 12:37 AM, Randy Bush wrote: > >> this misses my point entirely. we know not to announce private ASs. > >> > >> my point was > >> > >> o i do not accept the use example in the draft as justification > >> for an allocation of more private ASs. in fact, i object to > >> it and specifically object to the draft being advanced. we do > >> this already without your requested allocation which then can > >> only be viewed as an end-run around the IR system. > >> > >> o i can see tli's point about use in large datacenter deployments. > >> if the draft is changed to use that (or a similar real need) as > >> the motivation, i would reconsider my objection. > >> > >> apologies, but i do not know how to be more clear. > >> > >> randy > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --20cf306f770434a25f04d0980ea6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 I&#= 39;m for removing them.

On Tue, Dec 11, 2= 012 at 10:26 AM, Russ White <russw@riw.us> wrote:

+1

Lets steer away from the justifications in a draft, as they might well chan= ge over the next 5 years anyway. The justification seems well supported o l= ist, so make the draft simple...

:-)

Russ

<><
russw@riw.us
riwhite@verisign.com

On Dec 11, 2012, at 11:54 AM, Robert Raszuk <robert@raszuk.net> wrote:

> All,
>
> I think Jon should remove any use case examples from the draft as
> there is no way one could enforce that the new range will _only_ be > used in those use cases.
>
> I think Jon in fact already said it very clearly that the point of the=
> draft is to get IANA registration. That' it - no more no less.
>
> It would be up to individual operators to use such new range in L3VPNs=
> as Shane points out, in DCs or for that matter in ISPs.
>
> Also it seems that it could be useful for dynamically routed home
> gateways and in that respect I think the current range may be in fact<= br> > too small so I am sympathetic to broaden this space. If this is bit > boundary aligned or human aligned I think is secondary .. I have no > personal preference.
>
> Many thx,
> R.
>
>
>
> On Tue, Dec 11, 2012 at 12:37 AM, Randy Bush <randy@psg.com> wrote:
>> this misses my point entirely. =A0we know not to announce private = ASs.
>>
>> my point was
>>
>> =A0o i do not accept the use example in the draft as justification=
>> =A0 =A0for an allocation of more private ASs. =A0in fact, i object= to
>> =A0 =A0it and specifically object to the draft being advanced. =A0= we do
>> =A0 =A0this already without your requested allocation which then c= an
>> =A0 =A0only be viewed as an end-run around the IR system.
>>
>> =A0o i can see tli's point about use in large datacenter deplo= yments.
>> =A0 =A0if the draft is changed to use that (or a similar real need= ) as
>> =A0 =A0the motivation, i would reconsider my objection.
>>
>> apologies, but i do not know how to be more clear.
>>
>> randy
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--20cf306f770434a25f04d0980ea6-- From jrmitche@puck.nether.net Tue Dec 11 10:59:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6106621E8030 for ; Tue, 11 Dec 2012 10:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32kj-i+PfB3I for ; Tue, 11 Dec 2012 10:59:19 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8521E802E for ; Tue, 11 Dec 2012 10:59:19 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBBIxH4g001104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Dec 2012 13:59:18 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBBIxH6O001101; Tue, 11 Dec 2012 13:59:17 -0500 Date: Tue, 11 Dec 2012 13:59:17 -0500 From: Jon Mitchell To: Russ White Message-ID: <20121211185917.GA21813@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 11 Dec 2012 13:59:18 -0500 (EST) Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:59:20 -0000 Russ - I agree with this view, however this was already my intention and I believe how the draft reads today. There is very little text overall and none that purports to be a use case for the new range in the draft. There is a brief introduction that mentions that BGP use in lot of applications has expanded, some may have interpeted this to be a use case but it sure doesn't try to provide any guidance on it nor in the subsequent text. I volunteered to remove the last sentence of the first paragraph in case it was being misinterpeted in this fashion... but unless people have some other *specific* wording changes besides that (that stay away from getting into more specific use cases, for instance about large DCs), I don't plan to make any further changes to the draft. Jon On Tue, Dec 11, 2012 at 01:26:03PM -0500, Russ White wrote: > > +1 > > Lets steer away from the justifications in a draft, as they might well change over the next 5 years anyway. The justification seems well supported o list, so make the draft simple... > > :-) > > Russ > > <>< > russw@riw.us > riwhite@verisign.com > > On Dec 11, 2012, at 11:54 AM, Robert Raszuk wrote: > > > All, > > > > I think Jon should remove any use case examples from the draft as > > there is no way one could enforce that the new range will _only_ be > > used in those use cases. > > > > I think Jon in fact already said it very clearly that the point of the > > draft is to get IANA registration. That' it - no more no less. > > > > It would be up to individual operators to use such new range in L3VPNs > > as Shane points out, in DCs or for that matter in ISPs. > > > > Also it seems that it could be useful for dynamically routed home > > gateways and in that respect I think the current range may be in fact > > too small so I am sympathetic to broaden this space. If this is bit > > boundary aligned or human aligned I think is secondary .. I have no > > personal preference. > > > > Many thx, > > R. > > > > > > > > On Tue, Dec 11, 2012 at 12:37 AM, Randy Bush wrote: > >> this misses my point entirely. we know not to announce private ASs. > >> > >> my point was > >> > >> o i do not accept the use example in the draft as justification > >> for an allocation of more private ASs. in fact, i object to > >> it and specifically object to the draft being advanced. we do > >> this already without your requested allocation which then can > >> only be viewed as an end-run around the IR system. > >> > >> o i can see tli's point about use in large datacenter deployments. > >> if the draft is changed to use that (or a similar real need) as > >> the motivation, i would reconsider my objection. > >> > >> apologies, but i do not know how to be more clear. > >> > >> randy > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Tue Dec 11 11:20:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1430521F87EE for ; Tue, 11 Dec 2012 11:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM6sqDSrE3Nb for ; Tue, 11 Dec 2012 11:20:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4683021F87EA for ; Tue, 11 Dec 2012 11:20:11 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3507687lah.31 for ; Tue, 11 Dec 2012 11:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=saWUy/qjrmebcjz3z6xHdrfZbI67goRdwzP9czH3Waw=; b=qy57vouTMeye6St5v4B2hDNsQ90v8wpyDfJShvKErWlJ6r/1NrGwKzqJOV8ObcUajE o9PxJ1Ici34Mkfnc/H3tZm3Nq3jbsLd22TIN64FjbSvLOPunfBfWYxAw//cO0zsBJrMt MhVOxugHPOLiLvHfUV8lDMC6r8CVt11sMeWLeV/+cAMoyTVugMDX8hxzcBuPFwne3X3j 8LPdgOGh5oaOdA35e5UYWFImewLiurHr2kavN0Oj4YUL0bDPZVDZ0RhR1wBpgwZYPXdZ kIh+zYgAkHbu34bYBMwKPZVwHgrMaVg+1XmJymBUmyAwdaX2tAjvzNaivAl5dqndj+jE uHXw== MIME-Version: 1.0 Received: by 10.152.109.173 with SMTP id ht13mr14604100lab.12.1355253610223; Tue, 11 Dec 2012 11:20:10 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.133.41 with HTTP; Tue, 11 Dec 2012 11:20:10 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> Date: Tue, 11 Dec 2012 20:20:10 +0100 X-Google-Sender-Auth: zadtvola16dLd_2rXtaSKpb0vOw Message-ID: From: Robert Raszuk To: Jon Mitchell , idr wg Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:20:12 -0000 How about if we would take completely different approach ... Based on number of use cases it seems to me like perhaps we should just declare the top most bit in 4 octet AS space as indicator of private vs public. 50% ! 2^31 should be well sufficient for public use for a long time, likewise for private use. Filtering/replacing also seems trivial. Cheers, R. PS. I must say that I see nothing wrong with advertising private AS to the public. It is just that no one should look at single atomic AS in the AS_PATH. If you look at tuple of private AS + next AS what harm does it cause to anyone including SIDR ? From nick@foobar.org Tue Dec 11 11:40:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D60321F85D2 for ; Tue, 11 Dec 2012 11:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3rSeOobDjFo for ; Tue, 11 Dec 2012 11:40:33 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9266F21F85A0 for ; Tue, 11 Dec 2012 11:40:33 -0800 (PST) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:7467:1316:745b:3b8]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBBJcskP039262 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 11 Dec 2012 19:39:00 GMT (envelope-from nick@foobar.org) Message-ID: <50C78C29.3070406@foobar.org> Date: Tue, 11 Dec 2012 19:40:25 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF IDR Working Group References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:40:34 -0000 On 11/12/2012 19:20, Robert Raszuk wrote: > Based on number of use cases it seems to me like perhaps we should > just declare the top most bit in 4 octet AS space as indicator of > private vs public. Excuse me if this sounds atrociously naive, but putting my operator hat on: - i'm human and regularly need to parse asns in as-paths - i don't naturally count in binary - i would really like a set of numbers which I can easily see are private or public. Decimal alignment would work nicely, both for me and the NOC staff that are going to be dealing with these numbers on a daily basis. - looking at 4278190079 and 4278190080, I simply cannot tell which might be public and which might be private. This will cause leakage because it will not be obvious on sight to an operator looking at a bgp aspath whether the range should be propagated or not #operatorfail - unless something drastic has changed recently, I'm not aware of any plans to assign bitwise masks to ASNs. Consequently bitwise alignment for a private ASN range is a purely arbitrary construction - please change to using a decimal-aligned range. it would make my life and the lives of many operators a little easier. I suggest 4000000000 or maybe 4200000000, or something else. Not 4278190080, because that number means nothing to me - otherwise, I love the idea of this draft. Please let us have private ASNs and lots of them. There are plenty of them to spare in the can. thanks, Nick From randy@psg.com Wed Dec 12 03:11:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55F21F89A8 for ; Wed, 12 Dec 2012 03:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2zITdEGTNml for ; Wed, 12 Dec 2012 03:11:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B886321F8982 for ; Wed, 12 Dec 2012 03:11:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TikDZ-000GqH-8z; Wed, 12 Dec 2012 11:11:13 +0000 Date: Wed, 12 Dec 2012 03:11:12 -0800 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 11:11:16 -0000 > I think Jon should remove any use case examples from the draft as > there is no way one could enforce that the new range will _only_ be > used in those use cases. if there is no documented motivation for it, then we don't need the draft at all. simplifies live greatly. great idea. ;~> randy From tony.li@tony.li Wed Dec 12 08:09:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8755021F89B5 for ; Wed, 12 Dec 2012 08:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjk6nrOChm+q for ; Wed, 12 Dec 2012 08:09:57 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 2725721F889C for ; Wed, 12 Dec 2012 08:09:57 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta14.emeryville.ca.mail.comcast.net with comcast id aeY91k0081ZMdJ4AEg9xoX; Wed, 12 Dec 2012 16:09:57 +0000 Received: from sjc-vpn3-1249.cisco.com ([128.107.239.233]) by omta16.emeryville.ca.mail.comcast.net with comcast id ag7j1k00w52qHCY8cg7mTJ; Wed, 12 Dec 2012 16:07:55 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Wed, 12 Dec 2012 08:07:43 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> References: <20121210225858.GC24937@puck.nether.net> To: Randy Bush X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355328597; bh=ue/ku/Ee3ynVwo9Ju203/vMJ+ugvcQbtZ5V3qb+z0PQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=JKsU2vIjmf+7PcfFmWMq6Puf7O28hkjRNcoqBSOw5Xo8YGSWMRiZI5vczQXJC7Drt VoFiggNNoCHimB9i6OQfpi/UXj1XIjOW5XYXvGoRebyHEUhjcciewBm80hC7T9MbLk VBoDwUOPInq1eARcofxn57H8+sojfTwHXhC4Sg934LLMqhY9QYXbdI/uO9zGaO4AZM lwprg7EC3KQaQsyJ+lV24/OCsqRqGrHSV7VtD7XhzZkTWirwVUQ/IBv+QZWKuechA6 lOvL6eskownU7zMUgfPyuE53CUTuEmz3mXcSDLQbgvCbVjy5BkZ7zCYrfesKizFy3c M1DbuZD2SqIgA== Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:09:57 -0000 On Dec 12, 2012, at 3:11 AM, Randy Bush wrote: >> I think Jon should remove any use case examples from the draft as >> there is no way one could enforce that the new range will _only_ be >> used in those use cases. > > if there is no documented motivation for it, then we don't need the > draft at all. simplifies live greatly. great idea. ;~> Then we lard up every draft with marketing material. Is that better? Tony From randy@psg.com Wed Dec 12 08:23:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227721F8578 for ; Wed, 12 Dec 2012 08:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkQIyBjY-3Lu for ; Wed, 12 Dec 2012 08:23:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0302621E804A for ; Wed, 12 Dec 2012 08:23:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tip5k-000HiR-Ll; Wed, 12 Dec 2012 16:23:28 +0000 Date: Wed, 12 Dec 2012 08:23:28 -0800 Message-ID: From: Randy Bush To: Tony Li In-Reply-To: <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:23:34 -0000 >>> I think Jon should remove any use case examples from the draft as >>> there is no way one could enforce that the new range will _only_ be >>> used in those use cases. >> if there is no documented motivation for it, then we don't need the >> draft at all. simplifies live greatly. great idea. ;~> > Then we lard up every draft with marketing material. Is that better? a use case != marketing material without sayng why we want to do something, kinda hard to justify doing it. in this case, "we want to end run around the IR system for no reason, just give us the cash and we'll leave." and robert has been so vociferous about wanting requirements for other things that it is hard to resist hoisting him on his own petard :) randy From rraszuk@gmail.com Wed Dec 12 08:32:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA7C21F88A3 for ; Wed, 12 Dec 2012 08:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBQdpmXFBnQ0 for ; Wed, 12 Dec 2012 08:32:39 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0CF21F8504 for ; Wed, 12 Dec 2012 08:32:39 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id c14so2332850ieb.0 for ; Wed, 12 Dec 2012 08:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7O8dgd/9pvou+Xaxhdz1uG/q+++UH4qQN6QJcImSTuM=; b=nUzancXE3sJtpe1IyPqwUVsxO9GKFLwHsv3R5yxOgIip3QbIKgV+fi/cAbcjP2TPfe 4hj3dqfVsLX2Ut+XJHIK3JOcNLFdWfetzHkuIL7WF7P9ei2Yncwt4IP7S2atXDUFzGKk xmNjxNvklVvh5DyoEpPxqTAeYFSf8yvTv0DoZuwSqyeOAbF7+0/41d3ZvGRMd9TGFez5 xqIodd+CvG7Lb4+bjR6ccR4dMeeN9TGbLaCDVjkWgLoCptmMFVTjZDeCGWODCfWTmI4t aHsGrmz+Zu+hyztBKPvoy2GFwwgpkOiaoOPkyeSGMCYi1KN2MwdKeJphS4MmZolqIDKs M7aw== MIME-Version: 1.0 Received: by 10.50.207.104 with SMTP id lv8mr13937528igc.33.1355329959198; Wed, 12 Dec 2012 08:32:39 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 08:32:39 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> Date: Wed, 12 Dec 2012 17:32:39 +0100 X-Google-Sender-Auth: KbuIRPMHCzVeWZp2nVVBhX3HqJU Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , Tony Li Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:32:40 -0000 Randy, I am just realistic. Sincerely, R. > and robert has been so vociferous about wanting requirements for other > things that it is hard to resist hoisting him on his own petard :) From warren@kumari.net Wed Dec 12 08:34:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7977A21F88B7 for ; Wed, 12 Dec 2012 08:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcqaf2zaLqHz for ; Wed, 12 Dec 2012 08:34:20 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97DD21F88B6 for ; Wed, 12 Dec 2012 08:34:19 -0800 (PST) Received: from [192.168.1.38] (unknown [66.84.81.123]) by vimes.kumari.net (Postfix) with ESMTPSA id 28F471B405DE; Wed, 12 Dec 2012 11:34:19 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> Date: Wed, 12 Dec 2012 11:34:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net> References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1499) Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:34:20 -0000 On Dec 12, 2012, at 11:07 AM, Tony Li wrote: >=20 > On Dec 12, 2012, at 3:11 AM, Randy Bush wrote: >=20 >>> I think Jon should remove any use case examples from the draft as >>> there is no way one could enforce that the new range will _only_ be >>> used in those use cases. >>=20 >> if there is no documented motivation for it, then we don't need the >> draft at all. simplifies live greatly. great idea. ;~> >=20 >=20 > Then we lard up every draft with marketing material. Is that better? Nope, no-one is suggesting marketing material -- but I think having = *some* mention of a use case / justification is needed to readers can = evaluate if the idea is worth the time / risk. Providing instructions on how to build a little wooden platform with = strong spring held back by a bent piece of metal that you can attach = bits of curdled dairy makes no sense unless you explain that this will = help solve their mouse problem... W >=20 > Tony >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --=20 Eagles soar but a weasel will never get sucked into a jet engine=20 From randy@psg.com Wed Dec 12 08:41:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC8221E80C7 for ; Wed, 12 Dec 2012 08:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpzWPnP+-nsw for ; Wed, 12 Dec 2012 08:40:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A226E21E804D for ; Wed, 12 Dec 2012 08:40:58 -0800 (PST) Received: from [166.147.93.94] (helo=[10.6.200.97]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TipMf-000HGU-W5; Wed, 12 Dec 2012 16:40:58 +0000 References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A525) From: Randy Bush Date: Wed, 12 Dec 2012 08:40:58 -0800 To: Robert Raszuk Cc: idr wg , Tony Li Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:41:00 -0000 We all think we are realistic. A common delusion. randy, on a stinkin' iPoop On Dec 12, 2012, at 8:32, Robert Raszuk wrote: > Randy, > > I am just realistic. > > Sincerely, > R. > > >> and robert has been so vociferous about wanting requirements for other >> things that it is hard to resist hoisting him on his own petard :) From chandra.appanna@yahoo.com Wed Dec 12 08:51:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1614D21E8050 for ; Wed, 12 Dec 2012 08:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZqTCmwIourd for ; Wed, 12 Dec 2012 08:51:17 -0800 (PST) Received: from nm34.bullet.mail.bf1.yahoo.com (nm34.bullet.mail.bf1.yahoo.com [72.30.238.192]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2C21E80C6 for ; Wed, 12 Dec 2012 08:51:17 -0800 (PST) Received: from [98.139.212.144] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 12 Dec 2012 16:51:07 -0000 Received: from [98.139.212.205] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 12 Dec 2012 16:51:07 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 12 Dec 2012 16:51:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 439732.19217.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 3009 invoked by uid 60001); 12 Dec 2012 16:51:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1355331067; bh=791mP9ifpdK/LekSU5yKjcqMDJ3uJVfFiQjL/zfsd68=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=X/C94+2e3dtHCMjcnWAVp9eAEO3mBZip7enV2CNZvGhtl9MUmIXdCbYF4PAAGVMR0Fnzc/4zPhryxaM1hKyUUUMccuRgc0J/v986ve/lsmWcjmcf8uYaGO76zIMEoIsnvVDkT9ctAEgeA0neBNLUyl5vnXLSPH4Gf4SjRQK7lHc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n1yOQvxt/XI8GHu4/uHnCW4tC3Y6eZgutiFGD3aazhEshaZWLrB0/zkfu9PMX0YmQnAHuR7SO/B+9yGUDifk4R/zMHSiRGXoWazEQWtKIn+zKjPuJ+k/2Df0lAzB560j+3bhChRGfE5dZ3buX6pb1kthvqU/aHf/Nwc+bvIz06A=; X-YMail-OSG: D0zdMRAVM1lFgSzD83e7WXIBWKUvLvWEhSZEcM.qGvno9GM e_lsCEG61soI4UIqCIL55NQZsNvcoBBYUbJEfj4.eiWLkt93vtrhD7YJsWXQ 2.SCaDyjDrVWxt__gJcVUyft5966brXv9Ne8XaLmIryL8F6xS3hqbf8Pa8Pm yPKto5wsuuHTMAcFxFB0NyYuJgEnRyJvoPrHBYU6p81cquMzvAKZA6rW3Pb9 wDSSL4JzT3MWYt1Ov2ZzPN4Y6RWsVDOZI3Wke.JZZ.dqXGg6TK1xeAfckx0W WpUoobPnEmrvEMrP1Vy2XRBflcD4HFb5JdAbNzEPsMNYl282z5WFl9AHHqsv 1lq3SYXZUwTO9OYu8uIIFVxxwngomCK1mtuKMFNSOkLNmaSG1gO46TD6GOVV ls6GDwUEB9.QaGySYL3mgvHi6ecjVeOkJUOXu.okHfTAjgZEF5R1PltrlvlQ KNcy3Bah1satwCv1Vo7yZ559JsaGP1n7Y14xZT.G78qQ0UN6RHlJiH2y9FiM 9DpjYJuLeOzZ2uONvVHgkdSw- Received: from [24.6.171.68] by web162905.mail.bf1.yahoo.com via HTTP; Wed, 12 Dec 2012 08:51:07 PST X-Rocket-MIMEInfo: 001.001, SSB0aGluayBpdCBpcyByZWFzb25hYmxlIHRvIHB1dCBhIGNvdXBsZSBvZiBsaW5lcwppbiB0aGVyZS4uIGFuZCB0aGVyZSBtdXN0IGJlIGEgY291cGxlIHdlIGNhbiBleHRyYWN0CmZyb20gdGhpcyBodW1vbmdvdXMgdGhyZWFkIGFuZCBpbnNlcnQgOikgV2UgZG8Kbm90IG5lZWQgNyBwYWdlcyBhbmQgaXQgaXMgcXVpdGUgbGlrZWx5IHRoYXQKb3ZlciB0aW1lIHRoaXMgd2lsbCBnZXQgYXBwbGllZCB0byBvdGhlciAKCnVuZm9yZXNlZW4gc2l0dWF0aW9ucyhsaWtlIHdlIGhhdmUgc2VlbiBpbiBvdGhlcgpzb2wBMAEBAQE- X-Mailer: YahooMailWebService/0.8.128.478 References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> Message-ID: <1355331067.395.YahooMailNeo@web162905.mail.bf1.yahoo.com> Date: Wed, 12 Dec 2012 08:51:07 -0800 (PST) From: Chandra Appanna To: Randy Bush , Tony Li In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2143897565-1106197264-1355331067=:395" Cc: idr wg , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Chandra Appanna List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:51:20 -0000 ---2143897565-1106197264-1355331067=:395 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think it is reasonable to put a couple of lines=0Ain there.. and there mu= st be a couple we can extract=0Afrom this humongous thread and insert :) We= do=0Anot need 7 pages and it is quite likely that=0Aover time this will ge= t applied to other =0A=0Aunforeseen situations(like we have seen in other= =0Asolutions many times).=0A=0AMore interesting to me is whether the range = we=0Ahave picked is the right one or we can pick another=0Aone as being dis= cussed.=0A=0AChandra.=0A=0A=0A=0A________________________________=0A From: = Randy Bush =0ATo: Tony Li =0ACc: idr wg ; Robert Raszuk =0ASent: Wednesday, Decembe= r 12, 2012 8:23 AM=0ASubject: Re: [Idr] WGLC on draft-ietf-idr-as-private-r= eservation-00=0A =0A>>> I think Jon should remove any use case examples fro= m the draft as=0A>>> there is no way one could enforce that the new range w= ill _only_ be=0A>>> used in those use cases.=0A>> if there is no documented= motivation for it, then we don't need the=0A>> draft at all.=A0 simplifies= live greatly.=A0 great idea.=A0 ;~>=0A> Then we lard up every draft with m= arketing material.=A0 Is that better?=0A=0Aa use case !=3D marketing materi= al=0A=0Awithout sayng why we want to do something, kinda hard to justify do= ing=0Ait.=A0 in this case, "we want to end run around the IR system for no= =0Areason, just give us the cash and we'll leave."=0A=0Aand robert has been= so vociferous about wanting requirements for other=0Athings that it is har= d to resist hoisting him on his own petard :)=0A=0Arandy=0A________________= _______________________________=0AIdr mailing list=0AIdr@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/idr ---2143897565-1106197264-1355331067=:395 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think it is reasonable to put a couple of lines
in there.. and there must be a couple we can extract
from this humongous thread and insert :) We do
not need 7 pages and it is quite likely that<= /span>
over time this will get applied to other <= br>
unforeseen situations (l= ike we have seen in other
solutions many = times).

More interesting to me is whether the range we
have picked= is the right one or we can pick another
one as being = discussed.

Chandra.

= From: Randy Bush <randy= @psg.com>
To: Tony = Li <tony.li@tony.li>
Cc: idr wg <idr@ietf.org>; Robert Raszuk <robert@raszuk.net&g= t;
Sent: Wednesday, D= ecember 12, 2012 8:23 AM
Subject:= Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
=

>>> I think Jon should remove any use case exam= ples from the draft as
>>> there is no way one could enforce th= at the new range will _only_ be
>>> used in those use cases.>> if there is no documented motivation for it, then we don't need the
>> draft at all.  simplifies live greatly.  great i= dea.  ;~>
> Then we lard up every draft with marketing materi= al.  Is that better?

a use case !=3D marketing material

= without sayng why we want to do something, kinda hard to justify doing
i= t.  in this case, "we want to end run around the IR system for no
r= eason, just give us the cash and we'll leave."

and robert has been s= o vociferous about wanting requirements for other
things that it is hard= to resist hoisting him on his own petard :)

randy
______________= _________________________________
Idr mailing list
Idr@ietf.org
https://ww= w.ietf.org/mailman/listinfo/idr


---2143897565-1106197264-1355331067=:395-- From farmer@umn.edu Wed Dec 12 09:03:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2233C21E80C6 for ; Wed, 12 Dec 2012 09:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xONjPXwha-am for ; Wed, 12 Dec 2012 09:03:35 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE2C21F87EE for ; Wed, 12 Dec 2012 09:03:35 -0800 (PST) Received: from mail-ia0-f198.google.com (mail-ia0-f198.google.com [209.85.210.198]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 12 Dec 2012 11:03:24 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f198.google.com [209.85.210.198] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f198.google.com with SMTP id m10so1887484iam.9 for ; Wed, 12 Dec 2012 09:03:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=JPBrmsh7Awlyhh3kyUu7dNmZe1wfuBcCUtNzAYVTAds=; b=ZCgMtKdpOMolfcuHxDmhdOdtJmP0iXVbDXd9sktWgpjut53a8dXt5M4lqwyIQR/4/Y Eb4VePyVGYIr8aJw+68J684yvTQ21GhAoETwU1lq9mSdpdJNDygdZnytjEd9S5TxDsQN 7TDgT6QOlvKDO3qfd3PI3lbjBrSp0GyPClsebWLMlaszAHDvRGNXhmvi8+lbNB+LcrfZ 17yenEcDL5D48ZlKdrVmWDGxi8+lXSqvCvkPMcsRa3GtgvDKkou2xx7knvBQ7uFaTy5G iDRz096GQtLtIfz2CLedj45QNsJE0s8DilNuuxBukoVwcY7SViEx8rpQRijd598Py5OD r7Xg== Received: by 10.50.0.204 with SMTP id 12mr14247550igg.54.1355331804447; Wed, 12 Dec 2012 09:03:24 -0800 (PST) Received: by 10.50.0.204 with SMTP id 12mr14247543igg.54.1355331804322; Wed, 12 Dec 2012 09:03:24 -0800 (PST) Received: from x-134-84-88-29.nts.umn.edu (x-134-84-88-29.nts.umn.edu. [134.84.88.29]) by mx.google.com with ESMTPS id eu3sm2166712igc.7.2012.12.12.09.03.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 09:03:22 -0800 (PST) Message-ID: <50C8B8D9.4090903@umn.edu> Date: Wed, 12 Dec 2012 11:03:21 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Nick Hilliard References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> In-Reply-To: <50C78C29.3070406@foobar.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkZ7Tf/177Fd235LqmOZ39J+GklfUIYWOFcBghaNuzXSsXY1hhKkRRcGj/n3P+Syls9hH/vFSOqwCL0Y6YVQKflkVRSOuJEdYmnE0TdXriIubg+947sr4s5xk4sUmn0W20YG6R5 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:03:36 -0000 Come on guys, I think the proposed range is more than reasonable, 4,278,190,080 to 4,294,967,294. Yes, the start and end of the range are not really that human or decimal friendly. But, within that you have a range of 10 million ASNs that are relatively human and decimal friendly, 4,280,000,000 to 4,289,999,999. And, if some how that isn't enough, you can pickup another 5 million ASNs with two other adjacent ranges that are only a little less human and decimal friendly, 4,279,000,000 to 4,279,999,999 and 4,290,000,000,000 to 4,294,999,9999. Something more than 16 million ASNs is way more than enough, reserving 300 million or more ASNs, just to start the range at the 4 billion point is just crazy. Get over it. On 12/11/12 13:40 , Nick Hilliard wrote: > On 11/12/2012 19:20, Robert Raszuk wrote: >> Based on number of use cases it seems to me like perhaps we should >> just declare the top most bit in 4 octet AS space as indicator of >> private vs public. > > Excuse me if this sounds atrociously naive, but putting my operator hat on: > > - i'm human and regularly need to parse asns in as-paths > > - i don't naturally count in binary > > - i would really like a set of numbers which I can easily see are private > or public. Decimal alignment would work nicely, both for me and the NOC > staff that are going to be dealing with these numbers on a daily basis. > > - looking at 4278190079 and 4278190080, I simply cannot tell which might be > public and which might be private. This will cause leakage because it will > not be obvious on sight to an operator looking at a bgp aspath whether the > range should be propagated or not #operatorfail > > - unless something drastic has changed recently, I'm not aware of any plans > to assign bitwise masks to ASNs. Consequently bitwise alignment for a > private ASN range is a purely arbitrary construction > > - please change to using a decimal-aligned range. it would make my life > and the lives of many operators a little easier. I suggest 4000000000 or > maybe 4200000000, or something else. Not 4278190080, because that number > means nothing to me > > - otherwise, I love the idea of this draft. Please let us have private > ASNs and lots of them. There are plenty of them to spare in the can. > > thanks, > Nick > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From rraszuk@gmail.com Wed Dec 12 09:11:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48021F88F8 for ; Wed, 12 Dec 2012 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsksRZ7NcI0j for ; Wed, 12 Dec 2012 09:11:48 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2904121F88CA for ; Wed, 12 Dec 2012 09:11:48 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1103268iaz.31 for ; Wed, 12 Dec 2012 09:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/kNxfJYimMxM7+HPBXT/Sv6qkYQF9XMrhH9SutQJutw=; b=WHuB0AV3rxOS4D20/w6S2crCvL0f1FouVqpk48UWoYBaKURsU5WPzsC3+iFR7t2KL7 BBofqUSJbLm4X+2ZaMWF46xVdhtjzNGwR4oTqhCtibjhW+pVWz17lEPWj/EjsW3DhvHd M1Gmp8eOna05griwWI/iv0957oVBKpJ2upWSmS7JIcVvSrWgDp5kXZvhdEdndovABB29 obIkSaaUI1zbMpu0h4g5Is+a6CRqSrF7G7dQtH3l80wAQPAOOg3n9jtj4lXdx0TafKsM uF5ZN1M9sLuo741Yz1/K6kbAlzh8PaD7Br6tFdtVbLG146y86Cc9QPVgAzsjnM2iKzoh +8cA== MIME-Version: 1.0 Received: by 10.50.57.133 with SMTP id i5mr1550816igq.67.1355332306813; Wed, 12 Dec 2012 09:11:46 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 09:11:46 -0800 (PST) In-Reply-To: <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net> References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net> Date: Wed, 12 Dec 2012 18:11:46 +0100 X-Google-Sender-Auth: EApNeKVIBNikDqyy13g2Q-TqCXc Message-ID: From: Robert Raszuk To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , Tony Li Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:11:49 -0000 Yes ... a simple reference to RFC1930/BCP6 should be sufficient. Unless this is no longer BCP and if so let's discuss why not. Regs, R. On Wed, Dec 12, 2012 at 5:34 PM, Warren Kumari wrote: > > On Dec 12, 2012, at 11:07 AM, Tony Li wrote: > >> >> On Dec 12, 2012, at 3:11 AM, Randy Bush wrote: >> >>>> I think Jon should remove any use case examples from the draft as >>>> there is no way one could enforce that the new range will _only_ be >>>> used in those use cases. >>> >>> if there is no documented motivation for it, then we don't need the >>> draft at all. simplifies live greatly. great idea. ;~> >> >> >> Then we lard up every draft with marketing material. Is that better? > > Nope, no-one is suggesting marketing material -- but I think having *some* mention of a use case / justification is needed to readers can evaluate if the idea is worth the time / risk. > > Providing instructions on how to build a little wooden platform with strong spring held back by a bent piece of metal that you can attach bits of curdled dairy makes no sense unless you explain that this will help solve their mouse problem... > > W >> >> Tony >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > -- > Eagles soar but a weasel will never get sucked into a jet engine > > From nick@foobar.org Wed Dec 12 09:53:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5418321E80E2 for ; Wed, 12 Dec 2012 09:53:26 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmhBzx9DCXb4 for ; Wed, 12 Dec 2012 09:53:24 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E88121F8977 for ; Wed, 12 Dec 2012 09:53:23 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBCHpn74049116 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 17:51:49 GMT (envelope-from nick@foobar.org) Message-ID: <50C8C491.4040705@foobar.org> Date: Wed, 12 Dec 2012 17:53:21 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Farmer References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> In-Reply-To: <50C8B8D9.4090903@umn.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:53:26 -0000 On 12/12/2012 17:03, David Farmer wrote: > I think the proposed range is more than reasonable, 4,278,190,080 to > 4,294,967,294. Dave, could you please provide me with a regexp which matches exactly 4278190080 to 4294967294? thanks, Nick From brian.peter.dickson@gmail.com Wed Dec 12 10:16:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA3B1F0CB2 for ; Wed, 12 Dec 2012 10:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p2gfoka91Uz for ; Wed, 12 Dec 2012 10:16:02 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7221F8903 for ; Wed, 12 Dec 2012 10:16:01 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so350211eaa.31 for ; Wed, 12 Dec 2012 10:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cypH+60OmH3ahpc6dNbSsf1W74NJCrFI/bqTRFqJ31k=; b=mSu5oXzEszOo3cm3HWNn8Xhg32GMAyshXK46oPSJKgHHJuVBkX0C3r+HbPe8FQmX+R rtov19xwWWO0Q7oS77cvlxE5B23r1yxeYM6WmHTg8KOVA3RRKVSYnHYtf2LNOIzBo7J4 Hb4FkitWNBxQMwhcdFLfjRSW/wKN3X2opQNlQKq73Qs3n0bhwYRRyZ6lr1YfGIMAfR1g YzCNOGmH9/6o3jg9rLfTLoWUeG4e1OybyYlOvDRQGozWyUGTg1po1EfYv/hZiWKy9HT8 fOkYVYuLfVYwmOSWyiiqNfBEiP6oOBm7uHy3xY5J1rA7gUyCiYaGC4d/LAOE/lDHyvhA S1kA== MIME-Version: 1.0 Received: by 10.14.173.65 with SMTP id u41mr4847046eel.13.1355336161008; Wed, 12 Dec 2012 10:16:01 -0800 (PST) Received: by 10.223.173.199 with HTTP; Wed, 12 Dec 2012 10:16:00 -0800 (PST) In-Reply-To: <50C8C491.4040705@foobar.org> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> Date: Wed, 12 Dec 2012 13:16:00 -0500 Message-ID: From: Brian Dickson To: Nick Hilliard Content-Type: multipart/alternative; boundary=047d7b6226b06d9e3c04d0abca56 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:16:03 -0000 --047d7b6226b06d9e3c04d0abca56 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 12, 2012 at 12:53 PM, Nick Hilliard wrote: > On 12/12/2012 17:03, David Farmer wrote: > > I think the proposed range is more than reasonable, 4,278,190,080 to > > 4,294,967,294. > > Dave, > > could you please provide me with a regexp which matches exactly 4278190080 > to 4294967294? > In as-dot notation, it would be (modulo the regexp language syntax for your CLI): 652[89]?.* | 65[34]??.* | 655[012]?.* | 6553[0-5].* (65280.* through 65535.*) This is every bit as easy (actually a bit easier) to do as a regexp, as the current 16-bit reserved ASNs are: 6451[2-9] | 645[2-9]? | 64[6-9]?? | 65[0-4]?? | 655[0-2]? | 6553[0-5] Of course, the general rule of how many separate regexp elements (separated by |) it would take, can be determined by the odometer rule: o How many carry-over rolls are there in the range? (Those are x99* to (x+1)00*.) o Ignore intermediate rolls between two rolls of increasing length o Obey "price is right" rule - don't use a roll if it takes you "over" the high number o That number, plus (up to) two, if the low number does not end in 0, and/or high number does not end with 9. o So, for the ranges above in as-plain, it is about 15 or so. o Not really horrible, and you only have to build it once. The great thing about constants -- they don't change. (Not sure, but I think the upper range limit should be 2^32-1, or 4294967295.) Brian --047d7b6226b06d9e3c04d0abca56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2012 at 12:53 PM, Nick Hilliard <nick@foobar.org> wrote:
On 12/12/2012 17:03, David Farmer wrote:
> I think the proposed range is more than reasonable, 4,278,190,080 to > 4,294,967,294.

Dave,

could you please provide me with a regexp which matches exactly 4278190080<= br> to 4294967294?

=
In as-dot notation, it would be (modulo the regexp language syntax for= your CLI):

652[89]?.* | 65[34]??.* | 655[012]?.* = | 6553[0-5].*

(65280.* through 65535.*)

This= is every bit as easy (actually a bit easier) to do as a regexp, as the cur= rent 16-bit reserved ASNs are:
6451[2-9] | 645[2-9]? | 64[6-9]?? = | 65[0-4]?? | 655[0-2]? | 6553[0-5]

Of course, the general rule of how many separate regexp= elements (separated by |) it would take,
can be determined by th= e odometer rule:
o =A0How many carry-over rolls are there in the = range?=A0(Those are x99* to (x+1)00*.)
o =A0 =A0 =A0 Ignore intermediate rolls between two rolls of increasin= g length
o =A0 =A0 =A0 Obey "price is right" rule - don= 't use a roll if it takes you "over" the high number
o =A0That number, plus (up to) two, if the low number does not end in 0, = and/or high number does not end with 9.
o =A0So, for the ranges above in as-plain, it is about 15 or so.
=
o =A0Not really horrible, and you only have to build it once. The grea= t thing about constants -- they don't change.

(Not sure, but I think the upper range limit should be 2^32-1, or 429496729= 5.)

Brian
--047d7b6226b06d9e3c04d0abca56-- From neil@domino.org Wed Dec 12 10:22:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800CC21E80BC for ; Wed, 12 Dec 2012 10:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtofVIPWHFac for ; Wed, 12 Dec 2012 10:22:07 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8E21E8086 for ; Wed, 12 Dec 2012 10:22:05 -0800 (PST) Received: from mail83-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 18:22:04 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id 1DAEF2C0245; Wed, 12 Dec 2012 18:22:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.5; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0310HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: PS-3(zzbb2dI98dI1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail83-ch1: domain of domino.org designates 157.56.252.5 as permitted sender) client-ip=157.56.252.5; envelope-from=neil@domino.org; helo=DB3PRD0310HT003.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1355336520921354_25849; Wed, 12 Dec 2012 18:22:00 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id D400C440248; Wed, 12 Dec 2012 18:22:00 +0000 (UTC) Received: from DB3PRD0310HT003.eurprd03.prod.outlook.com (157.56.252.5) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 18:21:59 +0000 Received: from DB3PRD0310MB391.eurprd03.prod.outlook.com ([169.254.6.204]) by DB3PRD0310HT003.eurprd03.prod.outlook.com ([10.255.44.38]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 18:21:57 +0000 From: "Neil J. McRae" To: Jay Borkenhagen , "idr@ietf.org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHN0woYFGWtHywUjEujt618CpD7NpgVhRGA Date: Wed, 12 Dec 2012 18:21:56 +0000 Message-ID: <71D3C995B1A23E4783B8B5149BC5C8D617297E7B@DB3PRD0310MB391.eurprd03.prod.outlook.com> In-Reply-To: <20671.32202.484172.394565@oz.mt.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.44.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F5AFDDE2B3F5548BA00E6EBFCC38CFA@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: domino.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:22:10 -0000 +1 on this. These seems far from something that we should be encouraging. Both Jay and Jared articulate my concerns also. On 05/12/2012 17:00, "Jay Borkenhagen" wrote: >Hi, > >My thoughts on this issue have been best expressed by Jared in his >messages here, including the one repeated below. Likewise, I do not >support advancing this draft. From nick@foobar.org Wed Dec 12 10:28:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6D321F8925 for ; Wed, 12 Dec 2012 10:28: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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C18NMzqpC+X for ; Wed, 12 Dec 2012 10:28:01 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1541521F8920 for ; Wed, 12 Dec 2012 10:28:00 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBCIQPKk049344 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 18:26:25 GMT (envelope-from nick@foobar.org) Message-ID: <50C8CCAD.7060305@foobar.org> Date: Wed, 12 Dec 2012 18:27:57 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Dickson References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:28:02 -0000 On 12/12/2012 18:16, Brian Dickson wrote: > In as-dot We don't use asdot on production networks and for good reasons. That barnyard door has been firmly bolted shut. Nick From jared@puck.nether.net Wed Dec 12 10:34:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA61F0CC2 for ; Wed, 12 Dec 2012 10:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1I3F6+YPIVW for ; Wed, 12 Dec 2012 10:34:53 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0DC1F0CBE for ; Wed, 12 Dec 2012 10:34:52 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCIYXna001886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 13:34:34 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <50C8CCAD.7060305@foobar.org> Date: Wed, 12 Dec 2012 13:34:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: <391A1541-E8D3-45A5-A98E-00EF05D9D5D9@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CCAD.7060305@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 13:34:34 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:34:53 -0000 On Dec 12, 2012, at 1:27 PM, Nick Hilliard wrote: > On 12/12/2012 18:16, Brian Dickson wrote: >> In as-dot > > We don't use asdot on production networks and for good reasons. That > barnyard door has been firmly bolted shut. No kidding. as-dot should go away and be removed from everyones code imho. - Jared From farmer@umn.edu Wed Dec 12 10:36:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33F11F0CC2 for ; Wed, 12 Dec 2012 10:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOqgMUdlxRmk for ; Wed, 12 Dec 2012 10:36:05 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id E0AFD1F0CBE for ; Wed, 12 Dec 2012 10:36:04 -0800 (PST) Received: from mail-oa0-f69.google.com (mail-oa0-f69.google.com [209.85.219.69]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 12 Dec 2012 12:35:54 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f69.google.com [209.85.219.69] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f69.google.com with SMTP id j6so4616359oag.4 for ; Wed, 12 Dec 2012 10:35:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=sYm4AVCmFykaJNCtmdIJfvDSItWWU0h5AT+3AxcZORw=; b=ZSqqcbKtw2iik2wL59zrPgogFWxHAnoBE9xM1Lw2bCb/AkrEBhIXMlEhJg6qXOgb3C YJY41iFD1JRa6/jZmGR9wMv8+07HNzkLr8z+VyVu/ORZZ0TpoTmIvlLeuAwKnIVvmhqp ir4dQ8ckc7bOQ7cHH5P5ZlpUGgwQ892dx/wOaM1Tb3WvPeHEIlRE9ul+VHdeQjzFFcpb 4z8cl3AhltsrvGSiyucwGOLGsbbMQZdiVVGfC/k7qd92PlWxqcZyt7vme+pSjZ2YPhmk 8qXNObZmn77Nh7x/ors82verdDP7PbRFegmPB8o+sZRB1sqAEiDES2PCMkue/1OwyQvO 5Ohg== Received: by 10.50.45.137 with SMTP id n9mr14290498igm.25.1355337353671; Wed, 12 Dec 2012 10:35:53 -0800 (PST) Received: by 10.50.45.137 with SMTP id n9mr14290489igm.25.1355337353538; Wed, 12 Dec 2012 10:35:53 -0800 (PST) Received: from x-134-84-88-29.nts.umn.edu ([2607:ea00:101:2001:302c:a344:9e98:3299]) by mx.google.com with ESMTPS id uj11sm2317363igb.15.2012.12.12.10.35.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 10:35:52 -0800 (PST) Message-ID: <50C8CE86.10103@umn.edu> Date: Wed, 12 Dec 2012 12:35:50 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian Dickson References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlLiD5kU5iFPzUp3F/QhirK1qnuGmM6XK5dHeG33HhD2IWSEG7gSRVtkzGjgVw87C5LCaEfGtTmzQngBV+dj3KZZ8QrtWkHmQ9kIhcsiyRaKl85Rh8o+vQ6HoUIDxLhl79HdxJ3 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:36:07 -0000 On 12/12/12 12:16 , Brian Dickson wrote: > On Wed, Dec 12, 2012 at 12:53 PM, Nick Hilliard > wrote: > > On 12/12/2012 17:03, David Farmer wrote: > > I think the proposed range is more than reasonable, 4,278,190,080 to > > 4,294,967,294. > > Dave, > > could you please provide me with a regexp which matches exactly > 4278190080 > to 4294967294? Nick, why is this any different than creating a regexp that matches the current private ASN range? To me this is a CLI/Config semantics issue and not a standards or allocation issue. Brian, thanks and more below. > In as-dot notation, it would be (modulo the regexp language syntax for > your CLI): > > 652[89]?.* | 65[34]??.* | 655[012]?.* | 6553[0-5].* > > (65280.* through 65535.*) > > This is every bit as easy (actually a bit easier) to do as a regexp, as > the current 16-bit reserved ASNs are: > 6451[2-9] | 645[2-9]? | 64[6-9]?? | 65[0-4]?? | 655[0-2]? | 6553[0-5] > > Of course, the general rule of how many separate regexp elements > (separated by |) it would take, > can be determined by the odometer rule: > o How many carry-over rolls are there in the range? (Those are x99* to > (x+1)00*.) > o Ignore intermediate rolls between two rolls of increasing length > o Obey "price is right" rule - don't use a roll if it takes you > "over" the high number > o That number, plus (up to) two, if the low number does not end in 0, > and/or high number does not end with 9. > o So, for the ranges above in as-plain, it is about 15 or so. > o Not really horrible, and you only have to build it once. The great > thing about constants -- they don't change. > > (Not sure, but I think the upper range limit should be 2^32-1, or > 4294967295.) > > Brian 4294967295 is reserved just like 65535 is reserved and not actually part of the original private ASN range, this is one of the things this draft clarifies from RFC 1930. Quickly, 65535 has special meaning, it is used for well known communities among other things. It is likely that 4294967295 will have similar special meanings and we don't want to make the same mistake RFC 1930 did by including 65535 in the original private range, see previous discussions for more details. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nick@foobar.org Wed Dec 12 10:39:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D3C1F0CC2 for ; Wed, 12 Dec 2012 10:39:50 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsEi+-Ymh4Qp for ; Wed, 12 Dec 2012 10:39:49 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5424E1F0CBE for ; Wed, 12 Dec 2012 10:39:47 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBCIc5IJ049457 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 18:38:05 GMT (envelope-from nick@foobar.org) Message-ID: <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 18:39:37 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Farmer References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> In-Reply-To: <50C8CE86.10103@umn.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:39:50 -0000 On 12/12/2012 18:35, David Farmer wrote: > Nick, why is this any different than creating a regexp that matches the > current private ASN range? well, throw the regexp on the table and let's take a look. Nick From rraszuk@gmail.com Wed Dec 12 10:43:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828A821F8826 for ; Wed, 12 Dec 2012 10:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpYifg6Rkrzv for ; Wed, 12 Dec 2012 10:43:07 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5835021F87C9 for ; Wed, 12 Dec 2012 10:43:07 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so2536686ieb.11 for ; Wed, 12 Dec 2012 10:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5gkhSNnsXw/AumHYtwftb+KMKT/yyiXJBqfIJo/xDpM=; b=amSApp3WyaGqhaK+wcY7eFmQihN4e5c5S8fizYgwlcjqzmVskgafzJFUcI35m66Y7e g7Hs1cmLNyPQ3Be8b4XMa1TQKY9Ub3zEqSZCSzGYLeBHYKBBGJGTrX/4ZgdSkuTqCDye IYub0xDR5ey15MrinqvZq+D2pM/XBNURujGV3d8P1pTwNPXEmp/8a2qEjDk06sDu2SqU CgNLerWklDmzQrxY0C1/Kugq+W2LDPw8z/FTDO8yVFlBGAFsiHNRb+UKHUjV9lnqA1KF 2t7dT8eSUzLGGBZpFw6ZUdLhq5nQkdZ02Qh/5Y4b/CLR6AK/AsqhrX/qoLju6Mld3eGn TOug== MIME-Version: 1.0 Received: by 10.50.150.176 with SMTP id uj16mr14461121igb.38.1355337786192; Wed, 12 Dec 2012 10:43:06 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 10:43:05 -0800 (PST) In-Reply-To: <50C8CF69.4070202@foobar.org> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 19:43:05 +0100 X-Google-Sender-Auth: fisyLPvoSD90eSzPvZo0K4yyA7U Message-ID: From: Robert Raszuk To: Nick Hilliard Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:43:08 -0000 Are you putting this regex in today ? Otherwise the sooner this goes through your vendors will be able to provide you one keyword match for the new private AS range in the policy language of your choice. So I can't quite see what's the point of this regex debate now .... Cheers, R. On Wed, Dec 12, 2012 at 7:39 PM, Nick Hilliard wrote: > On 12/12/2012 18:35, David Farmer wrote: >> Nick, why is this any different than creating a regexp that matches the >> current private ASN range? > > well, throw the regexp on the table and let's take a look. > > Nick From christopher.morrow@gmail.com Wed Dec 12 10:48:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2480221F881A for ; Wed, 12 Dec 2012 10:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex8EusFSPn-K for ; Wed, 12 Dec 2012 10:48:20 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB021E8109 for ; Wed, 12 Dec 2012 10:48:19 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so362937eaa.31 for ; Wed, 12 Dec 2012 10:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/xrrHfvjYdX100D1EInlDzwwTApl7xh/KvDRCKbZ9rE=; b=tEo+2ln9ZNNEoXDz1vdk6Tf1TImHeHgEyVGCfBxZu7HlyNHOGe24a5///jt0i7cn82 ASldGV73yBsMaZ+7X5Zd82brFtkXN7SYfvYJOKSk4qC1MT8eAaSDqrckJzRxNu0fErq1 nbK2iMS/qBOyKoXWrb63FAhXNosOhTXFLjDQcHq/ulMtGB1qFVNHPWQUCPMTXXZb8jfl jeFay/M9PV6BDUWoK9K5OhDFAYfiQTI35mADc1ee3KcmrrjlB5oN3A1M/3toDC3jj3qh TZ6TAP/Xth5LRyO7ogasNaAyp9K7bPD7T1KW/j+pXMkVE6/LcVD5WmapW+9WtalrUC03 dmXA== MIME-Version: 1.0 Received: by 10.14.202.3 with SMTP id c3mr5091375eeo.4.1355338098816; Wed, 12 Dec 2012 10:48:18 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Wed, 12 Dec 2012 10:48:18 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 13:48:18 -0500 X-Google-Sender-Auth: 0nICYV8EUW_ijxPde5aLd1ZL7ds Message-ID: From: Christopher Morrow To: Robert Raszuk Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:48:21 -0000 On Wed, Dec 12, 2012 at 1:43 PM, Robert Raszuk wrote: > Are you putting this regex in today ? > > Otherwise the sooner this goes through your vendors will be able to > provide you one keyword match for the new private AS range in the > policy language of your choice. > > So I can't quite see what's the point of this regex debate now .... to rephrase, I think Robert is asking: "Would you not just ask your vendor to include a macro like: 'PrivateASNGroup' to match on in routing policy language?" seems reasonable... except that my SFO router may not get upgraded at the same as my NYC router, nevermind fast-mover Nick over there who's always happy to load nightly code on his elbonian routers... so do we have to delay usage of this new shiny space until reasonably close to all public bgp speakers upgrade? Or build a mechanism like AS4 required for as2 only realms stuck in the middle of the AS4 world? From brian.peter.dickson@gmail.com Wed Dec 12 10:52:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6551F0CC2 for ; Wed, 12 Dec 2012 10:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rMv8gDayeV0 for ; Wed, 12 Dec 2012 10:52:33 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3E951F0CB2 for ; Wed, 12 Dec 2012 10:52:32 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so740566eek.31 for ; Wed, 12 Dec 2012 10:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BLfzAmjbCy4/mw2f8mkXNS0WJlf1VMf/HIrYNuXYV+E=; b=ofKTrKf6qr6on/Gtibl3b3Vbvzxq+mQdoA48KFWokgLTksEXuT1Jy6q8a9Dk6Vt5YP jT43EJWy3s3VlQa5tZ2d5S3Whb4NikwpMBAdWe9QJPEBwYtsUmfTNYOuooiKoajDIN7+ x4gaa28XlKb5thx4jiZ3KaaMmr684ItwQRAhA64bCO7MX9C5pG97XxJRTAydoHlqO4J4 Ntzvhtxxzx2zqNFlxaRmPbjuaGeylOygdKx6FcAY0gNQbo7fh6BGKvwQL1O0nW6t4Ngp rE6XwDWmxWKLXwArO+BcdxOsyotXW162uK4OfNzBvIJDYkqVoJQI0YzMW1jjdoqfsx4Y OlEw== MIME-Version: 1.0 Received: by 10.14.0.71 with SMTP id 47mr5053374eea.19.1355338350525; Wed, 12 Dec 2012 10:52:30 -0800 (PST) Received: by 10.223.173.199 with HTTP; Wed, 12 Dec 2012 10:52:30 -0800 (PST) In-Reply-To: <50C8C491.4040705@foobar.org> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> Date: Wed, 12 Dec 2012 13:52:30 -0500 Message-ID: From: Brian Dickson To: Nick Hilliard Content-Type: multipart/alternative; boundary=047d7b66f329eefcdb04d0ac4c22 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:52:34 -0000 --047d7b66f329eefcdb04d0ac4c22 Content-Type: text/plain; charset=ISO-8859-1 Okay, in as-plain, here goes: 42781900[8-9]? | \ 4278190[1-9]?? | \ 427819[1-9]??? | \ 4278[2-9]????? | \ 4279?????? | \ 428??????? | \ 429[0-3]?????? | \ 4294[0-8]????? | \ 42949[0-5]???? | \ 429496[0-6]??? | \ 4294967[0-1]?? | \ 42949672[0-8]? | \ 429496729[0-4] In fix-width, and wrapped so one-per-line, and using "hyphen" even for consecutive digits, it lines up nicely (so you can easily verify correctness). Feel free to use the above (and if you like, credit me :-)). Again, not too horrible - 13 terms instead of 5 for as-dot, or 7-8 for current 16-bit. Brian On Wed, Dec 12, 2012 at 12:53 PM, Nick Hilliard wrote: > On 12/12/2012 17:03, David Farmer wrote: > > I think the proposed range is more than reasonable, 4,278,190,080 to > > 4,294,967,294. > > Dave, > > could you please provide me with a regexp which matches exactly 4278190080 > to 4294967294? > > thanks, > Nick > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b66f329eefcdb04d0ac4c22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, in as-plain, here goes:

42781900[8-9]? | \
4278190[1-9]?? | \
427819[1-9]??? | \
4278[2-9]????? | \
<= div>4279?????? | \
<= font face=3D"courier new, monospace">428??????? | \
429[0-3]?????? | \
4294[0-8]????? | \
<= div>42949[0-5]???? | \
429496[0-6]??? | \
4294967[0-1]?? | \
<= font face=3D"courier new, monospace">42949672[0-8]? | \
429496729[0-4]

In fix-width,= and wrapped so one-per-line, and using "hyphen" even for consecu= tive digits, it lines up nicely (so you can easily verify correctness).

Feel free to use the above (and if = you like, credit me :-)).

Again, not to= o horrible - 13 terms instead of 5 for as-dot, or 7-8 for current 16-bit.
Brian

On Wed, Dec 12, 2012 at 12:53 PM, Nick Hilliard <nick@f= oobar.org> wrote:
On 12/12/2012 17:03, David= Farmer wrote:
> I think the proposed range is more than reasonable, 4,278,190,080 to > 4,294,967,294.

Dave,

could you please provide me with a regexp which matches exactly 4278190080<= br> to 4294967294?

thanks,
Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b66f329eefcdb04d0ac4c22-- From rraszuk@gmail.com Wed Dec 12 11:01:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F34621E80EB for ; Wed, 12 Dec 2012 11:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9r3ifhSwRoH for ; Wed, 12 Dec 2012 11:01:20 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D45AF21E80C0 for ; Wed, 12 Dec 2012 11:01:20 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so2547424ieb.31 for ; Wed, 12 Dec 2012 11:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Lif9Sb2nR+Ho8/pBH+zkVtZ1dGWtMNjDyat5ZLB9Tew=; b=r+CdgLp+910U2eX9YM4uoavdcdHQsLG6JAZFgJ/I8nwcnGPIGpgUuH2Ve2LRE/L7U2 AcL/jYjl3gc9Ix+O+Q6bicPYOLdipLEGi2AJ1lQ9GtNJn2xhPhQNQLYR6XeKN7Rn80se k4zlOa8e+fBqz75B7nf+64/ciZF2YJwwom75lHkEWyLes11mAocpCYvDAyJrWBMc2WfA GwtH/JurnloqTEq3ZL94iThOkJ9GvMMT8SxZfPJxuVmMGC4zwNCYlsX137tU4zI5IWQJ L2WZoiLYSVUy6gjlJar5TWuCAoziCiipWqWPGg4pd9kaM9ApX9v72PBkUID8NosrePLo CpSA== MIME-Version: 1.0 Received: by 10.42.52.204 with SMTP id k12mr1675120icg.3.1355338880364; Wed, 12 Dec 2012 11:01:20 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 11:01:20 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 20:01:20 +0100 X-Google-Sender-Auth: dscIvqTLdEC5_VBRxZTB-9p-PRY Message-ID: From: Robert Raszuk To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:01:23 -0000 Chris, Do you expect that folks will use the new space as soon as it is out of RFC editor ? Is there such huge demand for it among ISPs or DSL/FTTH/CABLE operators ;) ? And if so do you really assume those who will use it are so stupid that they would leak those ? I think 4 octet AS itself is not that widely deployed yet. Yes I saw your mail on few two octet private as leaked. And if those are leaked do you think transits should just blindly remove those and replace those private ASes with their own AS ? Note last time I checked it is not easy to remove private-as from AS_PATH other then replacing it with your own when the UPDATE crossed few hops. rgs, r. On Wed, Dec 12, 2012 at 7:48 PM, Christopher Morrow wrote: > On Wed, Dec 12, 2012 at 1:43 PM, Robert Raszuk wrote: >> Are you putting this regex in today ? >> >> Otherwise the sooner this goes through your vendors will be able to >> provide you one keyword match for the new private AS range in the >> policy language of your choice. >> >> So I can't quite see what's the point of this regex debate now .... > > to rephrase, I think Robert is asking: "Would you not just ask your > vendor to include a macro like: 'PrivateASNGroup' to match on in > routing policy language?" > > seems reasonable... except that my SFO router may not get upgraded at > the same as my NYC router, nevermind fast-mover Nick over there who's > always happy to load nightly code on his elbonian routers... so do we > have to delay usage of this new shiny space until reasonably close to > all public bgp speakers upgrade? Or build a mechanism like AS4 > required for as2 only realms stuck in the middle of the AS4 world? From warren@kumari.net Wed Dec 12 11:11:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BCE21E80F4 for ; Wed, 12 Dec 2012 11:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHMS13gGictx for ; Wed, 12 Dec 2012 11:11:21 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F04B21E808D for ; Wed, 12 Dec 2012 11:11:21 -0800 (PST) Received: from [192.168.1.38] (unknown [66.84.81.123]) by vimes.kumari.net (Postfix) with ESMTPSA id A3F061B405DE; Wed, 12 Dec 2012 14:11:20 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 12 Dec 2012 14:11:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> To: Robert Raszuk X-Mailer: Apple Mail (2.1499) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:11:22 -0000 On Dec 12, 2012, at 2:01 PM, Robert Raszuk wrote: > Chris, >=20 > Do you expect that folks will use the new space as soon as it is out > of RFC editor ? Who knows... > Is there such huge demand for it among ISPs or > DSL/FTTH/CABLE operators ;) ? Who know... >=20 > And if so do you really assume those who will use it are so stupid > that they would leak those ? Oh Gods yes. Maybe not stupid, but accidents *will* happen. But, if there is not a "reserved" range, folk are likely to just squat = on some numbers and will be as (or more likely) to leak this=85=20 If this is a reserved range at least external folk can more easily see = that this is a leak, and isn't as likely to end up as path poisoning a = legitimate AS. > I think 4 octet AS itself is not that > widely deployed yet. Yes I saw your mail on few two octet private as > leaked. >=20 > And if those are leaked do you think transits should just blindly > remove those and replace those private ASes with their own AS ? They could just drop them :-P (evil giggle, runs away=85) > Note > last time I checked it is not easy to remove private-as from AS_PATH > other then replacing it with your own when the UPDATE crossed few > hops. >=20 > rgs, > r. >=20 > On Wed, Dec 12, 2012 at 7:48 PM, Christopher Morrow > wrote: >> On Wed, Dec 12, 2012 at 1:43 PM, Robert Raszuk = wrote: >>> Are you putting this regex in today ? >>>=20 >>> Otherwise the sooner this goes through your vendors will be able to >>> provide you one keyword match for the new private AS range in the >>> policy language of your choice. >>>=20 >>> So I can't quite see what's the point of this regex debate now .... >>=20 >> to rephrase, I think Robert is asking: "Would you not just ask your >> vendor to include a macro like: 'PrivateASNGroup' to match on in >> routing policy language?" >>=20 >> seems reasonable... except that my SFO router may not get upgraded at >> the same as my NYC router, nevermind fast-mover Nick over there who's >> always happy to load nightly code on his elbonian routers... so do we >> have to delay usage of this new shiny space until reasonably close to >> all public bgp speakers upgrade? Or build a mechanism like AS4 >> required for as2 only realms stuck in the middle of the AS4 world? > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --=20 A. No Q. Is it sensible to top-post? From christopher.morrow@gmail.com Wed Dec 12 11:25:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDA21E80EB for ; Wed, 12 Dec 2012 11:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2F74UpfpZWS for ; Wed, 12 Dec 2012 11:25:54 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8030221E8088 for ; Wed, 12 Dec 2012 11:25:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so378623eaa.31 for ; Wed, 12 Dec 2012 11:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=36P5IYChBNwrIJwhI13qejVHKfHAWOQwlPSH8jIqCMk=; b=aDkHAEVL/AXv0yYwq4xyuw5TkVWgDdLTkLnxeFM67Z5rJudWdzLM/dF2JU92F24GZD bTnGXq5ZM/k8pwo/jiGzpgKMg2ArV2083lsxS5QaisUtHQA57aGBCkdIU0NmWg4I4vpe Noyr4wcwt3bbs9ppyE6SSZ5wtZF7+6cn1zhUWD6upvlbfdE/C7qCQEsJABxKPWdqf72e BhIAKeLowIh1shlPDnu1wZUqQBNjXvDXxRba32B6HhrmI2CwK0dUUk1XmOGpf2cJcMue 3x7pMsagJXDV2TxqL4+KU3PJp22TSFqGHkGaoHlVJ4LO8JO4Kd7GAZBE4AFAckPfxE/b HBtg== MIME-Version: 1.0 Received: by 10.14.214.132 with SMTP id c4mr5316163eep.18.1355340353667; Wed, 12 Dec 2012 11:25:53 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Wed, 12 Dec 2012 11:25:53 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 14:25:53 -0500 X-Google-Sender-Auth: 19jChBtutqS6XgjhhU0dU5dz0E4 Message-ID: From: Christopher Morrow To: Robert Raszuk , "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:25:55 -0000 +idr back On Wed, Dec 12, 2012 at 2:25 PM, Christopher Morrow wrote: > On Wed, Dec 12, 2012 at 1:57 PM, Robert Raszuk wrote: >> Chris, >> >> Do you expect that folks will use the new space as soon as it is out >> of RFC editor ? Is there such huge demand for it among ISPs or >> DSL/FTTH/CABLE operators ;) ? >> > > the use for the ietf-draft-transition space was ... fast. I'm not sure > how quickly they'll get used, I was simply asking of thought should be > put into the rollout/phased-approach and what happens in a mixed-node > network. > >> And if so do you really assume those who will use it are so stupid >> that they would leak those ? I think 4 octet AS itself is not that >> widely deployed yet. Yes I saw your mail on few two octet private as >> leaked. > > today we see leaks, all the time, of private-as in the path and as > origin... I clipped far back in this thread one example of many > examples I found by just asking routeviews. > > I have no faith that we'll be successful not leaking this time around. > >> >> And if those are leaked do you think transits should just blindly >> remove those and replace those private ASes with their own AS ? Note > > midstream you can't (today) replace (what would you replace it > with?)... so no, I don't think the transits will replace, I also don't > think they'll filter the routes (since they don't today, reliably). > >> last time I checked it is not easy to remove private-as from AS_PATH >> other then replacing it with your own when the UPDATE crossed few >> hops. > > agreed, uniess it's the immediate asn[0] or set of immediate asns[1] I > think you're out of luck replacing. > > -chris > > [0]: [] 65543 > [1]: [] 65543 65542 65541 > >> >> rgs, >> r. >> >>> On Wed, Dec 12, 2012 at 7:48 PM, Christopher Morrow wrote: >>> On Wed, Dec 12, 2012 at 1:43 PM, Robert Raszuk wrote: >>>> Are you putting this regex in today ? >>>> >>>> Otherwise the sooner this goes through your vendors will be able to >>>> provide you one keyword match for the new private AS range in the >>>> policy language of your choice. >>>> >>>> So I can't quite see what's the point of this regex debate now .... >>> >>> to rephrase, I think Robert is asking: "Would you not just ask your >>> vendor to include a macro like: 'PrivateASNGroup' to match on in >>> routing policy language?" >>> >>> seems reasonable... except that my SFO router may not get upgraded at >>> the same as my NYC router, nevermind fast-mover Nick over there who's >>> always happy to load nightly code on his elbonian routers... so do we >>> have to delay usage of this new shiny space until reasonably close to >>> all public bgp speakers upgrade? Or build a mechanism like AS4 >>> required for as2 only realms stuck in the middle of the AS4 world? From jared@puck.nether.net Wed Dec 12 11:38:41 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF7621E80F4 for ; Wed, 12 Dec 2012 11:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRtFwO6AzjrX for ; Wed, 12 Dec 2012 11:38:41 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 02D3521E808D for ; Wed, 12 Dec 2012 11:38:40 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCJcbgY007852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 14:38:39 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jared Mauch In-Reply-To: Date: Wed, 12 Dec 2012 14:38:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <10CFF9F7-1D87-4D6E-8CB5-75A4584B3E74@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> To: Warren Kumari X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 14:38:39 -0500 (EST) Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:38:41 -0000 On Dec 12, 2012, at 2:11 PM, Warren Kumari wrote: >>=20 >> And if so do you really assume those who will use it are so stupid >> that they would leak those ? >=20 > Oh Gods yes. Maybe not stupid, but accidents *will* happen. >=20 > But, if there is not a "reserved" range, folk are likely to just squat = on some numbers and will be as (or more likely) to leak this=85=20 >=20 > If this is a reserved range at least external folk can more easily see = that this is a leak, and isn't as likely to end up as path poisoning a = legitimate AS. Yes, they will leak them. They will be persistent, and most BGP users = aren't concerned about the impact. Take this currently visible global route: 2800:130::/32 12956 19169 27947 65001 27820 I From rraszuk@gmail.com Wed Dec 12 11:41:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7F21E810D for ; Wed, 12 Dec 2012 11:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECf8c5lgzMIS for ; Wed, 12 Dec 2012 11:41:31 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id C831821E808D for ; Wed, 12 Dec 2012 11:41:31 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so2637075iea.36 for ; Wed, 12 Dec 2012 11:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yg23aJRUV0l2giZZJPEILiV3u0/r/MmdO3bh3PSmMa4=; b=qQGRsLe8Mg4e62VBdQ7hZavFOGi1JwNXAFaOpXeYbvh7krr1aUXZDNwnHAT8x2cc+k vE2vBMSBIZFuc0Lq7NnDt24ayXZcV7tqPqN6acm6XA/xl9OW4/eL+CpEpX9U8dJKZSDc xui5HjDCaOWmHUzfBs3pLWeQpqCs9cOL5Wo2Du4F6tY0Lu6fsPq9NfJekQQjvpPpt/5W Hg0FyqRFM+z9C9dBsHunykxQ/dwco3hH7QH97aUCCkCFeMzZq33Ge7QL8vw0ygrUxSK+ jK2MMB58IUpDYeyfRU87wHqPGMJZVCBUm4p+7n6xynOcGY216PnimDQYCWORm2eNM6yx C8kQ== MIME-Version: 1.0 Received: by 10.50.150.167 with SMTP id uj7mr14632294igb.33.1355341290685; Wed, 12 Dec 2012 11:41:30 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 11:41:30 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 20:41:30 +0100 X-Google-Sender-Auth: o4PJPd2wnvhFnuRAhCC_O5Z3BEg Message-ID: From: Robert Raszuk To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:41:33 -0000 >> midstream you can't (today) replace (what would you replace it with?). You can if you would really need to replace any string in the AS_PATH with your own AS. I spec-ed this RPL enhancement based on the real customer demand. Example: http://goo.gl/xVToJ r. From rraszuk@gmail.com Wed Dec 12 11:44:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6C221E8110 for ; Wed, 12 Dec 2012 11:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5S6oTwa5FcZ for ; Wed, 12 Dec 2012 11:44:14 -0800 (PST) Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by ietfa.amsl.com (Postfix) with ESMTP id D644D21E810B for ; Wed, 12 Dec 2012 11:44:13 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id y25so1254589iay.33 for ; Wed, 12 Dec 2012 11:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e9bwDBbvBTKVJelgcvtyDj7ER7g3oU+CpHiB5Xchm3o=; b=l9dHqbvXsEv1nZnKir51ycaTrDp7WoxXJ/PgJQ3H6ElLTDZNDsVjOYx7drUMVbBRW0 I3sccw7y4foJx38gVo2CYjCd1CPYezfD9xwhSXF5s3qH754Dg1+G+oeWtuE1c+6HWKST 6d0zEoZMmsonC7INyj+r92hCpa0pVQQ3tbrEq486VyOxl0lawzBE6pGr4chhiTUjV6h5 ZjGF/Ce4R5mcTp5Rbjn7Bl0KoWY8/n/yubDV0mgAVvtVFS7AwgO2A1FWx0W7Liwv3+od 4gVQzG+fIJ9Ylhp9hvdQzfzdcyTqMEfogrE3vs3EuDMPFa4adj150uZoKhbE+MC5Kr1U 7v8Q== MIME-Version: 1.0 Received: by 10.50.170.66 with SMTP id ak2mr14660522igc.38.1355341453397; Wed, 12 Dec 2012 11:44:13 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 11:44:13 -0800 (PST) In-Reply-To: <10CFF9F7-1D87-4D6E-8CB5-75A4584B3E74@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> <10CFF9F7-1D87-4D6E-8CB5-75A4584B3E74@puck.nether.net> Date: Wed, 12 Dec 2012 20:44:13 +0100 X-Google-Sender-Auth: S4ma5iyxhM7DiWnLIHX4uwe8Cgo Message-ID: From: Robert Raszuk To: Jared Mauch Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:44:15 -0000 Jared, > Take this currently visible global route: > > 2800:130::/32 12956 19169 27947 65001 27820 I True. So this prefix will be dropped by anyone who has private AS of 65001. Is this a bug or a feature ? Don't you think that those who use private AS just default out anyway ? r. From jared@puck.nether.net Wed Dec 12 11:51:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012E321E810B for ; Wed, 12 Dec 2012 11:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrffqW8pRYAM for ; Wed, 12 Dec 2012 11:51:26 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id AC60E21E810D for ; Wed, 12 Dec 2012 11:51:24 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCJpMJP008931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 14:51:23 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Wed, 12 Dec 2012 14:51:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> <10CFF9F7-! 1D87-4D6E-8CB5-75A4584B3E74@puck.nether.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 14:51:23 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:51:40 -0000 On Dec 12, 2012, at 2:44 PM, Robert Raszuk wrote: > Jared, >=20 >> Take this currently visible global route: >>=20 >> 2800:130::/32 12956 19169 27947 65001 27820 I >=20 > True. >=20 > So this prefix will be dropped by anyone who has private AS of 65001. >=20 > Is this a bug or a feature ? Don't you think that those who use > private AS just default out anyway ? It's a multi-use protocol, so that view is perfectly "valid" for = someone, but likely not intended to be globally viewable. Ideally the vendors along the path would not default advert their full = table to someone without an explicit policy configured. They would also = make some of these settings more default.. remove-private should be the = default behavior for this new space. We should make folks be more conservative in their default behaviors = here.. I do wish those that still default flood their full table would = make that change. I would attempt to influence them, but they've made = it challenging to purchase from them due to other gaps in capability... - Jared= From christopher.morrow@gmail.com Wed Dec 12 12:22:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59B71F0CCF for ; Wed, 12 Dec 2012 12:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX-qqNP7Iz8q for ; Wed, 12 Dec 2012 12:22:03 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE9F81F0CC7 for ; Wed, 12 Dec 2012 12:22:02 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so802006eek.31 for ; Wed, 12 Dec 2012 12:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yf2vNZuJT31lQ2oU7QMDPmRQvJTywAbcWtYxyAEGk1g=; b=YONdw+4Jg3/P8LNj3UFWi+1DkeTPnWnvpztP/D2ySTdzD0UIW1BZazRMD7Rxum43hA AxMInxHDp16/SemxTSjL02W+QXNprpn6/rQTbapXHj5GFuETtJj/zpN+Csmm68WSZh1F LlyT7tcPgtN1M9WB6vTuI+YC73PqvcdeTeR/vo3dJnVfjkTCPd6srbLCo3cPLDcbVhmZ 7ZFdpPjU64mgI/TJFyIgqGQnS1DNDsKl41VN1S66z9ExNx9iI8G+3veEfUfxpcI96Ea4 JYbyvg1xb0U+xlzztJrc2RRT4l6yQ5pSpyTkEzLe+KUtqwIof8wNuy8gaKKqnE9LocgK 5mHA== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr5724015eef.25.1355343721938; Wed, 12 Dec 2012 12:22:01 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Wed, 12 Dec 2012 12:22:01 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 15:22:01 -0500 X-Google-Sender-Auth: dYGMCzJbrklcabTzKuVMYekN4pU Message-ID: From: Christopher Morrow To: Jared Mauch Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:22:12 -0000 On Wed, Dec 12, 2012 at 2:51 PM, Jared Mauch wrote: > Ideally the vendors along the path would not default advert their full table to someone without an explicit policy configured. They would also make some of these settings more default.. remove-private should be the default behavior for this new space. is default-remove-private really the right thing to do? for some 'internet connected' routers probably, for everyone? not likely. From jared@puck.nether.net Wed Dec 12 13:04:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E500C21E8034 for ; Wed, 12 Dec 2012 13:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inwKLytgflRy for ; Wed, 12 Dec 2012 13:04:05 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 675C421F8878 for ; Wed, 12 Dec 2012 13:04:05 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCL3lPm019262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 16:03:48 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Wed, 12 Dec 2012 16:03:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 16:03:49 -0500 (EST) Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:04:06 -0000 On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: > On Wed, Dec 12, 2012 at 2:51 PM, Jared Mauch = wrote: >> Ideally the vendors along the path would not default advert their = full table to someone without an explicit policy configured. They would = also make some of these settings more default.. remove-private should be = the default behavior for this new space. >=20 > is default-remove-private really the right thing to do? for some > 'internet connected' routers probably, for everyone? not likely. They can configure their policy to override the default behavior. The problem I see is implementations that a) default sending all best-path routes to peers. (at least one vendor = has this as a major problem). b) leak "private" space without explicit configurations to enable said = action. - Jared= From christopher.morrow@gmail.com Wed Dec 12 13:07:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E0F21E8034 for ; Wed, 12 Dec 2012 13:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVDG3JDga9q1 for ; Wed, 12 Dec 2012 13:07:03 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63C2721F8925 for ; Wed, 12 Dec 2012 13:07:03 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so832160eek.31 for ; Wed, 12 Dec 2012 13:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5isZGAUs9w2i9n2yMKkvWqopwKjHAiPTQUjUde72K38=; b=EvWOurkMCqRzGPB2aiRaSpFIxEVGtlYC5YDiXUrFKbp2w0wt9ccZ9/AiUWuJyuTiFp a4RnVjhqm2Khrh6XAlGBouVo7GA99poDG4EL1LvFhzfw4zGipinAHwMWw3hR0kYPbaQK tTuRLbNy3f8AMyoKMQ4Wv4JBqp+LqRX0PoOSJ8gliYuyKfYzYc5hMaAYmBhUX8F8J9BY jzPyRqKiaKhxhnowX5q+DiqNNEiKgWaT8XZSNyG8R9ryLaYWLzRe/z2+CrWcQ03vu4wc BYeRC4ChdifEFO/rPZm+ZuGU8EmXg95AW2/Bd7fEBkJG9/MNOsLi9ARLsxlphaStxR3M yZdw== MIME-Version: 1.0 Received: by 10.14.202.3 with SMTP id c3mr6020168eeo.4.1355346422584; Wed, 12 Dec 2012 13:07:02 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Wed, 12 Dec 2012 13:07:02 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> Date: Wed, 12 Dec 2012 16:07:02 -0500 X-Google-Sender-Auth: x5iwXaf97C3VFDm1x7K0PNl60nU Message-ID: From: Christopher Morrow To: Jared Mauch Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:07:04 -0000 On Wed, Dec 12, 2012 at 4:03 PM, Jared Mauch wrote: > > On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: > >> On Wed, Dec 12, 2012 at 2:51 PM, Jared Mauch wrote: >>> Ideally the vendors along the path would not default advert their full table to someone without an explicit policy configured. They would also make some of these settings more default.. remove-private should be the default behavior for this new space. >> >> is default-remove-private really the right thing to do? for some >> 'internet connected' routers probably, for everyone? not likely. > > They can configure their policy to override the default behavior. sure: "no ip directed broadcast" > The problem I see is implementations that > > a) default sending all best-path routes to peers. (at least one vendor has this as a major problem). ok, fine thing to ask the vendors to fix. > b) leak "private" space without explicit configurations to enable said action. 'what is private' ? -chris From nick@foobar.org Wed Dec 12 13:08:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99EB21E8037 for ; Wed, 12 Dec 2012 13:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Y+0W5RZVG4 for ; Wed, 12 Dec 2012 13:08:42 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id F255521E8034 for ; Wed, 12 Dec 2012 13:08:41 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:79d2:636d:2532:9d2f]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBCL72tV050581 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 21:07:08 GMT (envelope-from nick@foobar.org) Message-ID: <50C8F252.4000706@foobar.org> Date: Wed, 12 Dec 2012 21:08:34 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Dickson References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:08:42 -0000 On 12/12/2012 18:52, Brian Dickson wrote: > Okay, in as-plain, here goes: ah, thanks - that's saved me the bother of sitting down and exercising the grey matter of an evening. In fact you can optimise it by taking characters out from the front, which I've done below. On some systems with recursive RE libs, you can do more of this and shorter the RE string. On other RE libs which support specifying the atom instance count, you can replace sequences of dots with squiggly braces, but that won't help much with readability and it's not portable across all of the various vendor regexp libs (and it will just make it look like modem-induced line-noise). I've taken out the 42 and cut-n-pasted it into a cisco router, and it now looks like this: > ip as-path access-list 499 permit _42(781900[8-9].|78190[1-9]..|7819[1-9]...|78[2-9].....|79......|8.......|9[0-3]......|94[0-8].....|949[0-5]....|9496[0-6]...|94967[0-1]..|949672[0-8].|9496729[0-4])_ It will be similar but not the same on other vendors. If we aim for a decimal-aligned system, in the worst case this is reduced to: > ip as-path access-list 499 permit _XXX......._ ... for some simple numeric value of XXX. I know which regular expression I'd prefer to deal with. Nick From warren@kumari.net Wed Dec 12 13:14:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6D921F8973 for ; Wed, 12 Dec 2012 13:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8XlFNIGAU38 for ; Wed, 12 Dec 2012 13:14:06 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BD521F896C for ; Wed, 12 Dec 2012 13:14:06 -0800 (PST) Received: from [192.168.1.38] (unknown [66.84.81.123]) by vimes.kumari.net (Postfix) with ESMTPSA id 103871B405E4; Wed, 12 Dec 2012 16:14:06 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <50C8F252.4000706@foobar.org> Date: Wed, 12 Dec 2012 16:14:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5CB6FA-F5B6-4627-99A9-8E14251B5460@kumari.net> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8F252.4000706@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1499) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:14:08 -0000 On Dec 12, 2012, at 4:08 PM, Nick Hilliard wrote: > On 12/12/2012 18:52, Brian Dickson wrote: >> Okay, in as-plain, here goes: >=20 > ah, thanks - that's saved me the bother of sitting down and exercising = the > grey matter of an evening. In fact you can optimise it by taking > characters out from the front, which I've done below. On some systems = with > recursive RE libs, you can do more of this and shorter the RE string. = On > other RE libs which support specifying the atom instance count, you = can > replace sequences of dots with squiggly braces, but that won't help = much > with readability and it's not portable across all of the various = vendor > regexp libs (and it will just make it look like modem-induced = line-noise). > I've taken out the 42 and cut-n-pasted it into a cisco router, and it = now > looks like this: >=20 >> ip as-path access-list 499 permit = _42(781900[8-9].|78190[1-9]..|7819[1-9]...|78[2-9].....|79......|8.......|= 9[0-3]......|94[0-8].....|949[0-5]....|9496[0-6]...|94967[0-1]..|949672[0-= 8].|9496729[0-4])_ >=20 > It will be similar but not the same on other vendors. >=20 > If we aim for a decimal-aligned system, in the worst case this is = reduced to: >=20 >> ip as-path access-list 499 permit _XXX......._ >=20 > ... for some simple numeric value of XXX. >=20 > I know which regular expression I'd prefer to deal with. Sure, but *you* have the ability to use (by policy) 4,280,000,000 to = 4,289,999,999 within your network and then your regexp becomes: ip as-path access-list 499 permit _428...=85._ Personally I think that human readable is much more friendly, but I can = see both sides of the argument=85 Actually, for yet more fun in this thread, the draft could suggest = reserving on the bit boundary, and then another reservation within that = that folk would actually allocate from (or just recommendations that = folk start counting at 4,280,000,000). Runs away again, giggling even louder=85=20 W >=20 > Nick >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 -- "Let's just say that if complete and utter chaos was lightning, he'd be = the sort to stand on a hilltop in a thunderstorm wearing wet copper = armour and shouting 'All gods are bastards'." -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of = Magic) From jared@puck.nether.net Wed Dec 12 13:29:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2867821E8045 for ; Wed, 12 Dec 2012 13:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhqFHkCQwLPg for ; Wed, 12 Dec 2012 13:29:30 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 794B021E8034 for ; Wed, 12 Dec 2012 13:29:30 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCLTNYq022363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 16:29:23 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Wed, 12 Dec 2012 16:29:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 16:29:23 -0500 (EST) Cc: IETF IDR Working Group , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:29:39 -0000 On Dec 12, 2012, at 4:07 PM, Christopher Morrow wrote: >> b) leak "private" space without explicit configurations to enable = said action. >=20 > 'what is private' ? Today? The range in rfc1930 for ASNs, but perhaps rfc1930+ the subject = draft. I believe it should perhaps also cover the IP space, but you may object = to that premise as a default behavior. - Jared From nick@foobar.org Wed Dec 12 13:40:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A492921F8975 for ; Wed, 12 Dec 2012 13:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8WEBOygQokB for ; Wed, 12 Dec 2012 13:40:30 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61821F8908 for ; Wed, 12 Dec 2012 13:40:27 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:79d2:636d:2532:9d2f]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBCLceHk050791 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 21:38:45 GMT (envelope-from nick@foobar.org) Message-ID: <50C8F9BC.6010700@foobar.org> Date: Wed, 12 Dec 2012 21:40:12 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Robert Raszuk References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 21:40:31 -0000 On 12/12/2012 18:43, Robert Raszuk wrote: > Are you putting this regex in today ? > > Otherwise the sooner this goes through your vendors will be able to > provide you one keyword match for the new private AS range in the > policy language of your choice. I think your time spent with commit access to XR has given you a overly rosy world view on how easy it is to get feature requests implemented :-) My experience with vendor feature requests varies from abysmally poor to don't-even-bother-asking, which I guess is what happens when your annual L2/L3 capex budget is less than $100m. But as Chris mentioned, we all run vendor heterogeneous networks these days, never mind running different code versions from the same vendor, or even different operating systems from the same vendor. How do we handle consistent policy during a migration period? I have no idea, unless you're ok with crazy mad REs like the one posted earlier (which I'm not because I need to debug this sort of thing). Nick From farmer@umn.edu Wed Dec 12 14:12:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5D021E8055 for ; Wed, 12 Dec 2012 14:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL6-HugpuHwq for ; Wed, 12 Dec 2012 14:12:01 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20B21E804B for ; Wed, 12 Dec 2012 14:12:01 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 12 Dec 2012 16:11:53 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id c10so5391250ieb.1 for ; Wed, 12 Dec 2012 14:11:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=6kU80UWSDp/+Xq+s9qWQkQmCaaVyrilm41OtDcKbQYI=; b=GjHs7y/oi29rxnwnRm3jDh/z+DcguXGHJ+v1U4tNgu0tF++Dz/E5bjDZaN+O0dXeBC HdzAf6KL8zyiH8jB7E9AOmNQJ63Yps9kuj8lQofLenPhXpc9CDHHbYJE1lCP7M2fY+Vx RWQnydgUgMAkQJKfUZZTtlSDh3gW9200nxbbJwO+Fwnsf5UlGkklEX+bXQS+6k7OP5sr LJCZOunFsJXzMSmX4X19ahkkFi0FO+VMu+IYexekGLV/OMOGdKMxG8q5S6RG75DRm+/I 6RPWco9SIrl3WgDxrIpllj740bagYgwUOUuCCnpiAiuS5Anz1JdKTp5L8GgFhh43KC/s Jc2A== Received: by 10.50.76.195 with SMTP id m3mr14972030igw.64.1355350313084; Wed, 12 Dec 2012 14:11:53 -0800 (PST) Received: by 10.50.76.195 with SMTP id m3mr14972017igw.64.1355350312813; Wed, 12 Dec 2012 14:11:52 -0800 (PST) Received: from x-134-84-88-29.nts.umn.edu ([2607:ea00:101:2001:1d22:1466:26ae:9e31]) by mx.google.com with ESMTPS id vq4sm2739727igb.10.2012.12.12.14.11.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 14:11:52 -0800 (PST) Message-ID: <50C90126.3010104@umn.edu> Date: Wed, 12 Dec 2012 16:11:50 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian Dickson References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnreJoPq0zlTspTqlXzRLVH00QpLNDKFw+E2+dEurad0yDc46GzKYQkUjFK2SiZhhdNCTF5sunGBcr5RYA5LiByw/uKsYAoKpgVH5yr7IBDtT//1wdemfJmApTLdCXB7lzp+Ugj Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:12:06 -0000 On 12/12/12 12:52 , Brian Dickson wrote: > Okay, in as-plain, here goes: > > 42781900[8-9]? | \ > 4278190[1-9]?? | \ > 427819[1-9]??? | \ > 4278[2-9]????? | \ > 4279?????? | \ > 428??????? | \ Just a thought, couldn't you eliminate the rest with the following shortcut; 429??????? Yes, it would match 4294967295 which is not part of the range, but it is reserved for other reasons, and shouldn't be seen in the wild at all, Big I or little i. And, would match ASNs bigger than 2^32 which can't exist. So unless some implemented there regexp library in a vary weird way, you are down to 7 lines. Yes, its cheating a little, but so what. > 429[0-3]?????? | \ > 4294[0-8]????? | \ > 42949[0-5]???? | \ > 429496[0-6]??? | \ > 4294967[0-1]?? | \ > 42949672[0-8]? | \ > 429496729[0-4] > > In fix-width, and wrapped so one-per-line, and using "hyphen" even for > consecutive digits, it lines up nicely (so you can easily verify > correctness). > > Feel free to use the above (and if you like, credit me :-)). > > Again, not too horrible - 13 terms instead of 5 for as-dot, or 7-8 for > current 16-bit. So with the shortcut above, you are back to more or less the same length as the regexp for the original private ASN block. Throwing some some version of this discussion is as an appendix might not be a bad idea, including a regexp for the original private ASN block too. And, just maybe that could help cut down on some of the leaking. I can't see how it could possibly make leaking any worse. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nick@foobar.org Wed Dec 12 14:22:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903FA21E8054 for ; Wed, 12 Dec 2012 14:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj81zQkDJ3Cm for ; Wed, 12 Dec 2012 14:22:32 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0342821E8044 for ; Wed, 12 Dec 2012 14:22:31 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:79d2:636d:2532:9d2f]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBCMKofc051022 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 22:20:57 GMT (envelope-from nick@foobar.org) Message-ID: <50C9039E.1050104@foobar.org> Date: Wed, 12 Dec 2012 22:22:22 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Farmer References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> In-Reply-To: <50C8B8D9.4090903@umn.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:22:33 -0000 On 12/12/2012 17:03, David Farmer wrote: > Come on guys, > > I think the proposed range is more than reasonable, 4,278,190,080 to > 4,294,967,294. Yes, the start and end of the range are not really that > human or decimal friendly. > > And, if some how that isn't enough, you can pickup another 5 million > ASNs with two other adjacent ranges that are only a little less human > and decimal friendly, 4,279,000,000 to 4,279,999,999 and > 4,290,000,000,000 to 4,294,999,9999. > > Something more than 16 million ASNs is way more than enough, reserving > 300 million or more ASNs, just to start the range at the 4 billion point > is just crazy. this isn't about what particular subset you could choose to use from this allocation, and I honestly don't care about the size of the proposed allocation as long as it's large enough to deal with really pathological lab cases. It's about vendors and operators and everyone else tending to align their choice of private ASN to the boundary of the formal allocation range, because that's what people naturally do when presented with a big pile of numbers: they select the first in the range, or maybe the last. It's also about making the entire range visually easy for operators to handle so that private ASNs are immediately identifiable as such. As a side effect, this will make it much easier to write regexps to handle these ASN ranges, because the tools we have for mucking around with AS paths tend to involve RE engines. It would be operationally more sensible to use a much lower range and suffer fewer ASNs as a result. This is because operational people like me routinely need to visually inspect ASNs in as-paths, and it's a whole lot easier to distinguish between a 5- or 6-digit numbers than 10 digit numbers. If the draft ends up with 10 digit private ASNs, operational people will end up with with a whole pile of "wtf were they _thinking_?" and hair pulling, as they try to figure out whether they've just typed eight 0s or nine, or made a mistake in position 4, 5 or 6. We're human, not machines and things like this make a difference. As a side issue, we actually don't really need 2^24 private ASNs, regardless of how complicated anyone's lab network is, but that is a less important issue. I'd like to formally propose a smaller range, decimal aligned, from a lower starting point. There are several large blocks free in various areas of the IANA pool, any of which might be suitable for an allocation for private use: www.iana.org/assignments/as-numbers/ >From a subjective point of view, I take this position: Bit-aligned 4278190080 to 4294967294: pros: - out of the way of RIR assignments cons: - impossible to recognise visually in operational context - the bounding regexp is ridiculous - the numbers are large enough that they will attract typos - complete mouthful and impossible to transmit down e.g. phone, across the room, etc (yes, we shout ASNs across the room, and sometimes even talk to customers). Low, decimal-aligned range: pros: - immediately identifiable as private in operational context - out of the way of RIR assignments - trivial bounding regexp - smaller numbers mean fewer typos cons: - ? 900000 to 999999 would work fine for me. I'd be even happier with 90000-99999. In fact I'd be really pleased with the lower range because I can relate to 5 digit numbers even more easily than 6 digit numbers - but perhaps 10k private ASNs may not be enough for crazy large lab models. > Get over it. What we need to get over is this idea that bit alignment is relevant to asn allocation policy. It simply isn't. This is an operational draft. Please let's request a range which works well for operators. Nick From jrmitche@puck.nether.net Wed Dec 12 14:46:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6F01F0CB9 for ; Wed, 12 Dec 2012 14:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I9KG+t6cQ6B for ; Wed, 12 Dec 2012 14:46:44 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 056CE1F0409 for ; Wed, 12 Dec 2012 14:46:43 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCMkh14031044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 17:46:43 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBCMkgkM031043; Wed, 12 Dec 2012 17:46:42 -0500 Date: Wed, 12 Dec 2012 17:46:42 -0500 From: Jon Mitchell To: Warren Kumari Message-ID: <20121212224642.GA29400@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 17:46:43 -0500 (EST) Cc: idr wg , Tony Li , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 22:46:45 -0000 To those asking for justification - RFC1930 is not replaced by this draft, only updated. This draft adds the following as justification for the 2nd range: The limited size of the current range of private use ASNs has led to the re-use of private use ASNs within a single organization, requiring the use of a number of implementation specific features that manipulate the AS_PATH or remove AS_PATH based loop prevention described in Section 9 of [RFC4271]. These workarounds have increased the operational complexity of the networks since the implementations of these functions vary and are not defined in existing BGP standards. < another paragraph justifies that the total amount of space is larger, and asns are not a scarce resource > If the first paragraph of the draft, by mentioning how BGP use has increased in a number of networks confuses folks into thinking they are justifying private ASNs for a specific use case, I've already said I'm happy to make minor edits. Since private ASNs are (w/o collectable data a total swag) deployed on several orders of magnitude higher numbers of devices than public ASNs and are used in many different ways, it seems to me focusing on any particular use case is a bit silly and short sighted give the justification above handles all use cases for the 2nd range and just creates fodder for those who want to debate the usefulness from an academic standpoint often while deploying the existing range in segments of their own networks. Even if we were to delineate a wide number of use cases for private asns in DCs, large Enterprise private networks, labs, etc... (which I don't think we have very good representation in IETF to fully expound upon), do we think that somehow this would bound folks or somehow fix any Internet leaking of the existing or new ranges? Jon On Wed, Dec 12, 2012 at 11:34:18AM -0500, Warren Kumari wrote: > > On Dec 12, 2012, at 11:07 AM, Tony Li wrote: > > > > > On Dec 12, 2012, at 3:11 AM, Randy Bush wrote: > > > >>> I think Jon should remove any use case examples from the draft as > >>> there is no way one could enforce that the new range will _only_ be > >>> used in those use cases. > >> > >> if there is no documented motivation for it, then we don't need the > >> draft at all. simplifies live greatly. great idea. ;~> > > > > > > Then we lard up every draft with marketing material. Is that better? > > Nope, no-one is suggesting marketing material -- but I think having *some* mention of a use case / justification is needed to readers can evaluate if the idea is worth the time / risk. > > Providing instructions on how to build a little wooden platform with strong spring held back by a bent piece of metal that you can attach bits of curdled dairy makes no sense unless you explain that this will help solve their mouse problem... > > W > > > > Tony > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > -- > Eagles soar but a weasel will never get sucked into a jet engine > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Wed Dec 12 15:17:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599821E805F for ; Wed, 12 Dec 2012 15:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYJXz-ktVR5d for ; Wed, 12 Dec 2012 15:17:36 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0669E21E808B for ; Wed, 12 Dec 2012 15:17:35 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3013699ieb.31 for ; Wed, 12 Dec 2012 15:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ZxTc91W7IGn83D3hsdJ9FI8qMSZcyjEAQi9aR6nH0uI=; b=lXBFunPMNGwEZnkmSl33K4+BOZsusOgKWfSpqcxty8kCboquVNWpzj4mOrXhfUCxxY 13TaXrk80swtV688OoUO7FyQpjRmdjw8NBEXKYxtNWJ1mETuBr3cwIiuDILQXehTTJOF 67O9dWC0WgAgwI0XvAJdmZY8zW9nvIE3W/k+t387s2+x57iuS8+5jQyGDdkCMFL2WLOV hurzQHs4GUEBYoEub7H4eR7LY4aqo6lammJzQoh5lEPGV7Ke9R+vgW6k07xBbBbfWtan NhE8NBAwMwrZAJpS6cvKaJ0hno9SKNkhqgN8RcKUf+58K/HRipi58oXZenkShdw/cXyQ lDkA== MIME-Version: 1.0 Received: by 10.50.13.162 with SMTP id i2mr2584931igc.38.1355354255493; Wed, 12 Dec 2012 15:17:35 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 15:17:35 -0800 (PST) Date: Thu, 13 Dec 2012 00:17:35 +0100 X-Google-Sender-Auth: XWn-iWB2_MxYDrby1jbtuqTJDtI Message-ID: From: Robert Raszuk To: idr wg Content-Type: text/plain; charset=ISO-8859-1 Subject: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:17:36 -0000 I think that this thread reg private AS range extension has demonstrated the real problem with the current AS definition. Let me post a very simple question ... Why current AS numbers are flat ? I think all current issues would be solved if we would define and provide two level AS numbers "AS-PUBLIC.AS-PRIVATE" which btw was perhaps a bit indirectly expressed in the other email I have sent except it called to look at the tuples of private and public AS. Perhaps it's time we revisit the AS_PATH attributes (two and four octets) and allow for required flexibility by defining new FLEX_AS_PATH attribute other then keep fighting on point issues today and in the future... Best, R. From tony.li@tony.li Wed Dec 12 15:25:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CAF21E808C for ; Wed, 12 Dec 2012 15:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBYFmbh0rY7l for ; Wed, 12 Dec 2012 15:25:44 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 356F821E8039 for ; Wed, 12 Dec 2012 15:25:44 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id al4s1k0211vN32cA1nRk3X; Wed, 12 Dec 2012 23:25:44 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta22.emeryville.ca.mail.comcast.net with comcast id anPY1k00g52qHCY8inPbDQ; Wed, 12 Dec 2012 23:23:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Wed, 12 Dec 2012 15:23:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <941924E0-5AD8-4C36-AE39-0AA4159122FB@tony.li> References: To: Robert Raszuk X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355354744; bh=4ADehhacOaQLaV7XIx/J/w1owED6cyTkSS/59fgAb2c=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=Kb4E0jzoHNOTBJdQH/JI2r3vbnQ7JgTfZU9B7oKsSVoYtV+PLWEjAIwsyT4dxSLJi zRts2/DggZN0EKiqBXYmSZ0wp5F8biOksdlYqSVbuAhxEV+CmMJaATQzFtbxEPGf/e 5CrzGluuos3uuSlbyvWHTE0eTXyw1qip70ffwujwXQsJKCbcDZbR1UseRln2fClTzc F0ehWNHqYXmHGrCHKgtqWQ382mEvrLA8JBVwTk1iik35iDnY5OAcs+hICyKxyTgQjs BgaviN3xQBDCXRWLC3iAtA5250XnUj4MA95KEnUlS2lQJP9sWr75hd8PaMUvyPZPt9 EicwifpO4ppbg== Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:25:45 -0000 On Dec 12, 2012, at 3:17 PM, Robert Raszuk wrote: > Let me post a very simple question ... Why current AS numbers are flat = ? Because as of the time that Yakov and Kirk started the protocol, that = was the 'obvious' approach. Remember that they ended up creating the AS = number space in its entirety. As we have seen in practice, we allocate them hierarchically, first = through the RIRs, and now private numbers within the domain. The generalization should be obvious to all. But the horse has long since left the barn. Regards, Tony From rraszuk@gmail.com Wed Dec 12 15:33:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF821F888A for ; Wed, 12 Dec 2012 15:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.942 X-Spam-Level: X-Spam-Status: No, score=-2.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMGWIt-U6ZJy for ; Wed, 12 Dec 2012 15:33:25 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1A2721F8889 for ; Wed, 12 Dec 2012 15:33:25 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3037039ieb.31 for ; Wed, 12 Dec 2012 15:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=z+n4UWA4dYhHAfVqXUht+ahmh23qY6pf8MFnZllMGZU=; b=h/+bAVoolwW33/GA/AHe3yhmQBuNdxjHGdlNYadL2xT+V3UG5p1WAmuV1pylLa5mbo A5HuWWDkwd5gUlHo7OQLXYRPHSjvwDQpIAmpBh282BUM8yUd0zHcz8kR23AtG8vdwfpL 8iyv90HihOHZvrOJUayJdHfd5THrzKw5OmRwNrF2fIUd8kC9nXzaQCkhEUU1fnjzMDNq H9kzZUxP5bMkxKfvyrJ0gnlcQ50ak101f8aKKkwhbXdzi+IfWACG3yJ8varedwK5RZlI xRPgU0s1MGDa07RcuNHgOUxTgywDUpeSfiORYJnBgqH9KIlwWruNDeH4KlQuo2XVh5XI 6NvQ== MIME-Version: 1.0 Received: by 10.42.118.13 with SMTP id v13mr2277133icq.44.1355355204811; Wed, 12 Dec 2012 15:33:24 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 15:33:24 -0800 (PST) In-Reply-To: <941924E0-5AD8-4C36-AE39-0AA4159122FB@tony.li> References: <941924E0-5AD8-4C36-AE39-0AA4159122FB@tony.li> Date: Thu, 13 Dec 2012 00:33:24 +0100 X-Google-Sender-Auth: 66gh1FC4cLJIZ4yFi8HyKqvpsB4 Message-ID: From: Robert Raszuk To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 23:33:26 -0000 > The generalization should be obvious to all. Well ... I think while are frequencies may match we may be out of orbit for others ;) > But the horse has long since left the barn. Likewise BGP was not MP at the stable. Then even Yakov took a step back and asked Ravi to implement MP. Maybe we need to make BGP AS_PATH fit the needs of today ? Yes it is very unfortunate that our close friends where spend time to define 4 octet AS just before .. but as it seems this does not help the real world. So anyone willing to fix the the main problem other then to work on the patches ??? r. > On Thu, Dec 13, 2012 at 12:23 AM, Tony Li wrote: > > On Dec 12, 2012, at 3:17 PM, Robert Raszuk wrote: > >> Let me post a very simple question ... Why current AS numbers are flat ? > > Because as of the time that Yakov and Kirk started the protocol, that was the 'obvious' approach. Remember that they ended up creating the AS number space in its entirety. > > As we have seen in practice, we allocate them hierarchically, first through the RIRs, and now private numbers within the domain. > > The generalization should be obvious to all. > > But the horse has long since left the barn. > > Regards, > Tony > From rajiva@cisco.com Wed Dec 12 16:10:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421101F0CC5 for ; Wed, 12 Dec 2012 16:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4QhR6dfO3ln for ; Wed, 12 Dec 2012 16:10:44 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 630DE1F0CB9 for ; Wed, 12 Dec 2012 16:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1355357444; x=1356567044; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qqCBOTGcXuVAOf2PYgR6ZMu0OPTrfb47V9XP/sEIhmI=; b=IixrnVr0yVdQXrY7uySNEfiYApFrRSOm3gmYajBMk5nmDUkKTGwCk7sx VJgCahRgWJfNapqh4BxRJ01WjJXSfgq27GudVtbFTUfqKNkYXn5uD4ava F12YliKw/yQ+aYFW4RCFx28ye4+lEOkizPk10wWed7LajD+Dd++SR2WIA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMwbyVCtJV2d/2dsb2JhbABFvm0Wc4IeAQEBAwEBAQE3NAsMBgEIEQMBAgEKFDcLHQgCBAENBQiIAwYMvXMEjEuDYmEDplGCc4Ii X-IronPort-AV: E=Sophos;i="4.84,269,1355097600"; d="scan'208";a="152373857" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 13 Dec 2012 00:10:43 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBD0Ahum019289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 00:10:43 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.180]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 18:10:43 -0600 From: "Rajiv Asati (rajiva)" To: Robert Raszuk , Tony Li Thread-Topic: [Idr] AS numbers - flat vs hierarchical Thread-Index: AQHN2L7x9C9PpgHsWUaH7lWvoJayB5gWMn0AgAACwgD//7aVAA== Date: Thu, 13 Dec 2012 00:10:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.249.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:10:45 -0000 It seems reasonable to expand BGP ASN to something like what IPv6 has -- in the name of GUA and ULA [RFC4193] =20 Cheers. Rajiv PS: Perhaps, Reserve one bit in 4 octet space to mean Private ASN, perhaps, and keep the same 4-octet length for private ASN. -----Original Message----- From: "robert@raszuk.net" Date: Wednesday, December 12, 2012 6:33 PM To: Tony Li Cc: "idr@ietf.org" Subject: Re: [Idr] AS numbers - flat vs hierarchical >> The generalization should be obvious to all. > >Well ... I think while are frequencies may match we may be out of >orbit for others ;) > >> But the horse has long since left the barn. > >Likewise BGP was not MP at the stable. Then even Yakov took a step >back and asked Ravi to implement MP. > >Maybe we need to make BGP AS_PATH fit the needs of today ? > >Yes it is very unfortunate that our close friends where spend time to >define 4 octet AS just before .. but as it seems this does not help >the real world. > >So anyone willing to fix the the main problem other then to work on >the patches ??? > >r. > >> On Thu, Dec 13, 2012 at 12:23 AM, Tony Li wrote: >> >> On Dec 12, 2012, at 3:17 PM, Robert Raszuk wrote: >> >>> Let me post a very simple question ... Why current AS numbers are flat >>>? >> >> Because as of the time that Yakov and Kirk started the protocol, that >>was the 'obvious' approach. Remember that they ended up creating the AS >>number space in its entirety. >> >> As we have seen in practice, we allocate them hierarchically, first >>through the RIRs, and now private numbers within the domain. >> >> The generalization should be obvious to all. >> >> But the horse has long since left the barn. >> >> Regards, >> Tony >> >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Wed Dec 12 16:23:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C38021F88A6 for ; Wed, 12 Dec 2012 16:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdrcpYJtuhpa for ; Wed, 12 Dec 2012 16:23:13 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7644521F88A4 for ; Wed, 12 Dec 2012 16:23:13 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1472788iaz.31 for ; Wed, 12 Dec 2012 16:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=J+OPPRudockJkZj1suGEba/k7M1pIzjgzPsyMvPx504=; b=jbjWvZSGmpQhKcqjLnwGHDEFTen1dQWlQC8T1ItrngbgfVtdOtJX2nebo/OIqKKwfo MI6UyCwAmT2fwB+IOFOsY8RfoagphzEOT0i6Ym4GRUUvAUkRHsOv0zoBS0FPwUmfnGfM pRaXNuJrYgmsmBNCrDj1s2AIUHLzV/903uM9VOdw8p1hwd8A3HVlTopp14BUWGNh/4Ff 8NxtUgSlQeAXFDT6C6rmvbo/NrwqaZWgXrxXvie1t/1+phNa4+zyRj+bOmlbrujY2CGt C5wBM7sinJVFQeFT5z/24DA293wvOxjRgj01boI2xVVZ9gBjbvGJ8EtUEJVbHLp88FdR 8V7w== MIME-Version: 1.0 Received: by 10.50.195.196 with SMTP id ig4mr2707279igc.33.1355358193032; Wed, 12 Dec 2012 16:23:13 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Wed, 12 Dec 2012 16:23:12 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 01:23:12 +0100 X-Google-Sender-Auth: KnvHT21jHQsBNqIr-szvthFZ8yk Message-ID: From: Robert Raszuk To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , Tony Li Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 00:23:14 -0000 Hi Rajiv, > PS: Perhaps, Reserve one bit in 4 octet space to mean Private ASN, > perhaps, and keep the same 4-octet length for private ASN. Well this was exactly as I suggested yesterday .. but I think only you have acked on it :) After second thought I think (and TLI states it as obvious) long term we need much more hierarchical AS_PATH where the real AS will have a freedom to assign subordinates ,,, r, From farmer@umn.edu Wed Dec 12 18:20:28 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8240321F8512 for ; Wed, 12 Dec 2012 18:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft2e7wPCLSH8 for ; Wed, 12 Dec 2012 18:20:27 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB7321F850B for ; Wed, 12 Dec 2012 18:20:27 -0800 (PST) Received: from mail-ia0-f199.google.com (mail-ia0-f199.google.com [209.85.210.199]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 12 Dec 2012 20:20:16 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f199.google.com [209.85.210.199] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f199.google.com with SMTP id z25so3052888iab.10 for ; Wed, 12 Dec 2012 18:20:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=sS4cpBgJIabREql5YK/+PbsOYZzvAG6kn3gaWrJhIM0=; b=DXQDJCqs1vJB4IJNSYWSfMzW3MuSg0GCbbXMeG2mhSBx4tuDZbVRZhV5HB4XgRFLEJ WnSOoSVyU0a7oFdPznbpbWOeZnp4Ie+bddbAF0lMkcG5uxRAjIX1i3PPpQLlf+pazJgR 5mcj6cLo66FHNwbUDqaNlPxWZ0q6ybZeiP2IwZT1Wz+d81iML2xVNG0BvPt6fOg8+k2n pWfOxucgDWFM2/CPsZHK6Ht021CxD901NN04hXHeKrh3yE7birgrbqowcStD+wzqeuBN Lb6w4h/lRV6QhvB2hL2uPy6BA1njgO40R5t4tj7W6iJcsFY9CE2/XxiUzbCtbgbD4duL csUw== Received: by 10.50.76.195 with SMTP id m3mr15481656igw.64.1355365216475; Wed, 12 Dec 2012 18:20:16 -0800 (PST) Received: by 10.50.76.195 with SMTP id m3mr15481624igw.64.1355365215885; Wed, 12 Dec 2012 18:20:15 -0800 (PST) Received: from x-134-84-88-29.nts.umn.edu ([2607:ea00:101:2001:1d22:1466:26ae:9e31]) by mx.google.com with ESMTPS id as6sm3219893igc.8.2012.12.12.18.20.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 18:20:14 -0800 (PST) Message-ID: <50C93B5D.4010607@umn.edu> Date: Wed, 12 Dec 2012 20:20:13 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlALwKwkR1nzA+Q0jqP6m6YNPLh+qe4FAFoAeqzY3ekGm6FBWwGKQz6JR8aldTROPrKpeYu4ZRpxqzKu5tVJIIk8Rk3TaPCKSTgrnpylqL6RhPTID3kB43ujl5dy3rUd8IzzRg9 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 02:20:28 -0000 On 12/12/12 15:07 , Christopher Morrow wrote: > On Wed, Dec 12, 2012 at 4:03 PM, Jared Mauch wrote: >> >> On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: >> ... >> b) leak "private" space without explicit configurations to enable said action. > > 'what is private' ? This got me thinking, why are we calling them "private" anyway? Section 10 of RFC 1930 is actually titled "Reserved AS Numbers" and only uses the word "private" when describe their use, it says; The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Just like we are clarifying the end point of the original range, as 65534 inclusive; I would like to suggest clarifying their use, by taking a cue from RFC 4193 and more accurately use the term "local" instead of "private" when describing their use. The definition of "private" doesn't seem completely accurate, "pertaining to or affecting a particular person or a small group of persons; individual; personal;" works, but "confined to or intended only for the persons immediately concerned; confidential;" seems problematic, and we seem wholly incapable of keeping them private anyway. Where as, local, "pertaining to or affecting a particular part or particular parts, as of a physical system or organism;" or "pertaining to, characteristic of, or restricted to a particular place or particular places" seem much more accurate, and has no connotations of confidentiality or security. Bedsides a general search and replace of "private" substituting "local" in the text and title, I would like to suggest a singe sentence paragraph be added at the beginning of Section 2; "Local use ASNs are used by or within a single technical administration or among multiple technical administrations by explicit agreement only." This simply restates the intended use of theses ASNs, using updated terminology, that should be less overloaded and misunderstood. This seems completely compatible with the original intent of section 10 of RFC 1930 and the operational guidance provided in Section 3 of this draft. Additionally, I would like to suggest the following changes to the abstract; "This document describes the reservation of Autonomous System numbers (ASNs) that are for local use only and should not be advertised to the Internet, sometimes known as private use ASNs. This document enlarges the total space available for local use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 in its entirety." The intent is to have this be the sole remaining use of the term "private" proving an explicit link to section 10 of RFC 1930. But, also clarifying how this draft updates RFC 1930, by replacing Section 10, clarifying the terminology and the end point of the original range. What do you think? -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jakob.heitz@ericsson.com Wed Dec 12 18:28:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACDC21F85E6 for ; Wed, 12 Dec 2012 18:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKp8ubRc0try for ; Wed, 12 Dec 2012 18:28:17 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 843C221F85C0 for ; Wed, 12 Dec 2012 18:28:17 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBD2ckPl016206; Wed, 12 Dec 2012 20:38:48 -0600 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 12 Dec 2012 21:28:09 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 21:28:09 -0500 From: Jakob Heitz To: David Farmer , Christopher Morrow Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHN19SJffMIynRi20WhRXYHBAltwZgUUuOAgAFmc4CAAA34gIAABlQAgAAFiwCAAAEOgIAAAPiAgAABdQCAAAOkAIAAAswAgAAHn4CAAAGRgIAAAf6AgAAIkYCAAAusgIAAAOgAgABXgYD//64TAA== Date: Thu, 13 Dec 2012 02:28:08 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> <50C93B5D.4010607@umn.edu> In-Reply-To: <50C93B5D.4010607@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 02:28:19 -0000 We all know what a private ASN is. "Local" is an overused word devoid of meaning. If it ain't broke, don't fix it. On , David Farmer <> wrote: > On 12/12/12 15:07 , Christopher Morrow wrote: >> On Wed, Dec 12, 2012 at 4:03 PM, Jared Mauch >> wrote:=20 >>>=20 >>> On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: >>>=20 > ... >>> b) leak "private" space without explicit configurations to enable >>> said action.=20 >>=20 >> 'what is private' ? >=20 > This got me thinking, why are we calling them "private" anyway? >=20 > Section 10 of RFC 1930 is actually titled "Reserved AS > Numbers" and only > uses the word "private" when describe their use, it says; >=20 > The Internet Assigned Numbers Authority (IANA) has reserved the > following block of AS numbers for private use (not to be > advertised on the global Internet): >=20 > 64512 through 65535 >=20 > Just like we are clarifying the end point of the original range, as > 65534 inclusive; I would like to suggest clarifying their > use, by taking > a cue from RFC 4193 and more accurately use the term "local" > instead of > "private" when describing their use. The definition of "private" > doesn't seem completely accurate, "pertaining to or affecting a > particular person or a small group of persons; individual; personal;" > works, but "confined to or intended only for the persons immediately > concerned; confidential;" seems problematic, and we seem wholly > incapable of keeping them private anyway. Where as, local, > "pertaining to or affecting a particular part or particular parts, as > of=20 > a physical > system or organism;" or "pertaining to, characteristic of, or > restricted to a particular place or particular places" seem much more > accurate, and > has no connotations of confidentiality or security. >=20 > Bedsides a general search and replace of "private" > substituting "local" > in the text and title, I would like to suggest a singe sentence > paragraph be added at the beginning of Section 2; >=20 > "Local use ASNs are used by or within a single technical > administration or among multiple technical administrations by explicit > agreement only." >=20 > This simply restates the intended use of theses ASNs, using updated > terminology, that should be less overloaded and misunderstood. This > seems completely compatible with the original intent of section 10 of > RFC 1930 and the operational guidance provided in Section 3 > of this draft. >=20 > Additionally, I would like to suggest the following changes to the > abstract;=20 >=20 > "This document describes the reservation of Autonomous System numbers > (ASNs) that are for local use only and should not be > advertised to the > Internet, sometimes known as private use ASNs. This document enlarges > the total space available for local use ASNs by documenting the > reservation of a second, larger range and updates RFC 1930 by > replacing Section 10 in its entirety." >=20 > The intent is to have this be the sole remaining use of the term > "private" proving an explicit link to section 10 of RFC 1930. But, > also clarifying how this draft updates RFC 1930, by replacing Section > 10, clarifying the terminology and the end point of the original > range.=20 >=20 > What do you think? --=20 Jakob Heitz. From farmer@umn.edu Wed Dec 12 18:45:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D627E21F87ED for ; Wed, 12 Dec 2012 18:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3866Eg07+v1 for ; Wed, 12 Dec 2012 18:45:30 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id B9C3421F87EC for ; Wed, 12 Dec 2012 18:45:20 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 12 Dec 2012 20:45:10 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id c10so6485043ieb.1 for ; Wed, 12 Dec 2012 18:45:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=7u2+Z7sadMOCvSPX1MI3RJ/s/ldNQwn6FHlZVdwVuFY=; b=P0S+LGW7P5ZU+3vCFrCoyVBoKAB9gcFHWcY72vmTn+Z7ix81rjAqgq2A8UbJ1/ONhP 5zsOD3Srx5gT7T+1vo96V/C8Mh6TNSgZSB8G6sV/b+D38pDQgFbxhj3HnYdzH5lFJvuY iIGcmnro2WhbIs2rEGIGlUwGlgAvVWqmggs3nbqzZSkHvVz9yUanrHnevNk1f1yL9h8l FcJGfcAxQ+U9XP6bYVEPB2no3x9+SNrD4xzV3qWnkaUG3WZWmZgLD24DAGhuHrplSKQc cwWMBuIgd8gR+hDZKxJcrYH4DU+zIPzNcWHLnm6LKvkh63O8dUDupzVbonsitgO9f3L6 t/WA== Received: by 10.50.214.38 with SMTP id nx6mr260427igc.28.1355366709894; Wed, 12 Dec 2012 18:45:09 -0800 (PST) Received: by 10.50.214.38 with SMTP id nx6mr260422igc.28.1355366709784; Wed, 12 Dec 2012 18:45:09 -0800 (PST) Received: from x-134-84-88-29.nts.umn.edu ([2607:ea00:101:2001:1d22:1466:26ae:9e31]) by mx.google.com with ESMTPS id uj11sm3247958igb.15.2012.12.12.18.45.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 18:45:08 -0800 (PST) Message-ID: <50C94133.9060805@umn.edu> Date: Wed, 12 Dec 2012 20:45:07 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jakob Heitz References: <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> <50C8CF69.4070202@foobar.org> <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnw72Lky4Ry52vNs4b/nKSdjcD1K+zhWhtcf7qgk/x0/HAIbmmKeb/pntM0as9WfPWbuGN6/4fcTXVgopyAaeiggLphixAcL/IC1cW6eocQSX+hEZ9FMc05c/rqKEWYUrMDw8Xq Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 02:45:35 -0000 On 12/12/12 20:28 , Jakob Heitz wrote: > We all know what a private ASN is. "Local" is an overused word > devoid of meaning. If it ain't broke, don't fix it. > > On , David Farmer <> wrote: > >> On 12/12/12 15:07 , Christopher Morrow wrote: >>> On Wed, Dec 12, 2012 at 4:03 PM, Jared Mauch >>> wrote: >>>> >>>> On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: >>>> >> ... >>>> b) leak "private" space without explicit configurations to enable >>>> said action. >>> >>> 'what is private' ? >> >> This got me thinking, why are we calling them "private" anyway? Ok, then you answer Chris' question. That was my answer. I'll only add "private" seems an equally overused word and equally devoid of meaning especially in this context. And, you may not think it is broke, but some people on the list seem to think it is broken. So, maybe we should fix the brokenness, rather than propagating the brokenness. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nick@foobar.org Thu Dec 13 02:15:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8B21F8A4B for ; Thu, 13 Dec 2012 02:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5QfnC48IAJu for ; Thu, 13 Dec 2012 02:15:49 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE521F8A27 for ; Thu, 13 Dec 2012 02:15:48 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie ([IPv6:2001:1bb8:2004:200:f42d:590c:723b:1e05]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBDAEAuo056317 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 10:14:11 GMT (envelope-from nick@foobar.org) Message-ID: <50C9AACF.1010201@foobar.org> Date: Thu, 13 Dec 2012 10:15:43 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Robert Raszuk References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:15:50 -0000 On 13/12/2012 00:23, Robert Raszuk wrote: > After second thought I think (and TLI states it as obvious) long term > we need much more hierarchical AS_PATH where the real AS will have a > freedom to assign subordinates ,,, Forgive my ignorance, but I don't what you're getting at here. Can you explain? ASN deployment has always been piecemeal, and ASNs bitfields have never been part of any routing discrimination mechanism. Are you proposing to change this, and if so, why? Nick From gvandeve@cisco.com Thu Dec 13 05:40:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3745521F8ACF for ; Thu, 13 Dec 2012 05:40:33 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4P1TrfdZPTB for ; Thu, 13 Dec 2012 05:40:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76421F8ACD for ; Thu, 13 Dec 2012 05:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1106; q=dns/txt; s=iport; t=1355406032; x=1356615632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gqhflk47fLDhMBeuqV9kkZTt4hK7qgUE0FOvw+CiQJM=; b=GVIb4ayOIOs6y2zMHal9aMgL3wYsOFUOuKo6evCijq6pU0P08GyasodU SMtygDnXXlkgVCi8y0J8rHMS/I3Msw4/cMSJqFl/3Qdspyd0pWHQ1AMwq rtKKSPwH/jGgjM9yNwYyMJheFloXh7r87TumXm7UPh3EZLiRTOLqyHzRd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF3ZyVCtJXHB/2dsb2JhbABFvnEWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiICwy9YgSMV4NiYQOmUYJzgiI X-IronPort-AV: E=Sophos;i="4.84,273,1355097600"; d="scan'208";a="152325382" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 13 Dec 2012 13:40:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBDDeVk6028807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 13:40:32 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.128]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 07:40:31 -0600 From: "Gunter Van de Velde (gvandeve)" To: Nick Hilliard , Robert Raszuk Thread-Topic: [Idr] AS numbers - flat vs hierarchical Thread-Index: AQHN2L7oPxEmPbywEkexFyTRbEd4q5gWMn0AgAACwgCAAApsAIAAA34AgACljID//9PMsA== Date: Thu, 13 Dec 2012 13:40:31 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C84EAB5@xmb-aln-x12.cisco.com> References: <50C9AACF.1010201@foobar.org> In-Reply-To: <50C9AACF.1010201@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:40:33 -0000 I am just falling into the discussion here.=20 Would hierarchical ASN's maybe aid with the operation of confederations and= making it simpler to deploy instead of using the private ASN space? (I am thinking out loud here) G/ -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Nick = Hilliard Sent: 13 December 2012 11:16 To: Robert Raszuk Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical On 13/12/2012 00:23, Robert Raszuk wrote: > After second thought I think (and TLI states it as obvious) long term=20 > we need much more hierarchical AS_PATH where the real AS will have a=20 > freedom to assign subordinates ,,, Forgive my ignorance, but I don't what you're getting at here. Can you exp= lain? ASN deployment has always been piecemeal, and ASNs bitfields have ne= ver been part of any routing discrimination mechanism. Are you proposing t= o change this, and if so, why? Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Thu Dec 13 06:09:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E6B21F8AE5 for ; Thu, 13 Dec 2012 06:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWwssplnVXpl for ; Thu, 13 Dec 2012 06:09:16 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id F252221F8AC8 for ; Thu, 13 Dec 2012 06:09:15 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBDE9D55005150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 09:09:13 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBDE9DeM005149; Thu, 13 Dec 2012 09:09:13 -0500 Date: Thu, 13 Dec 2012 09:09:13 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121213140913.GA4524@puck.nether.net> References: <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> <50C94133.9060805@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C94133.9060805@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 13 Dec 2012 09:09:13 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:09:17 -0000 Maybe I can assist with the definition... RFC1930 was writen a long time ago, but clearly in Section 10 it does say these are for private use. This is reconfirmed by RFC5226 definition of Private Use is what is being used in the draft, not a common language dictionary entry, here is the section text: 4.1. Well-Known IANA Policy Definitions The following are some defined policies, some of which are in use today. These cover a range of typical policies that have been used to date to describe the procedure for assigning new values in a namespace. It is not required that documents use these terms; the actual requirement is that the instructions to IANA are clear and unambiguous. However, use of these terms is RECOMMENDED where possible, since their meaning is widely understood. Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). Examples: Site-specific options in DHCP [DHCP-IANA], Fibre Channel Port Type Registry [RFC4044], Exchange Types in the IKEv2 header [RFC4306]. On Wed, Dec 12, 2012 at 08:45:07PM -0600, David Farmer wrote: > On 12/12/12 20:28 , Jakob Heitz wrote: > >We all know what a private ASN is. "Local" is an overused word > >devoid of meaning. If it ain't broke, don't fix it. > > > >On , David Farmer <> wrote: > > > >>On 12/12/12 15:07 , Christopher Morrow wrote: > >>>On Wed, Dec 12, 2012 at 4:03 PM, Jared Mauch > >>>wrote: > >>>> > >>>>On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: > >>>> > >>... > >>>>b) leak "private" space without explicit configurations to enable > >>>>said action. > >>> > >>>'what is private' ? > >> > >>This got me thinking, why are we calling them "private" anyway? > > Ok, then you answer Chris' question. That was my answer. > > I'll only add "private" seems an equally overused word and equally > devoid of meaning especially in this context. And, you may not > think it is broke, but some people on the list seem to think it is > broken. So, maybe we should fix the brokenness, rather than > propagating the brokenness. > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Thu Dec 13 06:15:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A953821F8AFA for ; Thu, 13 Dec 2012 06:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-wsMim1boEk for ; Thu, 13 Dec 2012 06:15:33 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9F6721F8AF9 for ; Thu, 13 Dec 2012 06:15:32 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so4007756ieb.31 for ; Thu, 13 Dec 2012 06:15:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dLrHK7da6r2//6q8DoOQhr5S6yNHsBE+C0IKRBX6yI0=; b=b1RmAdIiSYfK7RTOEdA5F0cCVzQh6yTQoMO7bM060QXA4fn1Keipk31KmpbJRnxVf+ 0CYk+2zB//C+eRmsh0x6r6Isr4JWa5blwBDvIPHYlc3MdkLaySLNDTxWMOGigA/fu5ib smHuhxjNALaO3tKNvIbR/MY+dx58xGqwfQmPgDYNihAfns0mQugDEWNkKT4QJuJ7hsBK yyTiAgN8gOtjYFyH55R9a9HW+felSLZuSzrORsAW4yXhSzSg8xhBsgSBiwI/grYqQZgP Pv+2is8JfUVPjpkqTtSilVetTyHN1mUXTkUI19DCLtOsgPeflYkcX8gIHbYA1c9mvZ0B IMxQ== MIME-Version: 1.0 Received: by 10.42.131.133 with SMTP id z5mr1500499ics.10.1355408125377; Thu, 13 Dec 2012 06:15:25 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 13 Dec 2012 06:15:25 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <50C8CE86.10103@umn.edu> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> Date: Thu, 13 Dec 2012 09:15:25 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl2I8/QA4dj8LxqTqQN5wroG+TthEyqksYuS5Xo5o22BlswLcB62GqYXmL2yii8CtOsCAEH Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:15:33 -0000 On Wed, Dec 12, 2012 at 1:35 PM, David Farmer wrote: > Nick, why is this any different than creating a regexp that matches the > current private ASN range? To me this is a CLI/Config semantics issue and > not a standards or allocation issue. When I read the above argument, I think it is a clear statement that you don't just not care how something appears in a CLI/NMS, but you actually care more about an arbitrary range of numbers being unnecessarily bit-aligned than you do a zero-cost move of that range to where it can be CLI-friendly. Operators do care what is on the CLI. Operators also think the IETF pays little attention to our concerns. That's our fault for not participating in the IETF process, but here you've got some operators saying, please, reconsider this allocation! Make it easier on us! And then you've got some guys whining about a bit-alignment thing that actually isn't. Why isn't it bit-aligned? Because ASN 2^32-1 is already reserved by IANA and is not part of this new proposed private ASN range. That means a programmer implementing a test to find if an ASN is in this private range will be doing a range-check. Could you make a branch table from the first bits and then do the second arithmetic comparison? Sure. Why would you want to? Unless there are a bunch of other branches in the table, it will be slower. There is no argument to be made that the bit-alignment can make code faster. We are talking about a difference of a few instruction cycles on any modern CPU anyway, but unless there will be a bunch of other results besides "private" and "not private," which would mean there are going to be a bunch of other reservations for different kinds of ASNs in the future, then the bit-alignment simply does not offer an advantage. Making the branch-table would actually be slower, but not so much slower you would care; however you probably won't implement the branch table anyway because it is both more complicated and slower. I continue to think that a decimal-aligned allocation makes more sense. I also agree with Nick Hilliard that this range should possibly be much lower in the ASN space to further improve legibility. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From usenet@sxi.dk Thu Dec 13 06:24:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154E021F8B33 for ; Thu, 13 Dec 2012 06:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxGvsci1Zt4N for ; Thu, 13 Dec 2012 06:24:12 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD8C21F8B32 for ; Thu, 13 Dec 2012 06:24:11 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1324371eek.31 for ; Thu, 13 Dec 2012 06:24:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nzx2cojYJ1IaNTwNB87Lz2hsv7CqP3Q3+R17OB3UR6U=; b=UMRSN+EwRYDsK9VgOWueHMpAXy+jxH4DUxV6eBTCc7cOb9npm6uV56Vb0RJcx4y4Mk U6Vc/8wrf1rlyPhxxQ7w/TK41OEXIwhVWbCNxIkgfxrjZSxCdyfi6dtrX4ftgQM4C7zA cXtMapzyi9UUCFlnjgxEjrqh5adJ1KgViO+Vo8YF0fdHhEJsNZwf/QVGINI7tzUkxhf0 nRKlQfty/JA737t0HTCMdKLUsS+U/7SNutKmDqElbckgmYfRQlfKWoouwrs2pH3c1kMP UFduswKs3uscvt+hee/sL5LhmuShlh5Gi+jQolcQDbvZBnQXu22Y2gLs4lZCY4+iyDc5 shfg== MIME-Version: 1.0 Received: by 10.14.2.66 with SMTP id 42mr5840036eee.7.1355408650431; Thu, 13 Dec 2012 06:24:10 -0800 (PST) Received: by 10.14.125.15 with HTTP; Thu, 13 Dec 2012 06:24:10 -0800 (PST) In-Reply-To: References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C8CE86.10103@umn.edu> Date: Thu, 13 Dec 2012 15:24:10 +0100 Message-ID: From: Allan Eising To: Jeff Wheeler Content-Type: multipart/alternative; boundary=047d7b62440c226b0804d0bcab91 X-Gm-Message-State: ALoCoQmIkwhB+NH+5/yGqVuvoHHHtKm2kGoEPu6yfIDx78tfxE3KVZ9AQNOZZZPsAs7MLg8aUshn Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:26:42 -0000 --047d7b62440c226b0804d0bcab91 Content-Type: text/plain; charset=ISO-8859-1 List, Nick, Jeff, I just wanted shortly to express that I agree with both Jeff here and Nick Hilliard. Their points are good enough and I feel no need to repeat them. We use a great deal of private ASNs, so an extended range of numbers would be welcomed no matter what, but with regards to the operational side of things, I would much prefer if the draft would reflect the points made in this thread. /Allan On Thu, Dec 13, 2012 at 3:15 PM, Jeff Wheeler wrote: > On Wed, Dec 12, 2012 at 1:35 PM, David Farmer wrote: > > Nick, why is this any different than creating a regexp that matches the > > current private ASN range? To me this is a CLI/Config semantics issue > and > > not a standards or allocation issue. > > When I read the above argument, I think it is a clear statement that > you don't just not care how something appears in a CLI/NMS, but you > actually care more about an arbitrary range of numbers being > unnecessarily bit-aligned than you do a zero-cost move of that range > to where it can be CLI-friendly. > > Operators do care what is on the CLI. Operators also think the IETF > pays little attention to our concerns. That's our fault for not > participating in the IETF process, but here you've got some operators > saying, please, reconsider this allocation! Make it easier on us! > And then you've got some guys whining about a bit-alignment thing that > actually isn't. > > Why isn't it bit-aligned? Because ASN 2^32-1 is already reserved by > IANA and is not part of this new proposed private ASN range. > > That means a programmer implementing a test to find if an ASN is in > this private range will be doing a range-check. Could you make a > branch table from the first bits and then do the second arithmetic > comparison? Sure. Why would you want to? Unless there are a bunch > of other branches in the table, it will be slower. > > There is no argument to be made that the bit-alignment can make code > faster. We are talking about a difference of a few instruction cycles > on any modern CPU anyway, but unless there will be a bunch of other > results besides "private" and "not private," which would mean there > are going to be a bunch of other reservations for different kinds of > ASNs in the future, then the bit-alignment simply does not offer an > advantage. Making the branch-table would actually be slower, but not > so much slower you would care; however you probably won't implement > the branch table anyway because it is both more complicated and > slower. > > I continue to think that a decimal-aligned allocation makes more > sense. I also agree with Nick Hilliard that this range should > possibly be much lower in the ASN space to further improve legibility. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b62440c226b0804d0bcab91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List, Nick, Jeff,

I just wanted shortly to express that = I agree with both Jeff here and Nick Hilliard. Their points are good enough= and I feel no need to repeat them.

We use a great= deal of private ASNs, so an extended range of numbers would be welcomed no= matter what, but with regards to the operational side of things, I would m= uch prefer if the draft would reflect the points made in this thread.

/Allan

<= br>
On Thu, Dec 13, 2012 at 3:15 PM, Jeff Whe= eler <jsw@inconcepts.biz> wrote:
On Wed, Dec 12, 2012 at 1:35 PM, David Farme= r <farmer@umn.edu> wrote:
> Nick, why is this any different than creating a regexp that matches th= e
> current private ASN range? =A0To me this is a CLI/Config semantics iss= ue and
> not a standards or allocation issue.

When I read the above argument, I think it is a clear statement that
you don't just not care how something appears in a CLI/NMS, but you
actually care more about an arbitrary range of numbers being
unnecessarily bit-aligned than you do a zero-cost move of that range
to where it can be CLI-friendly.

Operators do care what is on the CLI. =A0Operators also think the IETF
pays little attention to our concerns. =A0That's our fault for not
participating in the IETF process, but here you've got some operators saying, please, reconsider this allocation! =A0Make it easier on us!
And then you've got some guys whining about a bit-alignment thing that<= br> actually isn't.

Why isn't it bit-aligned? =A0Because ASN 2^32-1 is already reserved by<= br> IANA and is not part of this new proposed private ASN range.

That means a programmer implementing a test to find if an ASN is in
this private range will be doing a range-check. =A0Could you make a
branch table from the first bits and then do the second arithmetic
comparison? =A0Sure. =A0Why would you want to? =A0Unless there are a bunch<= br> of other branches in the table, it will be slower.

There is no argument to be made that the bit-alignment can make code
faster. =A0We are talking about a difference of a few instruction cycles on any modern CPU anyway, but unless there will be a bunch of other
results besides "private" and "not private," which woul= d mean there
are going to be a bunch of other reservations for different kinds of
ASNs in the future, then the bit-alignment simply does not offer an
advantage. =A0Making the branch-table would actually be slower, but not
so much slower you would care; however you probably won't implement
the branch table anyway because it is both more complicated and
slower.

I continue to think that a decimal-aligned allocation makes more
sense. =A0I also agree with Nick Hilliard that this range should
possibly be much lower in the ASN space to further improve legibility.

--
Jeff S Wheeler <jsw@inconcepts.biz= >
Sr Network Operator =A0/ =A0Innovative Network Concepts
_____________________= __________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b62440c226b0804d0bcab91-- From jrmitche@puck.nether.net Thu Dec 13 06:41:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC921F88D5 for ; Thu, 13 Dec 2012 06:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm1eM9BzeWGU for ; Thu, 13 Dec 2012 06:41:57 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D800A21F88CE for ; Thu, 13 Dec 2012 06:41:56 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBDEfl4w018133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 09:41:47 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBDEfl8h018132; Thu, 13 Dec 2012 09:41:47 -0500 Date: Thu, 13 Dec 2012 09:41:47 -0500 From: Jon Mitchell To: Nick Hilliard Message-ID: <20121213144147.GB4524@puck.nether.net> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C9039E.1050104@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 13 Dec 2012 09:41:47 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:41:57 -0000 This is a long email, revisiting almost everyone of the numbering discussions in the draft, but I'll try to respond inline mostly to the nice summary you have at bottom. Jon On Wed, Dec 12, 2012 at 10:22:22PM +0000, Nick Hilliard wrote: > > Bit-aligned 4278190080 to 4294967294: > > pros: > - out of the way of RIR assignments and consistent with placement of the existing range > > cons: > - impossible to recognise visually in operational context Well, for a long period of time, operators will know to look carefully at ASN's in the 4B range unless IANA or some other RFC vastly changes the current allocation method. > - the bounding regexp is ridiculous Depending on implentation this is true, but the existing range meets this definition as well. I'm sympathetic to this argument however. > - the numbers are large enough that they will attract typos > - complete mouthful and impossible to transmit down e.g. phone, across the > room, etc (yes, we shout ASNs across the room, and sometimes even talk to > customers). I encourage your drafts to deprecate 4B ASN, MAC addresses and IPv6. My general feeling is that if you are configuring a small number of sites and your operations is confined to a single room and voice communication is your primary method still, you are likely to be happy with just using ASN 65000 (meets all of your criteria). If you have more than 1000 sites you are trying to stick an ASN on, hopefully you are taking a more programmtic view to operating and troubleshooting the network, or at least have figured out that email / IM and other communication methods are more reliable than voice for network operations. Then again, my credit card number has 16 digits and I've managed to communicate that over the phone succesfully a number of times. > > Low, decimal-aligned range: > > pros: > - immediately identifiable as private in operational context > - out of the way of RIR assignments You've suggested a range that eventually could be right in the middle of IANA assignments (forever is a long time). > - trivial bounding regexp > - smaller numbers mean fewer typos See previous comment on every other type of thing you can't call accross the room today. Even most (unpreviously heard and therefore not easily grouped) IPv4 addresses can easily be typo'd if we suggest that most humans are unable to keep more than 7 digits easily in short term memory. > 900000 to 999999 would work fine for me. I'd be even happier with > 90000-99999. In fact I'd be really pleased with the lower range because I > can relate to 5 digit numbers even more easily than 6 digit numbers - but > perhaps 10k private ASNs may not be enough for crazy large lab models. The not having to revisit this argument again and force vendor implementations in the years to come was part of the justification for a large range. Since the purpose of the draft is a single organization and it's for private use (not public as some seem bent on inferring), I'd suggest you can choose more human readable sub-ranges within the allocation for your network or lab assuming you need over 1K ASNs. > > What we need to get over is this idea that bit alignment is relevant to > asn allocation policy. It simply isn't. > > This is an operational draft. Please let's request a range which works > well for operators. I'm sympathetic to the human recognizable (but not use small or lower value ranges) and regex arguments to utilize a decimal boundary and the original draft started there. An alternate proposal that is not as silly as 4B+ but still does not consume a significant portion of the total space (if there was widespread concensus in the WG to change the existing one, given that we are in LC already) could be: 4200000000 - 4294967294 Although this is even larger than the existing range, it still is a a very small portion of the existing range, and I think no one is seriously concerned it's the size of the new range (versus having one) is concerning as there is no belief that will correlate to any specific behavior. Jon From willramses2@gmail.com Thu Dec 13 06:56:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E287D21F8B0C for ; Thu, 13 Dec 2012 06:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTOV3Ctwg29Z for ; Thu, 13 Dec 2012 06:56:00 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4C21F898D for ; Thu, 13 Dec 2012 06:55:59 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so2088017obc.31 for ; Thu, 13 Dec 2012 06:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EXHBdidudTJCi6ZCmI8mAlkamXa3Oun9R0Wz6Ex/18s=; b=MJZPhc8lzG66JVu0t3/ArtefX58uN8i7rrzpJjHPVaVpn29jYAlBzn/dnbSJXefKZ5 kAmppBBOH3g9KFhFdBJOFp7Bdj97Q3TN5V8slnJFqiCXt8vmDIJMKIjXqODrYlurJG2t HxzBXTMjRahxd4nB0KnrMUYBSmA8P87R14nFx1iwaR4Uh9H92g3ekTM2pc3yMOUuHctT Mn1BtazI4fA1TPrOQRzKFfCX7Gzj/mBiwrQZ33dmsfP5U14DhZjC96jrc8+yto0WZ7rt HF+eK0oN7u4pfxn2YUS3LCgqUDyrWANwz3+gFjjwMoXV30Lp9cwgl/JCubqtMyJzl88C NERw== MIME-Version: 1.0 Received: by 10.60.32.71 with SMTP id g7mr1692521oei.96.1355410558924; Thu, 13 Dec 2012 06:55:58 -0800 (PST) Received: by 10.76.81.37 with HTTP; Thu, 13 Dec 2012 06:55:58 -0800 (PST) In-Reply-To: <67832B1175062E48926BF3CB27C49B240C84EAB5@xmb-aln-x12.cisco.com> References: <50C9AACF.1010201@foobar.org> <67832B1175062E48926BF3CB27C49B240C84EAB5@xmb-aln-x12.cisco.com> Date: Thu, 13 Dec 2012 06:55:58 -0800 Message-ID: From: Will White To: "Gunter Van de Velde (gvandeve)" Content-Type: multipart/alternative; boundary=e89a8fb1f81ee3b6f204d0bd1cff Cc: idr wg , Robert Raszuk Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:56:01 -0000 --e89a8fb1f81ee3b6f204d0bd1cff Content-Type: text/plain; charset=ISO-8859-1 The general idea they seem to be working on here is to allow a single ASN public allocation to have Y number of private ASN assigned to it. So if FOO company was assigned FOO ASN. Then X company could use FOO.Y for private internal ASNs. Y could be a predefined bit length allowing all companies to have a predefined set of private ASNs per public ASN. This is of course just one method of doing that. The general concept they are looking at is a way to give companies private ASNs without running into the problem of ASN duplication when buying a company or some other business to business need. This would allow companies to do things with BGP in the datacenter with having less worry of running out of numbers or accidentally announcing to the internet. Additionally the hierarchical concept could also be expanded to allow for something like transit and non-transit ASNs to help reduce the re-announcement of google's or facebook's blocks by making a transit provider register for a transit ASN rather than giving every fresh company a transitable ASN. Just a couple thoughts. Will On Thu, Dec 13, 2012 at 5:40 AM, Gunter Van de Velde (gvandeve) < gvandeve@cisco.com> wrote: > I am just falling into the discussion here. > > Would hierarchical ASN's maybe aid with the operation of confederations > and making it simpler to deploy instead of using the private ASN space? > (I am thinking out loud here) > > G/ > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Nick Hilliard > Sent: 13 December 2012 11:16 > To: Robert Raszuk > Cc: idr wg > Subject: Re: [Idr] AS numbers - flat vs hierarchical > > On 13/12/2012 00:23, Robert Raszuk wrote: > > After second thought I think (and TLI states it as obvious) long term > > we need much more hierarchical AS_PATH where the real AS will have a > > freedom to assign subordinates ,,, > > Forgive my ignorance, but I don't what you're getting at here. Can you > explain? ASN deployment has always been piecemeal, and ASNs bitfields have > never been part of any routing discrimination mechanism. Are you proposing > to change this, and if so, why? > > > Nick > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --e89a8fb1f81ee3b6f204d0bd1cff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The general idea they seem to be working on here is to allow a single ASN p= ublic allocation to have Y number of private ASN assigned to it. =A0So if F= OO company was assigned FOO ASN. =A0Then X company could use FOO.Y for priv= ate internal ASNs. =A0Y could be a predefined bit length allowing all compa= nies to have a predefined set of private ASNs per public ASN. =A0

This is of course just one method of doing that. =A0The gene= ral concept they are looking at is a way to give companies private ASNs wit= hout running into the problem of ASN duplication when buying a company or s= ome other business to business need. =A0This would allow companies to do th= ings with BGP in the datacenter with having less worry of running out of nu= mbers or accidentally announcing to the internet.

Additionally the=A0hierarchical concept could also be e= xpanded to allow for something like transit and non-transit ASNs to help re= duce the re-announcement of google's or facebook's blocks by making= a transit provider register for a transit ASN rather than giving every fre= sh company a transitable ASN.

Just a couple thoughts.

Will


On Thu, D= ec 13, 2012 at 5:40 AM, Gunter Van de Velde (gvandeve) &l= t;gvandeve@cisco.co= m> wrote:
I am just falling into the discussion here.<= br>
Would hierarchical ASN's maybe aid with the operation of confederations= and making it simpler to deploy instead of using the private ASN space? (I am thinking out loud here)

G/

-----Original Message-----
From: idr-bounces@ietf.org [mai= lto:idr-bounces@ietf.org] On Be= half Of Nick Hilliard
Sent: 13 December 2012 11:16
To: Robert Raszuk
Cc: idr wg
Subject: Re: [Idr] AS numbers - flat vs hierarchical

On 13/12/2012 00:23, Robert R= aszuk wrote:
> After second thought I think (and TLI states it as obvious) long term<= br> > we need much more hierarchical AS_PATH where the real AS will have a > freedom to assign subordinates ,,,

Forgive my ignorance, but I don't what you're getting at here. =A0C= an you explain? =A0ASN deployment has always been piecemeal, and ASNs bitfi= elds have never been part of any routing discrimination mechanism. =A0Are y= ou proposing to change this, and if so, why?


Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--e89a8fb1f81ee3b6f204d0bd1cff-- From farmer@umn.edu Thu Dec 13 07:08:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890FC21F8949 for ; Thu, 13 Dec 2012 07:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ou+yGs9VCTG for ; Thu, 13 Dec 2012 07:08:20 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5EE21F89B6 for ; Thu, 13 Dec 2012 07:08:20 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 13 Dec 2012 09:08:09 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f70.google.com [209.85.219.70] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f70.google.com with SMTP id k14so9230959oag.1 for ; Thu, 13 Dec 2012 07:08:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=eqgLJ8ZfJ+X5Mb2NqbLQ/OyuQGBxgW/sz1DqmUH3o7g=; b=nZbE0bfxOFBLt0nrLtRu8n5buGtBotqidfMXaOcn7qhvbsing6oNRVc+ikrBqh60dv KR1+EIvugvj8EaDf/MmmBBWArAh3CX4+1jdVimvyU3+UHGwPtxUNsAyZAIN1t5CbTAop uTGCANK5W/kN0KZb35vAJsLkxnQLpyDKWUuHzUqAjGCdYiPtMyuAqPNuit6r8W8se6rO MCFf15Yk+GyUfcX3gvTlSIQjdmBkU13BbmPBXhIHIgfJY6xcjblInk08LEHcBcp1heyg Fe5Fslx5Ig1z717V3SCG/3Pf3OpkwA8KoK2caO5qm1auOzCJjLQFLJrSWmuZc8uNW6Qp fWmg== Received: by 10.50.12.169 with SMTP id z9mr1908848igb.40.1355411289288; Thu, 13 Dec 2012 07:08:09 -0800 (PST) Received: by 10.50.12.169 with SMTP id z9mr1908838igb.40.1355411289176; Thu, 13 Dec 2012 07:08:09 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id fa6sm1417819igb.2.2012.12.13.07.08.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 07:08:08 -0800 (PST) Message-ID: <50C9EF56.5050204@umn.edu> Date: Thu, 13 Dec 2012 09:08:06 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jon Mitchell References: <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> <50C94133.9060805@umn.edu> <20121213140913.GA4524@puck.nether.net> In-Reply-To: <20121213140913.GA4524@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmuv9lmYeOqNNqC2dDnlx5yVwW+uWmsZus5Tt4VnnX3e4Q4PKAOwS5yLtR57hmAXOyGNhGlqYxipzrVcyP9qXnGduh+STHnHYCQDxFzATC+ctb4FRBnf7rRoGYiQShn/NzJX7JA Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:08:21 -0000 Thanks for the excellent reference. With that, I think keeping the current title and using the term "private use" in most of instances is appropriate. However, I'd would like to suggest the phrase "local or private use" be used in the first sentence of the abstract and introduction sections, keeping "private use" only elsewhere. And, I think it would be great if you could add the reference below in the first sentence of the introduction as well. Pulling something out of my other message, I think adding "by replacing Section 10 in its entirety." to the end of the abstract clarifies how this draft intends to updates RFC 1930. Thanks On 12/13/12 08:09 , Jon Mitchell wrote: > > Maybe I can assist with the definition... RFC1930 was writen a long time > ago, but clearly in Section 10 it does say these are for private use. > This is reconfirmed by RFC5226 definition of Private Use is what is > being used in the draft, not a common language dictionary entry, here is > the section text: > > 4.1. Well-Known IANA Policy Definitions > > > The following are some defined policies, some of which are in use > today. These cover a range of typical policies that have been used > to date to describe the procedure for assigning new values in a > namespace. It is not required that documents use these terms; the > actual requirement is that the instructions to IANA are clear and > unambiguous. However, use of these terms is RECOMMENDED where > possible, since their meaning is widely understood. > > Private Use - For private or local use only, with the type and > purpose defined by the local site. No attempt is made to > prevent multiple sites from using the same value in > different (and incompatible) ways. There is no need for > IANA to review such assignments (since IANA does not record > them) and assignments are not generally useful for broad > interoperability. It is the responsibility of the sites > making use of the Private Use range to ensure that no > conflicts occur (within the intended scope of use). > > Examples: Site-specific options in DHCP [DHCP-IANA], Fibre > Channel Port Type Registry [RFC4044], Exchange Types in the > IKEv2 header [RFC4306]. > > > On Wed, Dec 12, 2012 at 08:45:07PM -0600, David Farmer wrote: >> On 12/12/12 20:28 , Jakob Heitz wrote: >>> We all know what a private ASN is. "Local" is an overused word >>> devoid of meaning. If it ain't broke, don't fix it. >>> >>> On , David Farmer <> wrote: >>> >>>> On 12/12/12 15:07 , Christopher Morrow wrote: >>>>> On Wed, Dec 12, 2012 at 4:03 PM, Jared Mauch >>>>> wrote: >>>>>> >>>>>> On Dec 12, 2012, at 3:22 PM, Christopher Morrow wrote: >>>>>> >>>> ... >>>>>> b) leak "private" space without explicit configurations to enable >>>>>> said action. >>>>> >>>>> 'what is private' ? >>>> >>>> This got me thinking, why are we calling them "private" anyway? >> >> Ok, then you answer Chris' question. That was my answer. >> >> I'll only add "private" seems an equally overused word and equally >> devoid of meaning especially in this context. And, you may not >> think it is broke, but some people on the list seem to think it is >> broken. So, maybe we should fix the brokenness, rather than >> propagating the brokenness. >> >> -- >> ================================================ >> David Farmer Email: farmer@umn.edu >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 1-612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 >> ================================================ >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer@umn.edu Thu Dec 13 08:47:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8321F871D for ; Thu, 13 Dec 2012 08:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3ESGyham021 for ; Thu, 13 Dec 2012 08:47:56 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5946221F871F for ; Thu, 13 Dec 2012 08:47:56 -0800 (PST) Received: from mail-ia0-f198.google.com (mail-ia0-f198.google.com [209.85.210.198]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 13 Dec 2012 10:43:46 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f198.google.com [209.85.210.198] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f198.google.com with SMTP id m10so5114931iam.1 for ; Thu, 13 Dec 2012 08:43:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=jwmipQR6swEC5pj4S/W7Vy/h3mvS/1kNVkX+bwxCHsY=; b=YP7IfE+QsiJgCkTelh11mke1cg9VIZ9B9tGcf9qf4L0PNXe5ODq+3hJ9B4S7wCPEyN cMtDssnC4VLS5JuoaZ0iVWgIQ+Fsvs4WEZTzkzRY27OdaGblEGpSsa/H+Zi7Yj0G3hRM xo0wWmk8u50KkqubSu70L8i6fYESjnT9OoTdmI1VCuQM2QskB2gzRTytH9geSImTpCJL Xo6iEBssfXjomnG8Mb4scbfXLVVR2HUQ2+U9D72xToUkn5ky+TBSTPpDd7EedCQfKsrC s0ccrONNkS2aPIhZyGcEkga4z5MvA2sXdJ+7V469Us7NKVO79FNKis2FOYdX2Ruv9axj GJMw== Received: by 10.50.194.196 with SMTP id hy4mr2249624igc.52.1355417026319; Thu, 13 Dec 2012 08:43:46 -0800 (PST) Received: by 10.50.194.196 with SMTP id hy4mr2249602igc.52.1355417025968; Thu, 13 Dec 2012 08:43:45 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id s20sm1607459igs.10.2012.12.13.08.43.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 08:43:44 -0800 (PST) Message-ID: <50CA05BE.9010905@umn.edu> Date: Thu, 13 Dec 2012 10:43:42 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Nick Hilliard References: <50C9AACF.1010201@foobar.org> In-Reply-To: <50C9AACF.1010201@foobar.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQntPMdQDpZRptZ8uk9PTEqsYbksrzP37bOEAWOfO8ePx0tsVkmPH9/tPRtrM64++Ztn3/xlmVpthoNQ4mGfufVOQmtJZquElibZGxHv7/pxNUBatxKjOlInb+1CXkQYiL+qfodg Cc: idr wg , Robert Raszuk Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:47:57 -0000 On 12/13/12 04:15 , Nick Hilliard wrote: > On 13/12/2012 00:23, Robert Raszuk wrote: >> After second thought I think (and TLI states it as obvious) long term >> we need much more hierarchical AS_PATH where the real AS will have a >> freedom to assign subordinates ,,, > > Forgive my ignorance, but I don't what you're getting at here. Can you > explain? ASN deployment has always been piecemeal, and ASNs bitfields have > never been part of any routing discrimination mechanism. Are you proposing > to change this, and if so, why? I'm glad the conversion came back around to this, I've been thinking about a straw-man for ASN hierarchy ever since TLI brought the issue up a couple weeks ago. Here is my straw-man for ASN hierarchy; Create a new BGP atribute, call it ASN-Partition or something like that. It would have to be transitive, but local significance within an ASN. It would contain an 4-byte ASN and ANS-Partition identifier, maybe implement it as a extended community. But, then modify the loop detection algorithm, if a loop is found in the AS-Path attribute using the classic algorithm, further check if there is an ASN and ASN-Partition tuple for your ASN-Partition, and only then treat as a loop, otherwise don't. Also ASN-Partition would have to be part of neighbor negotiation. Using eBGP rules between neighbors of different ASN-Partitions within the same ASN, and iBGP rules between neighbors of the same ASN-Partition. This would need a lot more work and thinking through, I'm not sure it doesn't encourage excessive attribute bloat, or that its not just another version of confederations, or something, and the code implementation is a lot more complicated than adding an additional 4-byte private ASN range. However, there could be several use cases, the obvious ones of BGP-VPNs and the Data Center stuff being talked about. But, there could be some interesting big-I use cases too, that people use the "allow-in" and other hacks to implement now. Basically we could create a much less hackish way of bypassing normal loop detection. At least that is my idea. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From mohan.nanduri@gmail.com Thu Dec 13 09:46:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76D621F8807 for ; Thu, 13 Dec 2012 09:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab-mX+jZV-ab for ; Thu, 13 Dec 2012 09:46:00 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE621F86C8 for ; Thu, 13 Dec 2012 09:46:00 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so1630091pad.31 for ; Thu, 13 Dec 2012 09:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qaDZDYGYC8zfyhboCp0kVT/mwX2GdVRbQbgfY75oOaQ=; b=bKapJ1z+lQJiWom2uUwJsQLWu6g4reF0IzQ5hCLyEpwKKbfAb7BTC4HwEIOXV/6qgh uBbghJWrOOZxqDoUOFMJBW7orOfRW9eMQanS/fbSzS6xjAtsge/wo8xL2/UY8Jw7nREC dSJRNL6K4zlJnZOxwAOjX6k/ARjl42133VZtZWMZ8b6ekb4wbOkiSNfsjNE50PsX3Mt3 4BG5AGUhCOJTIAPnChkWDfSD1bdNPR1M6WrcdnR42zoxZolCsiv8S+S2F5fj3bxX/8bD Sb05KP2qLemRKGDom2rNF76gMa2dN3br0PD94LMsUzJVhgcUQ4Oe15BfEqj7jehonSFn p7HQ== MIME-Version: 1.0 Received: by 10.68.237.6 with SMTP id uy6mr7373170pbc.147.1355420760107; Thu, 13 Dec 2012 09:46:00 -0800 (PST) Received: by 10.68.25.5 with HTTP; Thu, 13 Dec 2012 09:45:59 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 12:45:59 -0500 Message-ID: From: Mohan Nanduri To: John Scudder Content-Type: multipart/alternative; boundary=047d7b33d58ced6a2f04d0bf7c9c Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:46:00 -0000 --047d7b33d58ced6a2f04d0bf7c9c Content-Type: text/plain; charset=ISO-8859-1 +1 Support. Cheers, -Mohan On Wed, Nov 28, 2012 at 4:26 PM, John Scudder wrote: > Folks, > > We have received a request for a working group last call on > draft-ietf-idr-as-private-reservation-00. A URL for the draft is > http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 > > Please send comments to the list by December 14. [*] > > Thanks, > > --John > > [*] Unless the world ends on December 12, in which case send them by > December 12. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b33d58ced6a2f04d0bf7c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 Support.

Cheers,
-Mohan


= On Wed, Nov 28, 2012 at 4:26 PM, John Scudder <jgs@juniper.net> wrote:
Folks,

We have received a request for a working group last call on draft-ietf-idr-= as-private-reservation-00. A URL for the draft is ht= tp://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00

Please send comments to the list by December 14. [*]

Thanks,

--John

[*] Unless the world ends on December 12, in which case send them by Decemb= er 12.
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b33d58ced6a2f04d0bf7c9c-- From jsw@inconcepts.biz Thu Dec 13 09:57:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9112421F8AE5 for ; Thu, 13 Dec 2012 09:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5JpfpgT4fv7 for ; Thu, 13 Dec 2012 09:57:19 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id CFDEE21F8A53 for ; Thu, 13 Dec 2012 09:57:19 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so2289274iad.13 for ; Thu, 13 Dec 2012 09:57:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zZTMrxh40mryVfLBiFRnv984Zpd4nC/DAc6fWjEMGx0=; b=HANQK/gBJ5IkxCHyLsbYffnnjECZfnxC7ZJyGAqmG3kwNlJs9ppZkjJU/MU1BjYUAR KbYScJCl48T0j0NqVRxfiN4JM5DAc5uvBvK+t1NZb0YPUYF1kd8Hnpq0xu0riMPlEwCU fP/BumFfqlPnXmgadL59hiCYAf1NdtTn58OZi9WI70QkfWfnbMMV4t6lfZHf3C/X0+dv yM++AbdYT231+8Pt+P2XBx0AlUG9LQUw9U/1Pz/njZWMPX16KOTIzEkHMBhe3mTRzUZX m2rpXJw4KBIV7jns1+I0AXDaTSLaj/4P+kxiNqEStTRgtAoKBHSRYW1o9xW860TnI55K GqZQ== MIME-Version: 1.0 Received: by 10.50.220.166 with SMTP id px6mr17596823igc.8.1355421439010; Thu, 13 Dec 2012 09:57:19 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 13 Dec 2012 09:57:18 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <50CA05BE.9010905@umn.edu> References: <50C9AACF.1010201@foobar.org> <50CA05BE.9010905@umn.edu> Date: Thu, 13 Dec 2012 12:57:18 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnJZ4NJalmVjJM6o6zwpQKbyuXeS1M4BAr/mp93BUGBpucsXjNSeL31bsc+hb2YzPXR14Fl Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:57:20 -0000 On Thu, Dec 13, 2012 at 11:43 AM, David Farmer wrote: > But, then modify the loop detection algorithm, if a loop is found in the > AS-Path attribute using the classic algorithm, further check if there is an > ASN and ASN-Partition tuple for your ASN-Partition, and only then treat as a > loop, otherwise don't. I read your post a few times but I do not understand. Could you give an example? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From tony.li@tony.li Thu Dec 13 10:08:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696F021F8A99 for ; Thu, 13 Dec 2012 10:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTJ1e68IKfsy for ; Thu, 13 Dec 2012 10:08:34 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9579121F8A88 for ; Thu, 13 Dec 2012 10:08:34 -0800 (PST) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta01.emeryville.ca.mail.comcast.net with comcast id b2R31k0090b6N64A168aBZ; Thu, 13 Dec 2012 18:08:34 +0000 Received: from [IPv6:2001:420:301:1004:2cc9:b6e7:d0fc:2a82] ([IPv6:2001:420:301:1004:2cc9:b6e7:d0fc:2a82]) by omta03.emeryville.ca.mail.comcast.net with comcast id b68Z1k0080hQ2Wr8P68an0; Thu, 13 Dec 2012 18:08:34 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 13 Dec 2012 10:08:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <67188419-7DAE-4C96-8171-BEB91097A91C@tony.li> References: <50C9AACF.1010201@foobar.org> <50CA05BE.9010905@umn.edu> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355422114; bh=uLf6wJyF6/KOPeeK8YQwjbsTJeaE/bucD4PDhuqP14I=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=UUgGEbfZOzTWR3Kg7zyfIxKVFy7azXZ2Y/nnCDA26Nd05ARhWjVwCTavLot0aadWX MJV7/aGIFkSdJAgytplsDX+xh+4/lIAAJ7QG0tQPV7/I9KjYFvWFMZoslJo3QYxz72 CuPeleh+Tak0wmMaIB9sLtjf1UQxhwnCdmy93aamUArl3WQwlvzNJKyIg3n7yRm82X 4T3/viH7l4FNrRrO2V60t8cN5O+g+SpeCSdjdF7AoE6BwYmKGuyui87Cj1D9ftGviI keuJxGX01NUKkrXLmU8hG0PIxNOVNkkyNVNpsVgJHHRlgLyXCAbo7zKwN5774eB81e 60i795tif4/Kw== Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:08:35 -0000 On Dec 13, 2012, at 9:57 AM, Jeff Wheeler wrote: > On Thu, Dec 13, 2012 at 11:43 AM, David Farmer wrote: >> But, then modify the loop detection algorithm, if a loop is found in = the >> AS-Path attribute using the classic algorithm, further check if there = is an >> ASN and ASN-Partition tuple for your ASN-Partition, and only then = treat as a >> loop, otherwise don't. >=20 > I read your post a few times but I do not understand. Could you give > an example? I'm not convinced that this is necessary. While hierarchy for = allocation and assignment seems useful, why not retain a flat approach = for loop detection? Tony From farmer@umn.edu Thu Dec 13 12:27:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2A521F8B13 for ; Thu, 13 Dec 2012 12:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD7MM7V-53Yt for ; Thu, 13 Dec 2012 12:27:07 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 46DE421F898B for ; Thu, 13 Dec 2012 12:27:02 -0800 (PST) Received: from mail-ia0-f198.google.com (mail-ia0-f198.google.com [209.85.210.198]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 13 Dec 2012 14:26:55 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f198.google.com [209.85.210.198] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f198.google.com with SMTP id m10so5774341iam.1 for ; Thu, 13 Dec 2012 12:26:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=xjknhXhSjQweqTfjQ7efpUAg3Z0EISUWUZ63J8efNGU=; b=BkujRzAU/7qnPe+HdLUgx9F4qYFc7yMX3JO0Fv1yUOtf8QRpyzB42Igq0rKWSAmey1 +FzWXObKYoRD1QYMM1AqVlUE4Su7efpuQr403lUdVn2ay/p3qJhWIKhRbg4WRT6//6pj v/SETK68RlLX7+UzZ9HTGCictn5FmZNR8CdiqbNbuu9/XmuiIANPvRTX7qPMgl1BqN8g BlAKwsqfggX8vUcHHLAVsBXz1ZXtFJmJYvgLcUbngI6YZQzP6hAK097NI6urjQfq//BY hjFOqfWsMwZCn6Oir0WvQuxMd7wLeDWDEks/tfV+L4hncGxQeOO7yDdlhDlpww3frhMN rSdg== Received: by 10.42.212.4 with SMTP id gq4mr2628233icb.38.1355430415514; Thu, 13 Dec 2012 12:26:55 -0800 (PST) Received: by 10.42.212.4 with SMTP id gq4mr2628225icb.38.1355430415356; Thu, 13 Dec 2012 12:26:55 -0800 (PST) Received: from [172.19.131.172] ([199.106.165.165]) by mx.google.com with ESMTPS id vq4sm5043932igb.10.2012.12.13.12.26.51 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 12:26:53 -0800 (PST) References: <50C9AACF.1010201@foobar.org> <50CA05BE.9010905@umn.edu> <67188419-7DAE-4C96-8171-BEB91097A91C@tony.li> In-Reply-To: <67188419-7DAE-4C96-8171-BEB91097A91C@tony.li> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8803BFAA-DB14-4BEA-8329-F7FCF33330D0@umn.edu> X-Mailer: iPad Mail (10A523) From: David Farmer Date: Thu, 13 Dec 2012 14:26:51 -0600 To: Tony Li X-Gm-Message-State: ALoCoQnWBVs0GP2ukJ8hHzIALKk/ufc+zoKn/5MsFP65svWZg68tg43S6fA9DH+8ff8/ehSoVxViX08lOdumxBp7M9jSQDLuV/Lyu2V+TVqXPozuW6vIfSe9eVAGFR+yWLfNao9RbBqO Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:27:08 -0000 On Dec 13, 2012, at 12:08, Tony Li wrote: >=20 > On Dec 13, 2012, at 9:57 AM, Jeff Wheeler wrote: >=20 >> On Thu, Dec 13, 2012 at 11:43 AM, David Farmer wrote: >>> But, then modify the loop detection algorithm, if a loop is found in the= >>> AS-Path attribute using the classic algorithm, further check if there is= an >>> ASN and ASN-Partition tuple for your ASN-Partition, and only then treat a= s a >>> loop, otherwise don't. >>=20 >> I read your post a few times but I do not understand. Could you give >> an example? >=20 > I'm not convinced that this is necessary. While hierarchy for allocation a= nd assignment seems useful, why not retain a flat approach for loop detectio= n? >=20 > Tony Because this approach allows a discontinuous AS to appear as a single AS to t= he outside world and even its L3VPN providers. Example, all of the sites of= an enterprise could use the same public ASN and each use a separate AS-Part= ition identifier. Peering with one or more L3VPN provider backbones and even= getting Internet connectivity locally at a site from there L3VPN provider o= r separate ISP if they wish. This approach allows for arbitrarily complicat= ed topologies that happen when you select from multiple L3VPN providers or I= SPs simultaneously per site based on multiple competitive factors and/or red= undancy needs for each site. And, I believe you wouldn't need to resort to t= he Allow-In or Remove-Private-AS hacks. Basically this allows an ASN to be d= iscontinuous between between AS-Partitions but not within a partition. Yes, that violates the classic view of an ASN, but that classic view is an o= ut dated anachronism with a lot of the new uses for BGP are taken into accou= nt. And, we are using hacks like Allow-In or Remove-Private-AS hacks to mak= e strange groups of BGP clouds look like they are classic ASNs. Lets just a= dmit there are new kinds of critters in the zoo today. Hope that helps, but like I said this is a straw-man and I'm not sure he has= all his arms and legs yet. :) --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From jrmitche@puck.nether.net Thu Dec 13 13:07:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0BE21F8B96 for ; Thu, 13 Dec 2012 13:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVB34nS1HaJE for ; Thu, 13 Dec 2012 13:07:39 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4430A21F8B92 for ; Thu, 13 Dec 2012 13:07:39 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBDL7bEp000415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 16:07:37 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBDL7bwp000414; Thu, 13 Dec 2012 16:07:37 -0500 Date: Thu, 13 Dec 2012 16:07:37 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121213210737.GA23120@puck.nether.net> References: <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> <50C94133.9060805@umn.edu> <20121213140913.GA4524@puck.nether.net> <50C9EF56.5050204@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50C9EF56.5050204@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 13 Dec 2012 16:07:37 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:07:40 -0000 On Thu, Dec 13, 2012 at 09:08:06AM -0600, David Farmer wrote: > Thanks for the excellent reference. > > With that, I think keeping the current title and using the term > "private use" in most of instances is appropriate. However, I'd > would like to suggest the phrase "local or private use" be used in > the first sentence of the abstract and introduction sections, > keeping "private use" only elsewhere. And, I think it would be > great if you could add the reference below in the first sentence of > the introduction as well. I think the use of "local" has a less exact definition (local to what) and don't feel this adds significant value to the draft. Further, I think the motivation paragraph saying this is for a single organization addresses the scope that private ASNs are meant to have already (as well as many of the concerns expressed about people using this for ISP customers which I'm not sure could be called the same organization by any definition as the entity allocating the ASNs). All other parts of the draft appear to use the term "private use" consistently. > > Pulling something out of my other message, I think adding "by > replacing Section 10 in its entirety." to the end of the abstract > clarifies how this draft intends to updates RFC 1930. I think this adds clarity on what parts of RFC 1930 this impacts and am willing to make this change to the abstract. I don't think this represents an actual content change to the draft however... Jon > > Thanks > From brian.peter.dickson@gmail.com Thu Dec 13 13:16:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2879E21F8BB9 for ; Thu, 13 Dec 2012 13:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtnLn8wTRcs6 for ; Thu, 13 Dec 2012 13:16:55 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D028821F8B59 for ; Thu, 13 Dec 2012 13:16:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so987969eaa.31 for ; Thu, 13 Dec 2012 13:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EP6tTYH8fBd27D5/tpqJ/pC4oSf4MIlYiQZhhxNCqqU=; b=A7lmcntnafJGkAMhK44PIse/EzsRHbFKYJGBkkEPJHbXtp/cdYYDiCcxoVeonymTYT EFjzOnrQqZduFRtNbAV6Hu7cjFsc8DPZwjFCezAG9q1XYU85iavZmphI4iQj+8RrKHWI FnIgYaa45CcE2urw843wVVL6264h1RpGiH7u3qITUCC1i+7Yt8sfq/FepelFvNMkDMLW fANIDJ7ndFAQ+JWLfTzcHRQk4zVOE/SWWsmrae/xIET3e1EWRm19c2tRrUEn7bPcotGh m/reDq+zr6dY8NtGiMTEd22ECAMe3uNIw/lTnFIoPsGIZZ6CEsc2YtYSo+XDsW6LlbIR vybg== MIME-Version: 1.0 Received: by 10.14.0.71 with SMTP id 47mr8600449eea.19.1355433413918; Thu, 13 Dec 2012 13:16:53 -0800 (PST) Received: by 10.223.173.199 with HTTP; Thu, 13 Dec 2012 13:16:53 -0800 (PST) In-Reply-To: <20121213210737.GA23120@puck.nether.net> References: <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> <50C94133.9060805@umn.edu> <20121213140913.GA4524@puck.nether.net> <50C9EF56.5050204@umn.edu> <20121213210737.GA23120@puck.nether.net> Date: Thu, 13 Dec 2012 16:16:53 -0500 Message-ID: From: Brian Dickson To: Jon Mitchell Content-Type: multipart/alternative; boundary=047d7b66f329273f9204d0c26f8a Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:16:56 -0000 --047d7b66f329273f9204d0c26f8a Content-Type: text/plain; charset=ISO-8859-1 Given that 1930 has defined Private Use, maybe instances of either of the two lower-case terms ("private use" or "local") could be replaced with mixed-case "Private Use"? It is not as aesthetically pleasing, but it removes ambiguity, IMHO, as most folks are (I hope) familiar enough with Defined Terms having Special Meaning. :-) Just my $0.02. Brian On Thu, Dec 13, 2012 at 4:07 PM, Jon Mitchell wrote: > On Thu, Dec 13, 2012 at 09:08:06AM -0600, David Farmer wrote: > > Thanks for the excellent reference. > > > > With that, I think keeping the current title and using the term > > "private use" in most of instances is appropriate. However, I'd > > would like to suggest the phrase "local or private use" be used in > > the first sentence of the abstract and introduction sections, > > keeping "private use" only elsewhere. And, I think it would be > > great if you could add the reference below in the first sentence of > > the introduction as well. > > I think the use of "local" has a less exact definition (local to what) > and don't feel this adds significant value to the draft. Further, I > think the motivation paragraph saying this is for a single organization > addresses the scope that private ASNs are meant to have already (as well > as many of the concerns expressed about people using this for ISP > customers which I'm not sure could be called the same organization by > any definition as the entity allocating the ASNs). All other parts of > the draft appear to use the term "private use" consistently. > > > > > Pulling something out of my other message, I think adding "by > > replacing Section 10 in its entirety." to the end of the abstract > > clarifies how this draft intends to updates RFC 1930. > > I think this adds clarity on what parts of RFC 1930 this impacts and am > willing to make this change to the abstract. I don't think this > represents an actual content change to the draft however... > > Jon > > > > > > Thanks > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b66f329273f9204d0c26f8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that 1930 has defined Private Use, maybe instances of either of the t= wo lower-case terms ("private use" or "local") could be= replaced with mixed-case "Private Use"?

It is= not as aesthetically pleasing, but it removes ambiguity, IMHO, as most fol= ks are (I hope) familiar enough with Defined Terms having Special Meaning. = :-)

Just my $0.02.

Brian

On Thu, Dec 13, 2012 at 4:07 PM, Jon Mitchell <jrmitche@puck.nether.net> wrote:
On Thu, Dec 13, 2012 at 09= :08:06AM -0600, David Farmer wrote:
> Thanks for the excellent reference.
>
> With that, I think keeping the current title and using the term
> "private use" in most of instances is appropriate. =A0Howeve= r, I'd
> would like to suggest the phrase "local or private use" be u= sed in
> the first sentence of the abstract and introduction sections,
> keeping "private use" only elsewhere. =A0And, I think it wou= ld be
> great if you could add the reference below in the first sentence of > the introduction as well.

I think the use of "local" has a less exact definition (loc= al to what)
and don't feel this adds significant value to the draft. =A0Further, I<= br> think the motivation paragraph saying this is for a single organization
addresses the scope that private ASNs are meant to have already (as well as many of the concerns expressed about people using this for ISP
customers which I'm not sure could be called the same organization by any definition as the entity allocating the ASNs). =A0All other parts of the draft appear to use the term "private use" consistently.

>
> Pulling something out of my other message, I think adding "by
> replacing Section 10 in its entirety." to the end of the abstract=
> clarifies how this draft intends to updates RFC 1930.

I think this adds clarity on what parts of RFC 1930 this impacts and = am
willing to make this change to the abstract. =A0I don't think this
represents an actual content change to the draft however...

Jon


>
> Thanks
>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b66f329273f9204d0c26f8a-- From brian.peter.dickson@gmail.com Thu Dec 13 13:18:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E6721F8810 for ; Thu, 13 Dec 2012 13:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsD3net-6jwQ for ; Thu, 13 Dec 2012 13:18:27 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1238321F86FD for ; Thu, 13 Dec 2012 13:18:26 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1588534eek.31 for ; Thu, 13 Dec 2012 13:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fzvvChVDAERSlw//ivll0ouVu2BqR1gBpPi8EgwUWY8=; b=jg6NgTSa8UtXfgxqROza4cIzxoPo/MRQ2aza+oNZJKi0xTulRrdkZN/CnOWK0qCiM2 gnbDT//Aip0F86t/S4CGgZ+96d9cS6gEh7G0a/CDezzWdEFz78bi+xf0HQ+0/dVV3ZIE 3UemDhct7LctHyL0VQ3WYpV/MsE8HF//ueevrzdKa7koODt84vQux7anXRTZVUNBooLE xo0oNY1USjiPAnc5lt5SCRltMWn3xti86bLlNT6g9O6VYqOLXTsg3epWzWjD+IGqZkei gUPsZR/f0cUfD8SXeNI0xb8R5MCsBoMzeBgnxKPKtH2d19qOMfbMLkK7Gu7s0d8KK5xq XTKg== MIME-Version: 1.0 Received: by 10.14.184.134 with SMTP id s6mr8512920eem.43.1355433506188; Thu, 13 Dec 2012 13:18:26 -0800 (PST) Received: by 10.223.173.199 with HTTP; Thu, 13 Dec 2012 13:18:26 -0800 (PST) In-Reply-To: <50C90126.3010104@umn.edu> References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C8C491.4040705@foobar.org> <50C90126.3010104@umn.edu> Date: Thu, 13 Dec 2012 16:18:26 -0500 Message-ID: From: Brian Dickson To: David Farmer Content-Type: multipart/alternative; boundary=047d7b3a7ff8a72c4704d0c274fe Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:18:31 -0000 --047d7b3a7ff8a72c4704d0c274fe Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 12, 2012 at 5:11 PM, David Farmer wrote: > On 12/12/12 12:52 , Brian Dickson wrote: > >> Okay, in as-plain, here goes: >> >> 42781900[8-9]? | \ >> 4278190[1-9]?? | \ >> 427819[1-9]??? | \ >> 4278[2-9]????? | \ >> 4279?????? | \ >> 428??????? | \ >> > > Just a thought, couldn't you eliminate the rest with the following > shortcut; > > 429??????? > > Doh! (). Good point, good catch, and yes, you are right. It also makes the one-liner regexp that has the form "42(something)" a lot simpler (and easier to debug). Brian > Yes, it would match 4294967295 which is not part of the range, but it is > reserved for other reasons, and shouldn't be seen in the wild at all, Big I > or little i. And, would match ASNs bigger than 2^32 which can't exist. So > unless some implemented there regexp library in a vary weird way, you are > down to 7 lines. Yes, its cheating a little, but so what. > > > 429[0-3]?????? | \ >> 4294[0-8]????? | \ >> 42949[0-5]???? | \ >> 429496[0-6]??? | \ >> 4294967[0-1]?? | \ >> 42949672[0-8]? | \ >> 429496729[0-4] >> >> In fix-width, and wrapped so one-per-line, and using "hyphen" even for >> consecutive digits, it lines up nicely (so you can easily verify >> correctness). >> >> Feel free to use the above (and if you like, credit me :-)). >> >> Again, not too horrible - 13 terms instead of 5 for as-dot, or 7-8 for >> current 16-bit. >> > > So with the shortcut above, you are back to more or less the same length > as the regexp for the original private ASN block. > > Throwing some some version of this discussion is as an appendix might not > be a bad idea, including a regexp for the original private ASN block too. > And, just maybe that could help cut down on some of the leaking. I can't > see how it could possibly make leaking any worse. > > > -- > ==============================**================== > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > --047d7b3a7ff8a72c4704d0c274fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 12, 2012 at 5:11 PM, David F= armer <farmer@umn.edu> wrote:
On 12/12/12 12:52 , Brian Dickson wrote:
Okay, in as-plain, here goes:

42781900[8-9]? | \
4278190[1-9]?? | \
427819[1-9]??? | \
4278[2-9]????? | \
4279?????? | \
428??????? | \

Just a thought, couldn't you eliminate the rest with the following shor= tcut;

429???????


Doh! (<facepalm>).
Good point, good catch, and yes, you are right.

<= /div>
It also makes the one-liner regexp that has the form "42(som= ething)" a lot simpler (and easier to debug).

Brian

=A0
Yes, it would match 4294967295 which is not part of the range, but it is re= served for other reasons, and shouldn't be seen in the wild at all, Big= I or little i. =A0And, would match ASNs bigger than 2^32 which can't e= xist. =A0So unless some implemented there regexp library in a vary weird wa= y, you are down to 7 lines. =A0Yes, its cheating a little, but so what.

429[0-3]?????? | \
4294[0-8]????? | \
42949[0-5]???? | \
429496[0-6]??? | \
4294967[0-1]?? | \
42949672[0-8]? | \
429496729[0-4]

In fix-width, and wrapped so one-per-line, and using "hyphen" eve= n for
consecutive digits, it lines up nicely (so you can easily verify
correctness).

Feel free to use the above (and if you like, credit me :-)).

Again, not too horrible - 13 terms instead of 5 for as-dot, or 7-8 for
current 16-bit.

So with the shortcut above, you are back to more or less the same length as= the regexp for the original private ASN block.

Throwing some some version of this discussion is as an appendix might not b= e a bad idea, including a regexp for the original private ASN block too. = =A0And, just maybe that could help cut down on some of the leaking. I can&#= 39;t see how it could possibly make leaking any worse.


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE =A0 =A0 Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 =A0Cell: 1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

--047d7b3a7ff8a72c4704d0c274fe-- From jgs@juniper.net Thu Dec 13 14:17:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCA521F8B1D for ; Thu, 13 Dec 2012 14:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLWGitH41od1 for ; Thu, 13 Dec 2012 14:17:45 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E471D21F8B1A for ; Thu, 13 Dec 2012 14:17:19 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUMpT745ikM6mO3BIoGOa27Mgeefzg1RP@postini.com; Thu, 13 Dec 2012 14:17:19 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 14:10:53 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 14:10:53 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 14:18:26 -0800 Received: from mail188-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 22:10:52 +0000 Received: from mail188-va3 (localhost [127.0.0.1]) by mail188-va3-R.bigfish.com (Postfix) with ESMTP id 059B820143 for ; Thu, 13 Dec 2012 22:10:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 1 X-BigFish: PS1(zz146fI4015Izz1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1155h) Received: from mail188-va3 (localhost.localdomain [127.0.0.1]) by mail188-va3 (MessageSwitch) id 1355436649454209_28020; Thu, 13 Dec 2012 22:10:49 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.246]) by mail188-va3.bigfish.com (Postfix) with ESMTP id 6B5D0360089 for ; Thu, 13 Dec 2012 22:10:49 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 22:10:48 +0000 Received: from [172.16.13.204] (66.129.224.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 13 Dec 2012 22:10:47 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Thu, 13 Dec 2012 17:04:26 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:17:45 -0000 Folks, It recently came to my attention that the following from RFC 4271 has = been interpreted in at least two different ways: 4.3. UPDATE Message Format ... Path Attributes: ... The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when sent and MUST be ignored when received. Specifically, the disagreement is regarding "when sent". One school of = thought holds that this means "when originated". Another holds that it = means "when originated or propagated." I'm inclined toward the "when originated" interpretation. This is = basically because for transitive attributes, reserved flags aren't good = for much if people go resetting them all the time, just for fun. Thus, = it makes sense to originate the flags as zero, but to transit them as = received.=20 I would like to open an erratum against RFC 4271 to clarify this. Some = proposed text is below. I thought I'd open the floor for discussion = before I file anything. We'd end up discussing it anyway, so this just = saves one step in processing the erratum. Also: even if we don't use my proposed text, it's demonstrably the case = that the text as written is insufficiently clear. Thus we need SOME = erratum to clarify it, to whatever the WG consensus is. Thanks, --John Suggested text: Type: Technical Section: RFC 4271 Section 4.3 Original Text: The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when sent and MUST be ignored when received. Corrected Text: The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when originated. When received, any value MUST be accepted. When a BGP speaker propagates an=20 attribute, it MUST propagate these flags as received. From Donald.Smith@CenturyLink.com Thu Dec 13 14:41:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6497A21F89A0 for ; Thu, 13 Dec 2012 14:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIVl6SqcHEJ3 for ; Thu, 13 Dec 2012 14:41:07 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5E21F8970 for ; Thu, 13 Dec 2012 14:41:07 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id qBDMf6NV013486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 15:41:07 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E0B591E004E; Thu, 13 Dec 2012 15:41:00 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A6C201E004D; Thu, 13 Dec 2012 15:41:00 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id qBDMf0L7006841; Thu, 13 Dec 2012 16:41:00 -0600 (CST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id qBDMexS2006816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 16:40:59 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 15:40:59 -0700 From: "Smith, Donald" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] Low-order attribute flags -- when to zero Thread-Index: AQHN2X+xL2PqhvmIoUeJ+z2/EKYbl5gXUDLF Date: Thu, 13 Dec 2012 22:40:58 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A28926F@PDDCWMBXEX503.ctl.intranet> References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> In-Reply-To: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D0A28926FPDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:41:08 -0000 --_000_68EFACB32CF4464298EA2779B058889D0A28926FPDDCWMBXEX503ct_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com > 4.3. UPDATE Message Format > ... > Path Attributes: > ... > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored w= hen > received. > > Specifically, the disagreement is regarding "when sent". One school= of thought > holds that this means "when originated". Another holds that it mean= s "when origin > ated or propagated." Actually you have some vendors that strictly follow that text. While they IGNORE those bits they always 0 them too (ok that is not quite i= gnoring but I see that vendor's point) Another vendor ignores those bits but propagated them (non-zero). Another vendor depending on code base drops the peering session if those bi= ts are set but sets those bits under special conditions on a different code= base. > > I'm inclined toward the "when originated" interpretation. This is b= asically because > for transitive attributes, reserved flags aren't good for much if p= eople go > resetting them all the time, just for fun. Thus, it makes sense to = originate the > flags as zero, but to transit them as received. > > I would like to open an erratum against RFC 4271 to clarify this. S= ome proposed > text is below. I thought I'd open the floor for discussion before I= file anything. > We'd end up discussing it anyway, so this just saves one step in pr= ocessing > the erratum. > > Also: even if we don't use my proposed text, it's demonstrably the = case that the > text as written is insufficiently clear. Thus we need SOME erratum= to clarify it, > to whatever the WG consensus is. > > Thanks, > > --John > > Suggested text: > > Type: Technical > Section: RFC 4271 Section 4.3 > Original Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored w= hen > received. > Corrected Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when originated. When received= , any > value MUST be accepted. When a BGP speaker propagates an > attribute, it MUST propagate these flags as received. This is acceptable from a RFC pov in my view but there are vendors that wil= l drop the peering session if the lower-order (nible) four bits are set. So= today this breaks stuff. Vendors have been requested to 0 those bits and i= gnore them from a peering pov (ignoring an attribute with those bits set). _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_68EFACB32CF4464298EA2779B058889D0A28926FPDDCWMBXEX503ct_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
= Idr@ietf.org
        https://www.ietf.org/mailman/listinfo/idr
--_000_68EFACB32CF4464298EA2779B058889D0A28926FPDDCWMBXEX503ct_-- From usenet@sxi.dk Thu Dec 13 14:54:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5239121F89A0 for ; Thu, 13 Dec 2012 14:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXl7r99qj2RC for ; Thu, 13 Dec 2012 14:54:04 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0615521F8983 for ; Thu, 13 Dec 2012 14:54:03 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1022846eaa.31 for ; Thu, 13 Dec 2012 14:54:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cspyKlKPHjdS4v6rSy0MqWZq0A8LxNLOL5dQM5GwJHE=; b=DskaJn7WiTc0coeRfnE5M9JR7ib5iEwnxkeyJPHtWxUzn84mN16tu7Zu+p4O+mo7dc PSTmPNBMhxFW95F0T/NZeh7kPuSFBSqp7Y8Ta4ln5pGUV2ymWf3RTNXdOhpAXRfEoHYD 6DMQvXe9a5cLifzzGxtiHaTuz3+/2Lvr/plKQWcz9vl67rqknhD3EnVQCy8Kjumj5GUU 6kSI42BinXYPNGu8NnNZE6K7CgZHwf2BPta3ZF9qF7SM0z3fZ/jjpftfl6yZVN2GOuE/ cqy01zxn/h5tMUJ9d/zp9aU1P+OcHR/bHq9K9zLu7D25cZQdWayyWgtsOhNChLwlJfrk 6Wcw== MIME-Version: 1.0 Received: by 10.14.207.6 with SMTP id m6mr9407419eeo.10.1355439243102; Thu, 13 Dec 2012 14:54:03 -0800 (PST) Received: by 10.14.125.15 with HTTP; Thu, 13 Dec 2012 14:54:02 -0800 (PST) In-Reply-To: <8803BFAA-DB14-4BEA-8329-F7FCF33330D0@umn.edu> References: <50C9AACF.1010201@foobar.org> <50CA05BE.9010905@umn.edu> <67188419-7DAE-4C96-8171-BEB91097A91C@tony.li> <8803BFAA-DB14-4BEA-8329-F7FCF33330D0@umn.edu> Date: Thu, 13 Dec 2012 23:54:02 +0100 Message-ID: From: Allan Eising To: David Farmer Content-Type: multipart/alternative; boundary=047d7b34372c998be704d0c3ca12 X-Gm-Message-State: ALoCoQkzs3irWKnkfQkVjkDwYYsyp99g0Vr0GYxndkmEIpsg1+yCwyMHn+1lcl8DbzDGGRAkYqCv Cc: idr wg , Tony Li Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:54:05 -0000 --047d7b34372c998be704d0c3ca12 Content-Type: text/plain; charset=ISO-8859-1 I must admit I fail to see the benefit of this. I like to see an AS as identifying a common routing policy. While you may have internal private systems, customers and networks that have individual policies, your external policy, the one regarding the on the internet visible ASN is still a common one. I cannot help but feel that trying to communicate internal structures on the internet overcomplicates things, and furthermore tries to communicate information that is not meant to be relayed through BGP. When it comes to routing policy and specifically filtering I fail to see the benefit of this increased complexity. Maybe you could clarify your proposal with a few examples? /Allan Eising On Thu, Dec 13, 2012 at 9:26 PM, David Farmer wrote: > > > > > On Dec 13, 2012, at 12:08, Tony Li wrote: > > > > > On Dec 13, 2012, at 9:57 AM, Jeff Wheeler wrote: > > > >> On Thu, Dec 13, 2012 at 11:43 AM, David Farmer wrote: > >>> But, then modify the loop detection algorithm, if a loop is found in > the > >>> AS-Path attribute using the classic algorithm, further check if there > is an > >>> ASN and ASN-Partition tuple for your ASN-Partition, and only then > treat as a > >>> loop, otherwise don't. > >> > >> I read your post a few times but I do not understand. Could you give > >> an example? > > > > I'm not convinced that this is necessary. While hierarchy for > allocation and assignment seems useful, why not retain a flat approach for > loop detection? > > > > Tony > > Because this approach allows a discontinuous AS to appear as a single AS > to the outside world and even its L3VPN providers. Example, all of the > sites of an enterprise could use the same public ASN and each use a > separate AS-Partition identifier. Peering with one or more L3VPN provider > backbones and even getting Internet connectivity locally at a site from > there L3VPN provider or separate ISP if they wish. This approach allows > for arbitrarily complicated topologies that happen when you select from > multiple L3VPN providers or ISPs simultaneously per site based on multiple > competitive factors and/or redundancy needs for each site. And, I believe > you wouldn't need to resort to the Allow-In or Remove-Private-AS hacks. > Basically this allows an ASN to be discontinuous between between > AS-Partitions but not within a partition. > > Yes, that violates the classic view of an ASN, but that classic view is an > out dated anachronism with a lot of the new uses for BGP are taken into > account. And, we are using hacks like Allow-In or Remove-Private-AS hacks > to make strange groups of BGP clouds look like they are classic ASNs. Lets > just admit there are new kinds of critters in the zoo today. > > Hope that helps, but like I said this is a straw-man and I'm not sure he > has all his arms and legs yet. :) > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b34372c998be704d0c3ca12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I must admit I fail to see the benefit of this.<= /div>
I like to see an AS as identifying a common= routing policy. While you may have internal private systems, customers and= networks that have individual policies, your external policy, the one rega= rding the on the internet visible ASN is still a common one. I cannot help = but feel that trying to communicate internal structures on the internet ove= rcomplicates things, and furthermore tries to communicate information that = is not meant to be relayed through BGP. When it comes to routing policy and= specifically filtering I fail to see the benefit of this increased complex= ity.

Maybe you c= ould clarify your proposal with a few examples?

/Allan Eising

On Thu, Dec 13, 2012 at 9:26 PM, David Farmer <farmer@umn.edu> = wrote:




On Dec 13, 2012, at 12:08, Tony Li <t= ony.li@tony.li> wrote:

>
> On Dec 13, 2012, at 9:57 AM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
>
>> On Thu, Dec 13, 2012 at 11:43 AM, David Farmer <farmer@umn.edu> wrote:
>>> But, then modify the loop detection algorithm, if a loop is fo= und in the
>>> AS-Path attribute using the classic algorithm, further check i= f there is an
>>> ASN and ASN-Partition tuple for your ASN-Partition, and only t= hen treat as a
>>> loop, otherwise don't.
>>
>> I read your post a few times but I do not understand. =A0Could you= give
>> an example?
>
> I'm not convinced that this is necessary. =A0While hierarchy for a= llocation and assignment seems useful, why not retain a flat approach for l= oop detection?
>
> Tony

Because this approach allows a discontinuous AS to appear as a single= AS to the outside world and even its L3VPN providers. =A0Example, all of t= he sites of an enterprise could use the same public ASN and each use a sepa= rate AS-Partition identifier. Peering with one or more L3VPN provider backb= ones and even getting Internet connectivity locally at a site from there L3= VPN provider or separate ISP if they wish. =A0This approach allows for arbi= trarily complicated topologies that happen when you select from multiple L3= VPN providers or ISPs simultaneously per site based on multiple competitive= factors and/or redundancy needs for each site. =A0And, I believe you would= n't need to resort to the Allow-In or Remove-Private-AS hacks. =A0Basic= ally this allows an ASN to be discontinuous between between AS-Partitions b= ut not within a partition.

Yes, that violates the classic view of an ASN, but that classic view is an = out dated anachronism with a lot of the new uses for BGP are taken into acc= ount. =A0And, we are using hacks like Allow-In or Remove-Private-AS hacks t= o make strange groups of BGP clouds look like they are classic ASNs. =A0Let= s just admit there are new kinds of critters in the zoo today.

Hope that helps, but like I said this is a straw-man and I'm not sure h= e has all his arms and legs yet. :)

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE =A0 =A0 =A0 =A0Phone: 612-626-0815
Minneapolis, MN 55414-3029 =A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b34372c998be704d0c3ca12-- From jakob.heitz@ericsson.com Thu Dec 13 14:58:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA11D21F891C for ; Thu, 13 Dec 2012 14:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxXicscamaJs for ; Thu, 13 Dec 2012 14:58:24 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E790E21F880F for ; Thu, 13 Dec 2012 14:58:23 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBDMwNpU002649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 16:58:23 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Dec 2012 17:58:22 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 17:58:22 -0500 From: Jakob Heitz To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] Low-order attribute flags -- when to zero Thread-Index: AQHN2X+35WnO93tFyUutiNTGt3vZBpgXTiwA Date: Thu, 13 Dec 2012 22:58:21 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E11453E@eusaamb109.ericsson.se> References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> In-Reply-To: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:58:24 -0000 Our code stores known attributes in an abstracted fashion and rebuilds them when writing the UPDATE message. It does this explicitly to prevent our peers barfing on bad reserved bits. Unknown optional transitive attributes are retransmitted verbatim. BTW, we ignore those bits on receipt. I think the horse has left the barn. There are routers out there that (mistakenly) barf when receiving those bits as non-zero. If we change the code to propagate the bad bits, we'll suddenly see more sessions resetting. Maybe, you can change your last sentence to: When a BGP speaker propagates an=20 unknown optional transitive attribute, it MUST propagate these flags as received. -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of John Scudder > Sent: Thursday, December 13, 2012 2:04 PM > To: idr@ietf. org > Subject: [Idr] Low-order attribute flags -- when to zero >=20 > Folks, >=20 > It recently came to my attention that the following from RFC=20 > 4271 has been interpreted in at least two different ways: >=20 > 4.3. UPDATE Message Format > ... > Path Attributes: > ... > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. >=20 > Specifically, the disagreement is regarding "when sent". One=20 > school of thought holds that this means "when originated".=20 > Another holds that it means "when originated or propagated." >=20 > I'm inclined toward the "when originated" interpretation.=20 > This is basically because for transitive attributes, reserved=20 > flags aren't good for much if people go resetting them all=20 > the time, just for fun. Thus, it makes sense to originate the=20 > flags as zero, but to transit them as received.=20 >=20 > I would like to open an erratum against RFC 4271 to clarify=20 > this. Some proposed text is below. I thought I'd open the=20 > floor for discussion before I file anything. We'd end up=20 > discussing it anyway, so this just saves one step in=20 > processing the erratum. >=20 > Also: even if we don't use my proposed text, it's=20 > demonstrably the case that the text as written is=20 > insufficiently clear. Thus we need SOME erratum to clarify=20 > it, to whatever the WG consensus is. >=20 > Thanks, >=20 > --John >=20 > Suggested text: >=20 > Type: Technical > Section: RFC 4271 Section 4.3 > Original Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. > Corrected Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when originated. When=20 > received, any > value MUST be accepted. When a BGP speaker propagates an=20 > attribute, it MUST propagate these flags as received. >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From jrmitche@puck.nether.net Thu Dec 13 15:01:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D105221F8B67 for ; Thu, 13 Dec 2012 15:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm-bgZ71iTQg for ; Thu, 13 Dec 2012 15:01:49 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3835221F8B0C for ; Thu, 13 Dec 2012 15:01:49 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBDN0llh014949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 18:00:47 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBDN0llU014948; Thu, 13 Dec 2012 18:00:47 -0500 Date: Thu, 13 Dec 2012 18:00:47 -0500 From: Jon Mitchell To: Brian Dickson Message-ID: <20121213230047.GA12504@puck.nether.net> References: <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> <50C94133.9060805@umn.edu> <20121213140913.GA4524@puck.nether.net> <50C9EF56.5050204@umn.edu> <20121213210737.GA23120@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 13 Dec 2012 18:00:47 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:01:49 -0000 Seems a reasonable change... Jon On Thu, Dec 13, 2012 at 04:16:53PM -0500, Brian Dickson wrote: > Given that 1930 has defined Private Use, maybe instances of either of the > two lower-case terms ("private use" or "local") could be replaced with > mixed-case "Private Use"? > > It is not as aesthetically pleasing, but it removes ambiguity, IMHO, as > most folks are (I hope) familiar enough with Defined Terms having Special > Meaning. :-) > > Just my $0.02. > > Brian > > On Thu, Dec 13, 2012 at 4:07 PM, Jon Mitchell wrote: > > > On Thu, Dec 13, 2012 at 09:08:06AM -0600, David Farmer wrote: > > > Thanks for the excellent reference. > > > > > > With that, I think keeping the current title and using the term > > > "private use" in most of instances is appropriate. However, I'd > > > would like to suggest the phrase "local or private use" be used in > > > the first sentence of the abstract and introduction sections, > > > keeping "private use" only elsewhere. And, I think it would be > > > great if you could add the reference below in the first sentence of > > > the introduction as well. > > > > I think the use of "local" has a less exact definition (local to what) > > and don't feel this adds significant value to the draft. Further, I > > think the motivation paragraph saying this is for a single organization > > addresses the scope that private ASNs are meant to have already (as well > > as many of the concerns expressed about people using this for ISP > > customers which I'm not sure could be called the same organization by > > any definition as the entity allocating the ASNs). All other parts of > > the draft appear to use the term "private use" consistently. > > > > > > > > Pulling something out of my other message, I think adding "by > > > replacing Section 10 in its entirety." to the end of the abstract > > > clarifies how this draft intends to updates RFC 1930. > > > > I think this adds clarity on what parts of RFC 1930 this impacts and am > > willing to make this change to the abstract. I don't think this > > represents an actual content change to the draft however... > > > > Jon > > > > > > > > > > Thanks > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > From farmer@umn.edu Thu Dec 13 15:11:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D281721F8BEC for ; Thu, 13 Dec 2012 15:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqBMeQhwNwPX for ; Thu, 13 Dec 2012 15:11:06 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 32EE421F8A97 for ; Thu, 13 Dec 2012 15:11:06 -0800 (PST) Received: from mail-ia0-f198.google.com (mail-ia0-f198.google.com [209.85.210.198]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 13 Dec 2012 17:10:38 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f198.google.com [209.85.210.198] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f198.google.com with SMTP id m10so6358569iam.1 for ; Thu, 13 Dec 2012 15:10:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ijxL5lGCGmWMNgNz6PZDl0UEMwf0onKqTE23J14a0nQ=; b=dHs+dsA5tB4hirlCzCR/Zh4k2R2YSo5JRlfLkDpdXlgfW7EE0EsiRq2Ff28y7pYns8 7kX0L5nGiKkgq/CvFpiyTf/mQLYG5imAJpYFW0Bz2qAQfU+WvG4YDk1quzkhmxZHTjjP +MTPlgYCIu0MLNxgCumALu9227f43LdR+Wf3LUPT75cczwymArXbUZyaDYD/BCoqaq/S FU+Cq6vjrmnxm+n+brfV9moVOZMKtB8v1MWoToPMEblOCTfdYCmuPaSLe1dzdjNj2eLV uK4O/mT9n3dINcoVLmaW3eh2nXNEyGYSPWgX8OpYaI5M3NgP6hdrWW7yyJnQd7s1ePz5 1fkg== Received: by 10.50.222.166 with SMTP id qn6mr3428688igc.47.1355440237861; Thu, 13 Dec 2012 15:10:37 -0800 (PST) Received: by 10.50.222.166 with SMTP id qn6mr3428675igc.47.1355440237739; Thu, 13 Dec 2012 15:10:37 -0800 (PST) Received: from dhcp-128-146-123-191.osuwireless.ohio-state.edu (dhcp-128-146-123-191.osuwireless.ohio-state.edu. [128.146.123.191]) by mx.google.com with ESMTPS id c3sm106437igj.1.2012.12.13.15.10.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 15:10:36 -0800 (PST) Message-ID: <50CA606B.6070505@umn.edu> Date: Thu, 13 Dec 2012 17:10:35 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jon Mitchell References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> In-Reply-To: <20121213144147.GB4524@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktuoy9BR0Hq8b5t4/kN8GnAGNZKDeL2E0aDQm3KqbkAll9XiYhzgeoDE0U7G4GeGcOLHB4dx27UA2SAvq8n2ftnmOqF42yIGNy9ilT/QNpav/CsSb4fX8q/Vi5ZKjlk+wUeOIG Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:11:07 -0000 On 12/13/12 08:41 , Jon Mitchell wrote: ... > I'm sympathetic to the human recognizable (but not use small or lower > value ranges) and regex arguments to utilize a decimal boundary and the > original draft started there. An alternate proposal that is not as > silly as 4B+ but still does not consume a significant portion of the > total space (if there was widespread concensus in the WG to change the > existing one, given that we are in LC already) could be: > > 4200000000 - 4294967294 > > Although this is even larger than the existing range, it still is a a > very small portion of the existing range, and I think no one is > seriously concerned it's the size of the new range (versus having one) > is concerning as there is no belief that will correlate to any specific > behavior. > > Jon I'm sympathetic to the argument too, even though it may not sound like it. :) But, I can't justify something in the 300M range or even the 100M range in my head. Hey, 10M is a stretch, but given that I can easily come up with scenarios for a few tens of thousands, cranking that up 2 or 3 orders of magnitude means we should have to revisit it for 20 or 30 years. There would be one exception, if we were to require pseudo-random allocation to help facilitate mergers, similar to IPv6 ULA in RFC 4193. Then I could justify a few 100 million in my head, so you get a better spreading function. But nine random digits preceded by a 4 isn't going to be very human friendly either. :( If we did 4B up most everybody is going to just use a few 10 of thousand just above the 4B mark. And I'm not sure 4.2B mark would be any different. Just like most people use 65000-65010 and 65500-65510 and some other combinations in the 1023 we have now. My recommendation is to specify 4280000000-4289999999 for private use, and then suggest to the IESG that they have IANA mark 4278190080-4279999999 and 4290000000-4294967294 as reserved as opposed to unallocated. That gives private use a block of 10M and sets aside some 6M for other future special uses. Who knows what really cool use for million or two ASNs some smart kid will come up with in a few year. :) And if we wanted to provide another smaller but much more human friendly range there is another reserved range at 65552 to 131071, maybe take 100000-129999 out of that range too. We don't want to go into 130K, to help prevent anyone from accidentally going about 131071 and the ranges that the RIRs are using. Then you would have the original 1023, a moderate but mostly human friendly block of 30000, and block of 10000000 that is probably best for programmatic uses. Just throwing out some ideas. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jsw@inconcepts.biz Thu Dec 13 15:39:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AADF21F87F6 for ; Thu, 13 Dec 2012 15:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7dxmZHEw7jy for ; Thu, 13 Dec 2012 15:39:31 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B63CA21F8527 for ; Thu, 13 Dec 2012 15:39:31 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so5021385ieb.31 for ; Thu, 13 Dec 2012 15:39:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iyFXTVuEU43LG89ORIG0RpLgc6a2rhXdwSIVVeHWu/o=; b=FqWzIIBxSwkzz4CNqJpAp7E3ge8VHPUhtdFJUOuUQIoDcK68xxh0nT5u9zGMhqmsFO q3v2cm1/if1Ga+WcuCqlQZM0/VgzAFbysXLW7SgGq1dstI94JUeJlrgdJIlZ7xc+Cq2k TDzQOt+T2ionGAEsjbRibVOgjkpyK8SOUa1eCzJ4YcgKEJ9ofI/GjRe+PpdhGKE65i4a UizMeWzxeieTT6Q1DUECd8GXgySH3/tqlR8O9dc69HoXWgv0iOldrs2geHmpAaLLj/p4 OoBXjz4kHFDJfKmOMtpu3AsSAm9L8vid1hme/aw8VreVL4p37RWquD8NWNzMYf6N7vFC /OvQ== MIME-Version: 1.0 Received: by 10.50.36.200 with SMTP id s8mr3521682igj.23.1355441971323; Thu, 13 Dec 2012 15:39:31 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 13 Dec 2012 15:39:31 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Thu, 13 Dec 2012 18:39:31 -0500 Message-ID: From: Jeff Wheeler To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlWjfudrb81p9QCY7hBYFdIwQDczHTCuTL0DlB/zyxxhuqgn6+mNA41WE4tsSkSAsZAZaz0 Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:39:32 -0000 On Thu, Dec 13, 2012 at 5:04 PM, John Scudder wrote: > Specifically, the disagreement is regarding "when sent". One school of thought holds that this means "when originated". Another holds that it means "when originated or propagated." I'm glad there is some interest in this, because it caused me and others some operational headaches recently. > Original Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. > Corrected Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when originated. When received, any > value MUST be accepted. When a BGP speaker propagates an > attribute, it MUST propagate these flags as received. I wish the flags would be propagated as received. I feel this is correct. However, I can't wrap my head around the leap of logic that makes this a MUST. In one sentence, it is forbidden to originate an attribute with these bits != 0x0. In the same paragraph, you must take care to preserve their value in case they are != 0x0 anyway. IMO if that is to be changed, then the text opens up the door to originating the attribute and then modifying it later by setting these bits, as not being illegal; but it is illegal to set them at origination. How strange is that? I imagine some vendors have got complaints that they didn't zero these bits on propagation. I'm not complaining to my vendor not because of ambiguity, but because my downstream customer's BGP implementation was wrong by not ignoring the bits, and that's as far as I was willing to argue it. If any change, I think MUST be zero when sent =/= SHOULD be zero when sent, and just remove all ambiguity about whether or not these bits may be used for some vendor-private extension or whatever. The change you are proposing essentially has the same affect. $0.02. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From nick@foobar.org Thu Dec 13 15:56:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E30D21F8991 for ; Thu, 13 Dec 2012 15:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 521Ua8TyVjPD for ; Thu, 13 Dec 2012 15:56:30 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C530221F863B for ; Thu, 13 Dec 2012 15:56:29 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:eca1:f237:4141:14ce]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBDNsmiN065206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 23:54:53 GMT (envelope-from nick@foobar.org) Message-ID: <50CA6B25.7020608@foobar.org> Date: Thu, 13 Dec 2012 23:56:21 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Allan Eising References: <50C9AACF.1010201@foobar.org> <50CA05BE.9010905@umn.edu> <67188419-7DAE-4C96-8171-BEB91097A91C@tony.li> <8803BFAA-DB14-4BEA-8329-F7FCF33330D0@umn.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:56:30 -0000 On 13/12/2012 22:54, Allan Eising wrote: > When it comes to routing policy and specifically filtering I fail to see > the benefit of this increased complexity. the proposal also omits the concept of an ASN mask, so I'm guessing it's heading down the direction of classful ASN assignment and we know what a bad idea that is. Or maybe someone wants to suggest an ASN assignment mask? But I think at this stage, reductio ad absurdum has been achieved on this particular suggestion. AS usage is flat and always has been. Changing this would be virtually impossible. Now, can we divert out of this rathole and head back to as-private-reservation again? Nick From jsw@inconcepts.biz Thu Dec 13 16:22:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21F321F8BE5 for ; Thu, 13 Dec 2012 16:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIV-Cr0NR-zb for ; Thu, 13 Dec 2012 16:22:05 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0345D21F8BA7 for ; Thu, 13 Dec 2012 16:22:04 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so5063590ieb.31 for ; Thu, 13 Dec 2012 16:22:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=SBpCteGl6tVOersI633EAjWn7Fcz5BqYL2K+AzIELjo=; b=ioSJelhMSzZgz8AS+9/cn6WkoSbS4xGQiqd61JlA7kHOqmdE+8F3wXsoLpc5sjnOUj FWJ/Lo67+sC5c7kUJs01tm+z0bu5GcxFdRggFDu4J0SFSM3o3uIbccO17/8X/dowHj6g fVaO+qxqtk3URgcDf8RzdaXBdgFWEfcOQAEQfS/g66rNdYApM/jtGZZAS6SD+nKUKaqL XtoXEmUS+mKB+PKGVJwtdDM/fFBacbAJywpaYShvQKwAJO19MVEmH3LfCJlEPGx8Md5s BpAUBXrAUnI++wHbWLlp8q9rwAPdi5o5nmcMdC3JpJh7V/jsPUA0dOVvM4eJfXUf9anR llVg== MIME-Version: 1.0 Received: by 10.50.195.135 with SMTP id ie7mr97016igc.8.1355444524045; Thu, 13 Dec 2012 16:22:04 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 13 Dec 2012 16:22:03 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <8803BFAA-DB14-4BEA-8329-F7FCF33330D0@umn.edu> References: <50C9AACF.1010201@foobar.org> <50CA05BE.9010905@umn.edu> <67188419-7DAE-4C96-8171-BEB91097A91C@tony.li> <8803BFAA-DB14-4BEA-8329-F7FCF33330D0@umn.edu> Date: Thu, 13 Dec 2012 19:22:03 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: multipart/alternative; boundary=14dae9340fcb5e56fd04d0c5050c X-Gm-Message-State: ALoCoQnF/YnQfqBnwvgBM06+osBceiK94A+JANp3eNoVpJWMV0EG10sX4RvLSr4d24+OH26Nok8k Cc: idr wg Subject: Re: [Idr] AS numbers - flat vs hierarchical X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:22:06 -0000 --14dae9340fcb5e56fd04d0c5050c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 13, 2012 at 3:26 PM, David Farmer wrote: > Because this approach allows a discontinuous AS to appear as a single AS I still don't get how you imagine implementing this. Would really like to see an example. The trouble I imagine is, if you need to identify which ASNs in the AS_PATH belong to a given Administrative Domain, it sounds like you propose a new Attribute for this. How will a receiver supporting this capability determine which AS_PATH elements match up with which AD identifier, given that the AS_PATH is being modified en-route by BGP speakers who are not yet aware of this capability? Will the AD identifier count from the end of the AS_PATH (the originating ASN) and define a range? For example: 4474 16631 65000 65001 6461 65000 1239 +----------------+---------------+----------------+----------------+ | flags | type | length = 12 | AD +----------------+---------------+----------------+----------------+ ..AD cont'd VALUE=6461 | offseta = 1 | +----------------+---------------+----------------+----------------+ | span = 1 | AD VALUE=16631 +----------------+---------------+----------------+----------------+ | offseta = 3 | span = 2 | +----------------+--------------------------------+ Above is how I imagine your idea. Every time you need to add one of your Administrative-Domain-specific spans of ASns into the AS_PATH you need to basically push an entry onto this attribute which identifies the globally-unique Administrative Domain (by global ASN) and the offset of that span, from the right of the AS_PATH, as well as the span size (number of ASNs there which are private.) Problem is if someone in the middle, say a DFZ router, strips out what it sees as a "private ASN" then your offsets are all screwed up. I don't imagine this can be assured of not happening because some uninformed router might do almost anything to the path, Maybe you need bounds like "between ASN 1239 and AS 6461" instead? 4474 16631 65000 65001 6461 65000 1239 +----------------+---------------+----------------+----------------+ | flags | type | length = 16 | RESERVED | +----------------+---------------+----------------+----------------+ | private_right=1239 | +----------------+---------------+----------------+----------------+ | private_left=6461 | +----------------+---------------+----------------+----------------+ ... | private_right=6461 | +----------------+---------------+----------------+----------------+ | private_left=16631 | +----------------+---------------+----------------+----------------+ The above encoding gets rid of that problem I suppose, so you just scan the AS_PATH from the right and it will give you the bounds of each group of private ASNs. It assumes the left-most ASN in each bounding-pair identifies the Administrative Domain by its 4-octet ASN. You could add more attributes for that if you didn't want them to be tied to ASN but that seems like a logical place to start. I don't know if this is exactly your idea. I'm not advocating this concept or the above encoding, either. I think you are suggesting something that is unlikely to be implemented. But this is the way I could imagine it working, and it isn't really that HARD to implement it. Please note the RESERVED field above is just for formatting in the email. You can't guarantee a BGP attribute of arbitrary length has its values aligned without adding, or not, a reserved field based on the attribute length, because of the optional Extended Length bit in the attribute flags. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --14dae9340fcb5e56fd04d0c5050c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2012 at 3:26 PM, David Farmer <farmer@umn.edu> wrote:
> Because this approach allows= a discontinuous AS to appear as a single AS

I still don't get h= ow you imagine implementing this. =A0Would really like to see an example.
The trouble I imagine is, if you need to identify which ASNs in the AS_= PATH belong to a given Administrative Domain, it sounds like you propose a = new Attribute for this. =A0How will a receiver supporting this capability d= etermine which AS_PATH elements match up with which AD identifier, given th= at the AS_PATH is being modified en-route by BGP speakers who are not yet a= ware of this capability? =A0Will the AD identifier count from the end of th= e AS_PATH (the originating ASN) and define a range? =A0For example:

4474 16631 65000 65001 6461 65000 1239

+----------------+-------= --------+----------------+----------------+
| flags =A0 =A0 =A0 = =A0 =A0| type =A0 =A0 =A0 =A0 =A0| length =3D 12 =A0 =A0| AD <asn32><= /font>
+----------------+---------------+----------------+----------------+
=A0 ..AD<asn32> cont'd =A0 VALUE=3D6461 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | offseta =3D 1 =A0 =A0|
+----------------+---------------+----------------+----------------+
| span =3D 1 =A0 =A0 =A0 | AD <asn32> VALUE=3D16631
+----------------+---------------+----------------+----------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| offseta =3D 3 =A0 | sp= an =3D 2 =A0 =A0 =A0 |
+----------------+--------------------------------+

Abov= e is how I imagine your idea. =A0Every time you need to add one of your Adm= inistrative-Domain-specific spans of ASns into the AS_PATH you need to basi= cally push an entry onto this attribute which identifies the globally-uniqu= e Administrative Domain (by global ASN) and the offset of that span, from t= he right of the AS_PATH, as well as the span size (number of ASNs there whi= ch are private.)

Problem is if someone in the middle, say a DFZ router, = strips out what it sees as a "private ASN" then your offsets are = all screwed up. =A0I don't imagine this can be assured of not happening= because some uninformed router might do almost anything to the path, =A0Ma= ybe you need bounds like "between ASN 1239 and AS 6461" instead?<= /div>

4474 16631 65000 65001 6461 65000 1239

+--------= --------+---------------+----------------+----------------+
| fl= ags =A0 =A0 =A0 =A0 =A0| type =A0 =A0 =A0 =A0 =A0| length =3D 16 =A0 =A0| R= ESERVED =A0 =A0 =A0 |
+----------------+---------------+----------------+----------------+
| private_right=3D1239 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+----------------+---------------+----------------+----------------+
| private_left=3D6461 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
+----------------+---------------+----------------+----------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 ...
| private_right=3D6461 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+---= -------------+---------------+----------------+----------------+
| private_left=3D16631 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
= = +----------------+---------------+----------------+----------------+=

The above encoding gets rid of that proble= m I suppose, so you just scan the AS_PATH from the right and it will give y= ou the bounds of each group of private ASNs. =A0It assumes the left-most AS= N in each bounding-pair identifies the Administrative Domain by its 4-octet= ASN. =A0You could add more attributes for that if you didn't want them= to be tied to ASN but that seems like a logical place to start.

I don't know if this is exactly your idea.

I'm not advocating this concept or the above encoding,= either. =A0I think you are suggesting something that is unlikely to be imp= lemented. =A0But this is the way I could imagine it working, and it isn'= ;t really that HARD to implement it.

Please note the RESERVED field above is just for format= ting in the email. =A0You can't guarantee a BGP attribute of arbitrary = length has its values aligned without adding, or not, a reserved field base= d on the attribute length, because of the optional Extended Length bit in t= he attribute flags.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator =A0/ =A0Innovati= ve Network Concepts
--14dae9340fcb5e56fd04d0c5050c-- From agmalis@gmail.com Thu Dec 13 14:45:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA521F8B11 for ; Thu, 13 Dec 2012 14:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxZLyFbJ4rk2 for ; Thu, 13 Dec 2012 14:45:23 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5EB21F89A0 for ; Thu, 13 Dec 2012 14:45:23 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so4928262iea.36 for ; Thu, 13 Dec 2012 14:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cnbZS2rnbPEeyJvQDm9nPJNWxkSQjxY4gns9iGWXeP0=; b=KT/1vnSmGJMMPODSYRBvkREh/t9jNjxMIiAcugczmd0RGNo3sp75O0ICSU3CyBpavo 1fvO2smDR321at7+1JGH4Q9y8kdJBa71vLiF8LK9j67+/sy348CgR3kHRBEnm3EiQm2P vSQ4UKebQTN3CTfRZT+WmcsGVI8r5EuFtGt+1YXP5TxqWzB90qpyefb6GSeRY1a3C8C3 SOep+KhtF+RqliNABe4FnPTZSFOcKvNNZIP/C0tEDUIOBpc1Em/eAerLkYfHLFEeJd79 ZjACyo0ssR3xZb9cH07Yylufd+/rPnYlpsUkjdw7UNu1bADWOoXdh7T++X4cRtxreOYa /DbA== Received: by 10.50.12.138 with SMTP id y10mr18356410igb.58.1355438723017; Thu, 13 Dec 2012 14:45:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.51.228 with HTTP; Thu, 13 Dec 2012 14:45:02 -0800 (PST) From: "Andrew G. Malis" Date: Thu, 13 Dec 2012 14:45:02 -0800 Message-ID: To: idr@ietf.org Content-Type: multipart/alternative; boundary=14dae934051799ab7104d0c3ab38 X-Mailman-Approved-At: Thu, 13 Dec 2012 16:50:33 -0800 Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:45:24 -0000 --14dae934051799ab7104d0c3ab38 Content-Type: text/plain; charset=ISO-8859-1 Support - the draft specifies useful functionality. Thanks, Andy -----Original Message----- From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of John Scudder Sent: Thursday, December 06, 2012 2:39 PM To: idr at ietf. org Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Folks, The authors have requested IDR adopt draft-svshah-interdomain-sla-exchange-03 as a working group document. Please send any comments to the list by the Winter Solstice (December 21). Thanks, --John --14dae934051799ab7104d0c3ab38 Content-Type: text/html; charset=ISO-8859-1 Support - the draft specifies useful functionality.

Thanks,
Andy
-----Original Message-----
From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of John Scudder
Sent: Thursday, December 06, 2012 2:39 PM
To: idr at ietf. org
Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03

Folks,

The authors have requested IDR adopt draft-svshah-interdomain-sla-exchange-03 as a working group document.

Please send any comments to the list by the Winter Solstice (December 21).

Thanks,

--John


--14dae934051799ab7104d0c3ab38-- From jgs@juniper.net Thu Dec 13 16:58:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2B21F8510 for ; Thu, 13 Dec 2012 16:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwdL33ibWiaZ for ; Thu, 13 Dec 2012 16:58:04 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id F004421F850D for ; Thu, 13 Dec 2012 16:58:03 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUMp5mx15ero/qdfL8THEb+3ijslBsvvT@postini.com; Thu, 13 Dec 2012 16:58:04 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 16:49:50 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 16:49:49 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 16:57:22 -0800 Received: from mail83-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 00:49:48 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id B2D912C00E0 for ; Fri, 14 Dec 2012 00:49:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zz98dI9371I1102Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275fhz2dh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1355446187207963_26448; Fri, 14 Dec 2012 00:49:47 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id 26BFA440252; Fri, 14 Dec 2012 00:49:47 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 00:49:42 +0000 Received: from hsrinath-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 14 Dec 2012 00:49:41 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "John G. Scudder" In-Reply-To: Date: Thu, 13 Dec 2012 19:49:37 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%INCONCEPTS.BIZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:58:04 -0000 Jeff, On Dec 13, 2012, at 6:39 PM, Jeff Wheeler wrote: > I wish the flags would be propagated as received. I feel this is > correct. However, I can't wrap my head around the leap of logic that > makes this a MUST. In one sentence, it is forbidden to originate an > attribute with these bits !=3D 0x0. In the same paragraph, you must > take care to preserve their value in case they are !=3D 0x0 anyway. Exactly. This was my point in writing "this is basically because for = transitive attributes, reserved flags aren't good for much if people go = resetting them all the time, just for fun", but I see I should have = spent a few more words on the rationale. Basically, reserved flags are only useful if there is some hope of = someday using them for something. If implementations go resetting the = flags, then some future revision to the spec that introduced a new flag = would have no hope of that flag propagating end to end, since it would = be very likely that some well-meaning intermediate router would stomp on = it. The effort to roll out implementations that transited the new flag = would almost certainly be prohibitive. I have no current use for the reserved flags in mind, but I'm hesitant = to throw out a potentially valuable resource for future extension. > IMO if that is to be changed, then the text opens up the door to > originating the attribute and then modifying it later by setting these > bits, as not being illegal; but it is illegal to set them at > origination. How strange is that? Well, "modifying it later" wasn't my intention, and I think also not = permitted by what I wrote. It's true that if some router DID modify it = later, the text I offered would propagate the modified flag. Then again, = see above: maybe that modification would be for a good well-specified = reason.=20 It comes down to a case of "Be conservative in what you send, liberal in = what you accept." --John= From shyam.ioml@gmail.com Thu Dec 13 19:16:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276FF21F8C54 for ; Thu, 13 Dec 2012 19:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0M6skWgaukp for ; Thu, 13 Dec 2012 19:16:53 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B900221F8C51 for ; Thu, 13 Dec 2012 19:16:52 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2367663lbk.31 for ; Thu, 13 Dec 2012 19:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qWJHHHWcPl9REpFxppq7qSoisu7exJSucKmCwd+F65Y=; b=s9Kiy/y7e2cOmqpdxXrCDss061yokExfRHqJeIFPH1FpppgVOp3fVTgBJ/Iaxt7WgH Qmoy5Hp19yuzYRzQJv2D3OYsUD/fD2J10BBQYGO0Jd9hI3zVKwkg6CL7jN9w240DZS5n SOcvBSCBHtiq1QeN17g1BBXN1OnGcVTCL88wqT9Dr0d1gBAv/UMrUlSHP31GxkoKeV/U Hw9yoRkuwDgHN797qV8YkViryglJaYO9Aurca6iUaoZI0OHgkmw9K7j+n92vMYKEYjhN 9PI6/SiD1iAifBfYp8NNIJmNjGpn3joqKfPw0Zw+N0J6i0OhMGb72YIK/0okLqa2aWkV 9ncg== MIME-Version: 1.0 Received: by 10.152.103.99 with SMTP id fv3mr1122631lab.16.1355454460794; Thu, 13 Dec 2012 19:07:40 -0800 (PST) Received: by 10.112.134.38 with HTTP; Thu, 13 Dec 2012 19:07:40 -0800 (PST) In-Reply-To: References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Thu, 13 Dec 2012 19:07:40 -0800 Message-ID: From: Shyam Sethuram To: "John G. Scudder" Content-Type: multipart/alternative; boundary=f46d04071655a5160a04d0c75590 Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:16:54 -0000 --f46d04071655a5160a04d0c75590 Content-Type: text/plain; charset=ISO-8859-1 Unfortunately given the current implementations out there, we'll never be able to introduce a new Flag :( The Neighbor-Complete flag in draft-ietf-idr-optional-transitive-02 is one such example that was nixed because of this. But it is still worth adding the Errata as you said. shyam On Thu, Dec 13, 2012 at 4:49 PM, John G. Scudder wrote: > Jeff, > > On Dec 13, 2012, at 6:39 PM, Jeff Wheeler wrote: > > > I wish the flags would be propagated as received. I feel this is > > correct. However, I can't wrap my head around the leap of logic that > > makes this a MUST. In one sentence, it is forbidden to originate an > > attribute with these bits != 0x0. In the same paragraph, you must > > take care to preserve their value in case they are != 0x0 anyway. > > Exactly. This was my point in writing "this is basically because for > transitive attributes, reserved flags aren't good for much if people go > resetting them all the time, just for fun", but I see I should have spent a > few more words on the rationale. > > Basically, reserved flags are only useful if there is some hope of someday > using them for something. If implementations go resetting the flags, then > some future revision to the spec that introduced a new flag would have no > hope of that flag propagating end to end, since it would be very likely > that some well-meaning intermediate router would stomp on it. The effort to > roll out implementations that transited the new flag would almost certainly > be prohibitive. > > I have no current use for the reserved flags in mind, but I'm hesitant to > throw out a potentially valuable resource for future extension. > > > IMO if that is to be changed, then the text opens up the door to > > originating the attribute and then modifying it later by setting these > > bits, as not being illegal; but it is illegal to set them at > > origination. How strange is that? > > Well, "modifying it later" wasn't my intention, and I think also not > permitted by what I wrote. It's true that if some router DID modify it > later, the text I offered would propagate the modified flag. Then again, > see above: maybe that modification would be for a good well-specified > reason. > > It comes down to a case of "Be conservative in what you send, liberal in > what you accept." > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d04071655a5160a04d0c75590 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Unfortunately given the current implementations out there, we'll n= ever
be able to introduce a new Flag :(
=A0
T= he Neighbor-Complete flag in draft-ietf-idr-option= al-transitive-02 is
one such example that was nixed because of this.
=A0
B= ut it is still worth adding the Errata as you said.
=A0
shyam


On Thu, Dec 13, 2012 at 4:49 PM, John G. Scudder <jgs@juniper.n= et> wrote:
Jeff,

On Dec 13, 2012, at 6:39 PM, Jeff Wheeler <jsw@inconcepts.biz> wrote:

> I wish the flags would be propagated as received. =A0I feel this is > correct. =A0However, I can't wrap my head around the leap of logic= that
> makes this a MUST. =A0In one sentence, it is forbidden to originate an=
> attribute with these bits !=3D 0x0. =A0In the same paragraph, you must=
> take care to preserve their value in case they are !=3D 0x0 anyway.
Exactly. This was my point in writing "this is basically because for t= ransitive attributes, reserved flags aren't good for much if people go = resetting them all the time, just for fun", but I see I should have sp= ent a few more words on the rationale.

Basically, reserved flags are only useful if there is some hope of someday = using them for something. If implementations go resetting the flags, then s= ome future revision to the spec that introduced a new flag would have no ho= pe of that flag propagating end to end, since it would be very likely that = some well-meaning intermediate router would stomp on it. The effort to roll= out implementations that transited the new flag would almost certainly be = prohibitive.

I have no current use for the reserved flags in mind, but I'm hesitant = to throw out a potentially valuable resource for future extension.

> IMO if that is to be changed, then the text opens up the door to
> originating the attribute and then modifying it later by setting these=
> bits, as not being illegal; but it is illegal to set them at
> origination. =A0How strange is that?

Well, "modifying it later" wasn't my intention, and I think a= lso not permitted by what I wrote. It's true that if some router DID mo= dify it later, the text I offered would propagate the modified flag. Then a= gain, see above: maybe that modification would be for a good well-specified= reason.

It comes down to a case of "Be conservative in what you send, liberal = in what you accept."

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--f46d04071655a5160a04d0c75590-- From tony.li@tony.li Thu Dec 13 19:45:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60DA21F89FD for ; Thu, 13 Dec 2012 19:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHvLhFgQ6XLf for ; Thu, 13 Dec 2012 19:45:56 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D721F894F for ; Thu, 13 Dec 2012 19:45:56 -0800 (PST) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta07.emeryville.ca.mail.comcast.net with comcast id b90B1k0020b6N64A7FlwfZ; Fri, 14 Dec 2012 03:45:56 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta03.emeryville.ca.mail.comcast.net with comcast id bFlu1k00B43ZcXW8PFluqe; Fri, 14 Dec 2012 03:45:55 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Thu, 13 Dec 2012 19:45:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355456756; bh=ixcbGL+h9BMqcC2I2NAGyUEUVgk3obDBjgn3kUqQp64=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=froTBpQrNLO8M12SeVBtLjEaUoiP/xVrfEv+r7zstZDi4IXvq1H8H+gAjI6G1jRRG gFHSsh1eZecme8q3JybmqxWhUcwaLMye1Fd5oBINSFBv/oV/JeKTaSvONkg5VAmSg0 Co7iRpr3711k6youjLJBGXRppKQCLDFrMgeWstfxzcJc+yoRA6d0H1rMpzD0T4l4uL S07G/mGjCfFCJjJ1pqwGLxeuIUrmngIn5AuxkrH5FYaIdsqud1KiYV4t4GGzAJiy17 83uJXnXSgX9QnQBH/2wucJhUqwgboeuljFfKoFklEHJiXewD5padw3/zRR32RB0RYL M50p5/ZtiTWGg== Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 03:45:57 -0000 On Dec 13, 2012, at 2:04 PM, John Scudder wrote: > It recently came to my attention that the following from RFC 4271 has = been interpreted in at least two different ways: >=20 > 4.3. UPDATE Message Format > ... > Path Attributes: > ... > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. >=20 > Specifically, the disagreement is regarding "when sent". One school of = thought holds that this means "when originated". Another holds that it = means "when originated or propagated." >=20 > I'm inclined toward the "when originated" interpretation. This is = basically because for transitive attributes, reserved flags aren't good = for much if people go resetting them all the time, just for fun. Thus, = it makes sense to originate the flags as zero, but to transit them as = received.=20 >=20 > I would like to open an erratum against RFC 4271 to clarify this. Some = proposed text is below. I thought I'd open the floor for discussion = before I file anything. We'd end up discussing it anyway, so this just = saves one step in processing the erratum. >=20 > Also: even if we don't use my proposed text, it's demonstrably the = case that the text as written is insufficiently clear. Thus we need SOME = erratum to clarify it, to whatever the WG consensus is. >=20 > Suggested text: >=20 > Type: Technical > Section: RFC 4271 Section 4.3 > Original Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. > Corrected Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when originated. When received, = any > value MUST be accepted. When a BGP speaker propagates an=20 > attribute, it MUST propagate these flags as received. John, My recollection was that the intent is captured by the corrected text. =20= Will the RFC Editor accept this as a Erratum? In the past, when we've = suggested similar technical changes, they've been rebuffed. Tony From jgs@juniper.net Thu Dec 13 20:07:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C772F21F8B95 for ; Thu, 13 Dec 2012 20:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra4OUQuIm3O2 for ; Thu, 13 Dec 2012 20:07:01 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2D43E21F8AF1 for ; Thu, 13 Dec 2012 20:07:01 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUMql5M6pWhDdZx0ILoygAmXRlW3TZ6fw@postini.com; Thu, 13 Dec 2012 20:07:01 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 19:59:13 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 13 Dec 2012 19:59:12 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 13 Dec 2012 20:06:41 -0800 Received: from mail61-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 03:59:07 +0000 Received: from mail61-ch1 (localhost [127.0.0.1]) by mail61-ch1-R.bigfish.com (Postfix) with ESMTP id 4A37C20026C for ; Fri, 14 Dec 2012 03:59:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 1 X-BigFish: PS1(zz98dI9371Izz1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1155h) Received: from mail61-ch1 (localhost.localdomain [127.0.0.1]) by mail61-ch1 (MessageSwitch) id 1355457545288322_29175; Fri, 14 Dec 2012 03:59:05 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail61-ch1.bigfish.com (Postfix) with ESMTP id 444342A02D3; Fri, 14 Dec 2012 03:59:05 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 03:59:05 +0000 Received: from BL2PRD0512MB614.namprd05.prod.outlook.com ([169.254.9.170]) by BL2PRD0512HT001.namprd05.prod.outlook.com ([10.255.233.34]) with mapi id 14.16.0245.002; Fri, 14 Dec 2012 03:59:04 +0000 From: John Scudder To: Tony Li Thread-Topic: [Idr] Low-order attribute flags -- when to zero Thread-Index: Ac3ZfrktbzqKxTLKTfCfJnhHzNs+lg== Date: Fri, 14 Dec 2012 03:59:04 +0000 Message-ID: <407DC9AF-90AE-4698-89CA-64CF3A55A337@juniper.net> References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.151.14.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <22CFB6F798C10346B34B3C90D5A2A85F@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TONY.LI$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:07:01 -0000 On Dec 13, 2012, at 10:45 PM, Tony Li wrote: > Will the RFC Editor accept this as a Erratum? In the past, when we've su= ggested similar technical changes, they've been rebuffed. Well, we don't know until we try. The reason I think there's a strong case = for this to be an erratum is that it's demonstrably unclear in the current = text, in that different implementors have done different things, not out of= any willful desire to diverge from the spec, but because that's what they = thought it said. Seems to me like exactly what a technical erratum is for.= =20 --John= From bruno.decraene@orange.com Fri Dec 14 05:28:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8118C21F8425 for ; Fri, 14 Dec 2012 05:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CHQ7rNB8Kg5 for ; Fri, 14 Dec 2012 05:28:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7121F86B7 for ; Fri, 14 Dec 2012 05:28:00 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 50D68264370; Fri, 14 Dec 2012 14:27:59 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DB0A2238093; Fri, 14 Dec 2012 14:27:42 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 14:27:42 +0100 From: To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] Low-order attribute flags -- when to zero Thread-Index: AQHN2X+xgh3VvdAFrESK2s+Szeky/JgYRDxA Date: Fri, 14 Dec 2012 13:27:42 +0000 Message-ID: <29278_1355491679_50CB295E_29278_2080_1_53C29892C857584299CBF5D05346208A11833D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> In-Reply-To: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.14.94517 Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:28:02 -0000 John, all Please find below some comments inline. >From: John Scudder > >Folks, > >It recently came to my attention that the following from RFC 4271 has been >interpreted in at least two different ways: Thanks for raising and clarifying the point. >4.3. UPDATE Message Format >... > Path Attributes: >... > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. > >Specifically, the disagreement is regarding "when sent". One school of tho= ught >holds that this means "when originated". Another holds that it means "when >originated or propagated." > >I'm inclined toward the "when originated" interpretation. This is basically >because for transitive attributes, reserved flags aren't good for much if >people go resetting them all the time, just for fun. Thus, it makes sense = to >originate the flags as zero, but to transit them as received. +1 In my view, this is not limited to transitive attributes. IMHO, we could po= ssibly specify new usage for those bits even for non-transitive or even wel= l-known attributes. >I would like to open an erratum against RFC 4271 to clarify this. Some pro= posed >text is below. I thought I'd open the floor for discussion before I file >anything. We'd end up discussing it anyway, so this just saves one step in >processing the erratum. > >Also: even if we don't use my proposed text, it's demonstrably the case th= at >the text as written is insufficiently clear. Thus we need SOME erratum to >clarify it, to whatever the WG consensus is. +1 >Thanks, > >--John > >Suggested text: > >Type: Technical >Section: RFC 4271 Section 4.3 >Original Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. >Corrected Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when originated.=20=20 +1 Possibly :s/unused/currently unused and reserved for future extension As clarifying the goal of those bits may help the readers to take the right= assumption in case some of further questions. > When received, any value MUST be accepted. +1 > When a BGP speaker propagates an attribute, it MUST propagate these flag= s as received. +1 Thanks, Bruno > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From chris.hall@highwayman.com Fri Dec 14 07:37:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246B121F8849 for ; Fri, 14 Dec 2012 07:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayspQ+MtY0nD for ; Fri, 14 Dec 2012 07:37:23 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4497821F8897 for ; Fri, 14 Dec 2012 07:37:19 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 58DAC384080 for ; Fri, 14 Dec 2012 15:37:17 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 3F0D038407C for ; Fri, 14 Dec 2012 15:37:17 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP for ; Fri, 14 Dec 2012 15:37:17 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TjXK8-0005lW-Hq for idr@ietf.org; Fri, 14 Dec 2012 15:37:16 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> <2F3EBB88EC3A454AAB08915FBF0B8C7E11453E@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E11453E@eusaamb109.ericsson.se> Date: Fri, 14 Dec 2012 15:37:11 -0000 Organization: Highwayman Message-ID: <02a101cdda10$e561dba0$b02592e0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJOAPYCeJyjYX3B4sEMfakUNrTUgGAMqs/mZV3CEA= Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:37:24 -0000 Jakob Heitz wrote (on Thu 13-Dec-2012 at 22:58 +0000): ... > I think the horse has left the barn. There was a horse ?! I read the requirement as tacit acceptance that it is never going to be possible to fiddle with the base level Flags handling. If there is doubt whether "sent" might mean just when "originated", then it could be made clear that the sender MUST *always* flatten to zeros (just in case the receiver is a blithering idiot and fails to flatten to zeros). Obviously these bits could be given meaning, between consenting peers who have negotiated their way into a state of (mutual) sin. Although, that could disrupt code which is processing UPDATE messages "out-of-band" :-( ... > Maybe, you can change your last sentence to: > When a BGP speaker propagates an > unknown optional transitive attribute, > it MUST propagate these flags as received. Is this a big win ? If an optional transitive attribute needs a few bits, why not just include them in the body of the attribute ? Further, it's simpler and more reliable if the receiver can treat all attributes the same, and mask off the "unused" bits. Mind you, in the Flags octet only Transitive and Extended Length have any useful meaning. And Transitive is only meaningful on Unknown attributes. Otherwise, the bits are pretty much noise, and once draft-ietf-idr-error-handling has had its wicked way with them, the noise will be suppressed. [Does anyone know what the "Partial" bit is for, BTW ?] Chris From jakob.heitz@ericsson.com Fri Dec 14 08:01:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E74321F88CC for ; Fri, 14 Dec 2012 08:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC0D1FSjUiAg for ; Fri, 14 Dec 2012 08:01:36 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D992821F88CB for ; Fri, 14 Dec 2012 08:01:35 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBEG1WEE012710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 10:01:33 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 14 Dec 2012 11:01:33 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Fri, 14 Dec 2012 11:01:32 -0500 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] Low-order attribute flags -- when to zero Thread-Index: AQHN2X+35WnO93tFyUutiNTGt3vZBpgXTiwAgAF0aoD//7L9/Q== Date: Fri, 14 Dec 2012 16:01:32 +0000 Message-ID: <25179503-DDE5-447A-8EBF-5BC480634450@ericsson.com> References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> <2F3EBB88EC3A454AAB08915FBF0B8C7E11453E@eusaamb109.ericsson.se>, <02a101cdda10$e561dba0$b02592e0$@highwayman.com> In-Reply-To: <02a101cdda10$e561dba0$b02592e0$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 16:01:36 -0000 On Dec 14, 2012, at 7:37 AM, "Chris Hall" wrote= : > There was a horse ?! Here is the horse: On Dec 9, 2012, at 6:26 PM, "Jeff Wheeler" wrote: > Here is an example from two weeks ago of some routes injected to the > DFZ with malformed attribute flags. The result was that everyone > running OpenBGPd more than a few months old, and some networks with > Alcatel routers, and who knows what else, had their BGP sessions > resetting endlessly. > http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html If the working group is fine with resetting sessions on those routers, I'll= happily change my code. >=20 -- Jakob Heitz.= From nick@foobar.org Fri Dec 14 08:25:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D5021F8959 for ; Fri, 14 Dec 2012 08:25:08 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVRX7Z7T3L7y for ; Fri, 14 Dec 2012 08:25:08 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC721F87CC for ; Fri, 14 Dec 2012 08:25:07 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBEGNU7U072258 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 16:23:30 GMT (envelope-from nick@foobar.org) Message-ID: <50CB52E0.7080602@foobar.org> Date: Fri, 14 Dec 2012 16:25:04 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <20121210225858.GC24937@puck.nether.net> <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> In-Reply-To: <20121213144147.GB4524@puck.nether.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 16:25:08 -0000 On 13/12/2012 14:41, Jon Mitchell wrote: > This is a long email, revisiting almost everyone of the numbering > discussions in the draft, but I'll try to respond inline mostly to the > nice summary you have at bottom. thanks for considering these points. Just one issue: >> - the numbers are large enough that they will attract typos >> - complete mouthful and impossible to transmit down e.g. phone, across the >> room, etc (yes, we shout ASNs across the room, and sometimes even talk to >> customers). > > I encourage your drafts to deprecate 4B ASN, MAC addresses and IPv6. I don't think this is a viable argument to justify a 10-digit range - instead it's a straw man. There are many potential ranges which will not interfere with the RIR ranges and the lower ranges have an explicit tangible benefit to me and others on this mailing list. Turning it around, why didn't IANA start AS32 allocations at 2^32 and work their way down from there? I'd argue that it's because the larger numbers are a pain to deal with and if they had done so, people would have jumped up and down and shouted at them for doing something unnecessarily pathological. On this basis I genuinely don't see why a private range should be considered any differently. Why should private ASN users be committed to use ridiculously large numbers forever more? (and what did they do to deserve this??? :-) > My general feeling is that if you are configuring a small number of > sites and your operations is confined to a single room and voice > communication is your primary method still, you are likely to be happy > with just using ASN 65000 (meets all of your criteria). There may also be reasons for using ASN32s instead of ASN16s, or perhaps including ASN16s. The two have different operational characteristics. Nick From jrmitche@puck.nether.net Fri Dec 14 09:40:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC4C21F89A9 for ; Fri, 14 Dec 2012 09:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNiW1rMuYE7Q for ; Fri, 14 Dec 2012 09:40:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8697721F85B3 for ; Fri, 14 Dec 2012 09:40:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBEHeClY021836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 12:40:13 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBEHeCu1021835; Fri, 14 Dec 2012 12:40:12 -0500 Date: Fri, 14 Dec 2012 12:40:12 -0500 From: Jon Mitchell To: Nick Hilliard Message-ID: <20121214174012.GA18502@puck.nether.net> References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CB52E0.7080602@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 14 Dec 2012 12:40:13 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:40:22 -0000 Nick - I don't think there seems to be much concensus around any of the discussions to change the range in the draft but there are a number of people supporting in it's current state w/o these reservations, there are literally billions of options we could choose from, especially when we consider David is now suggesting two ranges (the only other person on the list who has commented). The only obvious solution to using a very low number range that doesn't put the private ASN range right in the middle of public ASN's some number of years from now is to lower significantly the size of the allocation (which we have already debated and said we wanted to not re-visit this issue again). I appreciate that you say you may have a motivation that is different than a large number of sites for using the new range, but this is not the motivation of the current draft. This also leaves open the idea (not which I'm suggesting or planning on writing drafts about) to re-structure what happens with the vasty majority of the space in between for some future undefined purpose. As for private ASNs being secluded to the end of the range... this has historical precedence and seems to be much more identifiable as something different than other options (even if you typo it, it's unlikely to conflict with anyone!). Why should private ASN's being favored over current ARIN Public assignments? Should they gripe they have a 6 digit number while others are proposing the new range only be 5 digits? As for 10 digits.. is it really that many (you can add some structure internally.. i.e. some zeros in the middle if you only need a subset of the total available number)? Jon On Fri, Dec 14, 2012 at 04:25:04PM +0000, Nick Hilliard wrote: > On 13/12/2012 14:41, Jon Mitchell wrote: > > This is a long email, revisiting almost everyone of the numbering > > discussions in the draft, but I'll try to respond inline mostly to the > > nice summary you have at bottom. > > thanks for considering these points. Just one issue: > > >> - the numbers are large enough that they will attract typos > >> - complete mouthful and impossible to transmit down e.g. phone, across the > >> room, etc (yes, we shout ASNs across the room, and sometimes even talk to > >> customers). > > > > I encourage your drafts to deprecate 4B ASN, MAC addresses and IPv6. > > I don't think this is a viable argument to justify a 10-digit range - > instead it's a straw man. There are many potential ranges which will not > interfere with the RIR ranges and the lower ranges have an explicit > tangible benefit to me and others on this mailing list. > > Turning it around, why didn't IANA start AS32 allocations at 2^32 and work > their way down from there? I'd argue that it's because the larger numbers > are a pain to deal with and if they had done so, people would have jumped > up and down and shouted at them for doing something unnecessarily pathological. > > On this basis I genuinely don't see why a private range should be > considered any differently. Why should private ASN users be committed to > use ridiculously large numbers forever more? (and what did they do to > deserve this??? :-) > > > My general feeling is that if you are configuring a small number of > > sites and your operations is confined to a single room and voice > > communication is your primary method still, you are likely to be happy > > with just using ASN 65000 (meets all of your criteria). > > There may also be reasons for using ASN32s instead of ASN16s, or perhaps > including ASN16s. The two have different operational characteristics. > > Nick From jsw@inconcepts.biz Fri Dec 14 10:54:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9BA21F8A9B for ; Fri, 14 Dec 2012 10:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZjWuQN2tO2l for ; Fri, 14 Dec 2012 10:54:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8F21F8A05 for ; Fri, 14 Dec 2012 10:54:38 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6484176ieb.31 for ; Fri, 14 Dec 2012 10:54:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=jR5qsEbx8cIsG7s19dRAPksgkA5rGycVQt/ukmfiGTc=; b=WUrtnvBP9pPlxm36I2Td3nCvOh5r3q5X3CgdN/AT9FHMALkWgZopBVuvP8ro+hR1YL WeQbFf5zO0sfQeGJZEShH+VdLL6SU3D/7sZMcctBAzVmn/7Q1vbM0AmYDoU7BnW9xVzD wY1sPBVOijbu4pizy4Q4PxEqPA9O7WBjVv3ZLhI9yEVXMPnkin1xY6wcUq5K111L7Gjq xQznrXUewXTh6DwsPiVKaHPVMQnbNwr09r31KLwe+ABXg03OSAGSrZjWjzmO0qFDPaRA 5xTKM+dPz5tTL7J6kRLbHP0GlgfZ3AN99jjDOokYK7GCtunebtBTCWsxqtjDoqb3SDia EvyA== MIME-Version: 1.0 Received: by 10.42.22.198 with SMTP id p6mr5433795icb.17.1355511278305; Fri, 14 Dec 2012 10:54:38 -0800 (PST) Received: by 10.64.132.33 with HTTP; Fri, 14 Dec 2012 10:54:38 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Fri, 14 Dec 2012 13:54:38 -0500 Message-ID: From: Jeff Wheeler To: "John G. Scudder" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6Us/s8n6ePdmeCQQToy/z2v7b/LOFmXG4WUvCj+49R2NwG3I9XVXNtKJlnUmq8KeobV2b Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:54:39 -0000 On Thu, Dec 13, 2012 at 7:49 PM, John G. Scudder wrote: >> IMO if that is to be changed, then the text opens up the door to >> originating the attribute and then modifying it later by setting these >> bits, as not being illegal; but it is illegal to set them at >> origination. How strange is that? > > Well, "modifying it later" wasn't my intention, and I think also not perm= itted by what I wrote. It's true that if some router DID modify it later, t= he text I offered would propagate the modified flag. Then again, see above:= maybe that modification would be for a good well-specified reason. If you carefully parse the text you've written, it does indeed allow intermediate routers to modify the reserved bits. That's why I said I think it is a strange leap of logic. Basically it is unfortunate that ambiguity has caused different implementations to behave in different ways here, but I think it is hard to fix in a sensible way without re-defining the rules so that the implementations which do NOT reset the bits to 0 are suddenly out-of-spec. It makes perfect sense that those bits are RESERVED. It was done for octet-alignment and without any anticipation that they would be needed. If people are using them for something, I think that's fine, and perhaps they would care to modify BGP so the reserved bits SHOULD be zero instead of MUST be zero. i understand why this cannot be done as an errata but ultimately it is the correct "fix," if the goal is to modify the specification to fit some corner-cases in the real world. On Fri, Dec 14, 2012 at 10:37 AM, Chris Hall wr= ote: > [Does anyone know what the "Partial" bit is for, BTW ?] Yes, the Partial Bit is documented in RFC4271 Pg24. Basically, it's there for two reasons. First, if you propagate an unrecognized transitive optional Attribute, you are supposed to set the Partial bit. This indicates to other BGP speakers that, if you were supposed to modify this attribute (if you knew what it was) you did not do this (because you don't know how.) An example of this is that crazy private AS / administrative domain identifier attribute. Say you added that to the BGP specification as a new attribute. Routers that did not know what to do with it would happily forward the attribute and set Partial on it. Implementing that feature would not need the information carried in the Partial bit, but it's there just in case. Also if you add an optional transitive attribute, you are supposed to set the Partial bit, if you are not the originator of the path -- in other words, you are a transit router. On Fri, Dec 14, 2012 at 11:01 AM, Jakob Heitz wr= ote: > If the working group is fine with resetting sessions on those routers, I'= ll happily change my code. I guess that is a joke I didn't get? I did not think it was funny when I had to troubleshoot it in the middle of the night! :-( --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jakob.heitz@ericsson.com Fri Dec 14 13:19:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8921F8A7D for ; Fri, 14 Dec 2012 13:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg+6KTa4u4is for ; Fri, 14 Dec 2012 13:19:33 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 81D9421F89E8 for ; Fri, 14 Dec 2012 13:19:33 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBELTndY013785; Fri, 14 Dec 2012 15:30:09 -0600 Received: from EUSAAHC005.ericsson.se (147.117.188.87) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 14 Dec 2012 16:19:11 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.001; Fri, 14 Dec 2012 16:19:11 -0500 From: Jakob Heitz To: Jon Mitchell , Nick Hilliard Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHN19SJffMIynRi20WhRXYHBAltwZgUUuOAgAFmc4CAAFkhAIABEaaAgAGvMACAABT+AP//6J4w Date: Fri, 14 Dec 2012 21:19:10 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E115EA3@eusaamb109.ericsson.se> References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> In-Reply-To: <20121214174012.GA18502@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:19:37 -0000 FWIW, I support a human readable range. There is absolutely no advantage to any binary boundary from the software point of view. -- Jakob Heitz. =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Jon Mitchell > Sent: Friday, December 14, 2012 9:40 AM > To: Nick Hilliard > Cc: IETF IDR Working Group > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 >=20 >=20 > Nick - >=20 > I don't think there seems to be much concensus around any of the > discussions to change the range in the draft but there are a number of > people supporting in it's current state w/o these reservations, there > are literally billions of options we could choose from,=20 > especially when > we consider David is now suggesting two ranges (the only=20 > other person on > the list who has commented). >=20 > The only obvious solution to using a very low number range=20 > that doesn't > put the private ASN range right in the middle of public ASN's some > number of years from now is to lower significantly the size of the > allocation (which we have already debated and said we wanted to not > re-visit this issue again). I appreciate that you say you may have a > motivation that is different than a large number of sites for=20 > using the > new range, but this is not the motivation of the current draft. >=20 > This also leaves open the idea (not which I'm suggesting or=20 > planning on > writing drafts about) to re-structure what happens with the vasty > majority of the space in between for some future undefined purpose. >=20 > As for private ASNs being secluded to the end of the range... this has > historical precedence and seems to be much more identifiable as > something different than other options (even if you typo it, it's > unlikely to conflict with anyone!). Why should private ASN's being > favored over current ARIN Public assignments? Should they gripe they > have a 6 digit number while others are proposing the new=20 > range only be 5 > digits? >=20 > As for 10 digits.. is it really that many (you can add some structure > internally.. i.e. some zeros in the middle if you only need a=20 > subset of > the total available number)? >=20 > Jon >=20 > On Fri, Dec 14, 2012 at 04:25:04PM +0000, Nick Hilliard wrote: > > On 13/12/2012 14:41, Jon Mitchell wrote: > > > This is a long email, revisiting almost everyone of the numbering > > > discussions in the draft, but I'll try to respond inline=20 > mostly to the > > > nice summary you have at bottom. > >=20 > > thanks for considering these points. Just one issue: > >=20 > > >> - the numbers are large enough that they will attract typos > > >> - complete mouthful and impossible to transmit down=20 > e.g. phone, across the > > >> room, etc (yes, we shout ASNs across the room, and=20 > sometimes even talk to > > >> customers). > > >=20 > > > I encourage your drafts to deprecate 4B ASN, MAC=20 > addresses and IPv6. > >=20 > > I don't think this is a viable argument to justify a=20 > 10-digit range - > > instead it's a straw man. There are many potential ranges=20 > which will not > > interfere with the RIR ranges and the lower ranges have an explicit > > tangible benefit to me and others on this mailing list. > >=20 > > Turning it around, why didn't IANA start AS32 allocations=20 > at 2^32 and work > > their way down from there? I'd argue that it's because the=20 > larger numbers > > are a pain to deal with and if they had done so, people=20 > would have jumped > > up and down and shouted at them for doing something=20 > unnecessarily pathological. > >=20 > > On this basis I genuinely don't see why a private range should be > > considered any differently. Why should private ASN users=20 > be committed to > > use ridiculously large numbers forever more? (and what did=20 > they do to > > deserve this??? :-) > >=20 > > > My general feeling is that if you are configuring a small=20 > number of > > > sites and your operations is confined to a single room and voice > > > communication is your primary method still, you are=20 > likely to be happy > > > with just using ASN 65000 (meets all of your criteria). > >=20 > > There may also be reasons for using ASN32s instead of=20 > ASN16s, or perhaps > > including ASN16s. The two have different operational=20 > characteristics. > >=20 > > Nick > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > = From chris.hall@highwayman.com Fri Dec 14 15:01:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9376321F8AC6 for ; Fri, 14 Dec 2012 15:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFFjRLwb0azP for ; Fri, 14 Dec 2012 15:01:51 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tch.inty.net [91.221.169.46]) by ietfa.amsl.com (Postfix) with ESMTP id E3C6F21F8AD0 for ; Fri, 14 Dec 2012 15:01:50 -0800 (PST) Received: from mdfmta005.tch.inty.net (unknown [127.0.0.1]) by mdfmta005.tch.inty.net (Postfix) with ESMTP id 5DF2E18C67B; Fri, 14 Dec 2012 23:01:49 +0000 (GMT) Received: from mdfmta005.tch.inty.net (unknown [127.0.0.1]) by mdfmta005.tch.inty.net (Postfix) with ESMTP id 3A01B18C66C; Fri, 14 Dec 2012 23:01:49 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tch.inty.net (Postfix) with ESMTP; Fri, 14 Dec 2012 23:01:48 +0000 (GMT) Received: from [80.177.246.149] by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TjeGJ-0005lq-SW; Fri, 14 Dec 2012 23:01:47 +0000 References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Chris Hall Date: Fri, 14 Dec 2012 23:01:41 +0000 To: Jeff Wheeler X-MDF-HostID: 18 Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 23:01:51 -0000 On 14 Dec 2012, at 18:54, Jeff Wheeler wrote: > On Fri, Dec 14, 2012 at 10:37 AM, Chris Hall w= rote: >> [Does anyone know what the "Partial" bit is for, BTW ?] >=20 > Yes, the Partial Bit is documented in RFC4271 Pg24. Basically, it's > there for two reasons. >=20 > First, if you propagate an unrecognized transitive optional Attribute, > you are supposed to set the Partial bit. This indicates to other BGP > speakers that, if you were supposed to modify this attribute (if you > knew what it was) you did not do this (because you don't know how.) >=20 > An example of this is that crazy private AS / administrative domain > identifier attribute. Say you added that to the BGP specification as > a new attribute. Routers that did not know what to do with it would > happily forward the attribute and set Partial on it. Implementing > that feature would not need the information carried in the Partial > bit, but it's there just in case. >=20 > Also if you add an optional transitive attribute, you are supposed to > set the Partial bit, if you are not the originator of the path -- in > other words, you are a transit router. It's a bundle of laughs. No question. So, I'm staring at an attribute with a Partial bit on it, which means: 1) my immediate neighbour did not understand the attribute, 2) somebody upstream of my neighbour did not understand it, 3) somebody other than the originator added it, 4) or any combination of the above, I think that's all the possible meanings... plenty to choose from :-)... it'= s possible that something about the attribute will resolve this ambiguity...= or not; who can tell ? Chris= From farmer@umn.edu Fri Dec 14 15:26:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81221F8AC6 for ; Fri, 14 Dec 2012 15:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRTGsqlcxi8k for ; Fri, 14 Dec 2012 15:26:58 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 67E4C21F8992 for ; Fri, 14 Dec 2012 15:26:58 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 14 Dec 2012 17:13:28 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f70.google.com [209.85.219.70] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f70.google.com with SMTP id k14so16601412oag.1 for ; Fri, 14 Dec 2012 15:13:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=rx8RzT9ckPqJ9roLdZ0Z1orOCvZXtTa0HAF3hrP713U=; b=k1wMcEqLmVnn4XLZNLQxYrMPAgkKuiTokoJSEZDU1QSVdRfRYhcFNDKNlP38IzYq68 bafzbLDIQ6JY+FEXsqIs+lLhOqpPwkzM0KYYP4Yb9PuuIWPoYTphh9CqX6SUHm0LbboE PuXrel6LlCqhn8Dxms2l224WDVz+3Mr7JU9c/5huJw3Rsoh9Qd+SdTocgb4/MeAyYWRb 0dwGg77uiiHlStKRHTrgYL+dx63T3BsQe3be7xCde/gHJUkLYWju7MNGlPWVY73qCAv3 Qf3A2u1NlkNQsIPORMGq+vtuDbRC6pHSLZUp9/LsvKDNGmF4NoPqAL/4P4SdoLIz5QOu oIPg== X-Received: by 10.50.57.232 with SMTP id l8mr3246245igq.54.1355526808234; Fri, 14 Dec 2012 15:13:28 -0800 (PST) X-Received: by 10.50.57.232 with SMTP id l8mr3246238igq.54.1355526808087; Fri, 14 Dec 2012 15:13:28 -0800 (PST) Received: from vpn0-550.vpn.umn.edu (vpn0-550.vpn.umn.edu. [134.84.2.38]) by mx.google.com with ESMTPS id fa6sm5141528igb.2.2012.12.14.15.13.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 15:13:27 -0800 (PST) Message-ID: <50CBB294.1000300@umn.edu> Date: Fri, 14 Dec 2012 17:13:24 -0600 From: David Farmer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jon Mitchell References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> In-Reply-To: <20121214174012.GA18502@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl+YNCX/zj2Wci2Bzizq8qqr1E5bTdqMd+oBt/KuTVPAuqrMIUT4tGwjv8lB8otPNZYBWFryFGL+0VfSJyaK+9ms6c6BKRZBaOGqSNlmeOyABj17NN6RHcwFdic7P6h7lB7IDRe Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 23:26:59 -0000 On 12/14/12 11:40 , Jon Mitchell wrote: > > Nick - > > I don't think there seems to be much concensus around any of the > discussions to change the range in the draft but there are a number of > people supporting in it's current state w/o these reservations, there > are literally billions of options we could choose from, especially when > we consider David is now suggesting two ranges (the only other person on > the list who has commented). To be clear, I support the range currently in the draft, but I'm willing to consider the alternatives I outlined. Especially, if there is a consensus that we should have something more human and decimal/regexp friendly. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jsw@inconcepts.biz Fri Dec 14 16:04:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7828C21F8B6B for ; Fri, 14 Dec 2012 16:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7aYtlHFvGNI for ; Fri, 14 Dec 2012 16:04:46 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E84FB21F8B65 for ; Fri, 14 Dec 2012 16:04:45 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so3700486iaz.31 for ; Fri, 14 Dec 2012 16:04:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=W8ZqW3CsMju5ogndjExJV0TAwptLTT1N8PUPjYAaDDo=; b=mflE1mJZ4otAJDYOpOukCv3ZbD4yAk7mXBIxQPfQqW6ykBTh7bvj4EEb9Takh0RxE9 JAgDvNsvxOVcfjXzda1W7We0uSLvwlW57qzQfgP+4lOlk2gCteFui7Lbx2j5J5n9IKdA xbtzr768B4yA0ISilOZqMJ/DtlVKTXTxzUGkOUd0fcdUd69vuIhWpFMQleM+IgAdLTNg DInuciRY2k09dHY9F2rhXDpmUNzoZHMdNESLzHI2g51ptXK05WRFDxteMGYeIVb79QZj LFODRH52RsWnylhpGGpCScbgu8d8dXogkB/7dc3UKc0Z2ZC5fOHBF1CsQGnqkSrlUXCb 5JYg== MIME-Version: 1.0 Received: by 10.50.36.198 with SMTP id s6mr3359493igj.23.1355529885394; Fri, 14 Dec 2012 16:04:45 -0800 (PST) Received: by 10.64.132.33 with HTTP; Fri, 14 Dec 2012 16:04:45 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Fri, 14 Dec 2012 19:04:45 -0500 Message-ID: From: Jeff Wheeler To: Chris Hall Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk/OpbVy6HriDggc8Fd6dN+s2RfsrTPlMsM5TjTPrWosgA/ekc5MOkBavGUjyTU/lnjvbml Cc: "idr@ietf. org" Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 00:04:46 -0000 On Fri, Dec 14, 2012 at 6:01 PM, Chris Hall wrote: > I think that's all the possible meanings... plenty to choose from :-)... it's possible that something about the attribute will resolve this ambiguity... or not; who can tell ? The important thing is what Partial=0 means: the attribute was placed there by the originator and understood by all "upstream" BGP speakers. I don't know why it isn't documented that way. Maybe historical? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From warren@kumari.net Fri Dec 14 17:40:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E1921F895D for ; Fri, 14 Dec 2012 17:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3hebSJc0msu for ; Fri, 14 Dec 2012 17:40:37 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9DA21F8634 for ; Fri, 14 Dec 2012 17:40:37 -0800 (PST) Received: from [172.29.46.124] (unknown [72.14.227.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 74B221B4004E; Fri, 14 Dec 2012 20:40:33 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <50CBB294.1000300@umn.edu> Date: Fri, 14 Dec 2012 20:40:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1499) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 01:40:37 -0000 On Dec 14, 2012, at 6:13 PM, David Farmer wrote: > On 12/14/12 11:40 , Jon Mitchell wrote: >>=20 >> Nick - >>=20 >> I don't think there seems to be much concensus around any of the >> discussions to change the range in the draft but there are a number = of >> people supporting in it's current state w/o these reservations, there >> are literally billions of options we could choose from, especially = when >> we consider David is now suggesting two ranges (the only other person = on >> the list who has commented). >=20 > To be clear, I support the range currently in the draft, but I'm = willing to consider the alternatives I outlined. Especially, if there = is a consensus that we should have something more human and = decimal/regexp friendly. Sounds suspiciously like a "please weigh in" / consensus call=85 So, I'd like something more human / decimal/regexp friendly like = 4200000000=85=20 (and I sure hope I'm not the poor sod who gets allocated 4200000 or = 42000000 or 420000000=85 :-P ) W >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From jrmitche@puck.nether.net Fri Dec 14 18:30:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD2921F8B6B for ; Fri, 14 Dec 2012 18:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7galgvMpnJC5 for ; Fri, 14 Dec 2012 18:30:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40221F8B67 for ; Fri, 14 Dec 2012 18:30:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBF2UKX4017095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 21:30:20 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBF2UJiU017093; Fri, 14 Dec 2012 21:30:19 -0500 Date: Fri, 14 Dec 2012 21:30:19 -0500 From: Jon Mitchell To: Warren Kumari Message-ID: <20121215023019.GA14973@puck.nether.net> References: <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 14 Dec 2012 21:30:20 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 02:30:21 -0000 I agree Warren and was writing an email with the same suggestion. Does anyone object to moving the range in the draft to 4200000000 - 4294967294 from the current? I think the decimal versus bit boundary is the one trend I see in the messages that is worth revisiting. Jon On Fri, Dec 14, 2012 at 08:40:33PM -0500, Warren Kumari wrote: > > So, I'd like something more human / decimal/regexp friendly like 4200000000? > From lambert@psc.edu Fri Dec 14 19:02:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1D121F8AC6 for ; Fri, 14 Dec 2012 19:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fMsRF41cOgH for ; Fri, 14 Dec 2012 19:02:14 -0800 (PST) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by ietfa.amsl.com (Postfix) with ESMTP id 373EB21F8AB4 for ; Fri, 14 Dec 2012 19:02:14 -0800 (PST) Received: from dengue.hsd1.pa.comcast.net (c-67-186-16-191.hsd1.pa.comcast.net [67.186.16.191]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.8) with ESMTP id qBF32Cjq002092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 22:02:13 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael H Lambert In-Reply-To: <50CBB294.1000300@umn.edu> Date: Fri, 14 Dec 2012 22:02:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> To: IETF IDR Working Group X-Mailer: Apple Mail (2.1283) Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 03:02:14 -0000 On 14 Dec 2012, at 18:13, David Farmer wrote: > To be clear, I support the range currently in the draft, but I'm = willing to consider the alternatives I outlined. Especially, if there = is a consensus that we should have something more human and = decimal/regexp friendly. Well, if a new ashex type were to be introduced, 0xff000000 to = 0xfffffffe would be rather clean for the proposed private range. Michael ----- Michael H Lambert, GigaPoP Coordinator Phone: +1 412 268-4960 Pittsburgh Supercomputing Center/3ROX FAX: +1 412 268-5832 300 S Craig St, Pittsburgh, PA 15213 USA lambert@psc.edu From nick@foobar.org Sat Dec 15 14:44:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5B21F84F3 for ; Sat, 15 Dec 2012 14:44:36 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl7o4FDogaG2 for ; Sat, 15 Dec 2012 14:44:35 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id DA51421F84D4 for ; Sat, 15 Dec 2012 14:44:34 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBFMgnUf083071 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 22:42:56 GMT (envelope-from nick@foobar.org) Message-ID: <50CCFD49.1060307@foobar.org> Date: Sat, 15 Dec 2012 22:44:25 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Warren Kumari References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 22:44:37 -0000 On 15/12/2012 01:40, Warren Kumari wrote: > (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000… :-P ) or anything in the range between 420000 -> 429999. This falls bang in the middle of the likely range that will be assigned to ARIN. Let me hold my nose for a moment and use asdot format: as420000 == 6.26784, and I can see this asn being assigned in the foreseeable future in the ARIN service region. 900000-999999 seems to be well outside the range of any of the current RIRs (using current allocation techniques, there could be 6 more RIRs before there would be any interference). Nick From millnert@gmail.com Sat Dec 15 15:00:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD90121F853F for ; Sat, 15 Dec 2012 15:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0YJKkpo5CuJ for ; Sat, 15 Dec 2012 15:00:36 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA121F853E for ; Sat, 15 Dec 2012 15:00:35 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so2641522eek.31 for ; Sat, 15 Dec 2012 15:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=5SWPQ8Rbys8qsXbw3HwiwtlO1CacOcoFcBg/NywD+cY=; b=oDszFjB5GM1DDdGiCG4SmNyOSYlysuk0e2LO8CueoHIeJrTwUhvKr6zeFln0GRf74x xvl1t/a5IzcyYGQtSFIJoMCNfzvRNluAtPnyE+w2Rq7V1C9WCcfKHfi/T+la+gS4qlZH iWCmuqHcdAqxAMhmIUJBdJIncETtWzCz1+Tcxl3HKEx2ECfPBf1bXWmh/OcpM+eb+zFx rIZlRtEBAP7zzeuS8ih/MxRKQcbTIGc9PBeSCtfijlKnJlHwcWlM378mFT2uewR6K0iM PfjrM+9cpgaSxnt2zUlGJsx2NVM3yV6t0GD3ao+g6pUPI2YWXOYwChyBvuicgDHtvgqX eZrg== Received: by 10.14.209.193 with SMTP id s41mr27117085eeo.9.1355612435132; Sat, 15 Dec 2012 15:00:35 -0800 (PST) Received: from [192.168.120.17] (h-190-181.a189.priv.bahnhof.se. [85.24.190.181]) by mx.google.com with ESMTPS id 43sm18639425eed.10.2012.12.15.15.00.33 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 15:00:34 -0800 (PST) Message-ID: <1355612433.6115.16.camel@galileo.millnert.se> From: Martin Millnert To: Michael H Lambert Date: Sun, 16 Dec 2012 00:00:33 +0100 In-Reply-To: References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 23:00:36 -0000 On Fri, 2012-12-14 at 22:02 -0500, Michael H Lambert wrote: > Well, if a new ashex type were to be introduced, 0xff000000 to > 0xfffffffe would be rather clean for the proposed private range. It's my understanding this horse has left the barn as well, so this is not an option. FWIW, I am OK with the large size of a new range of 2^24 private ASNs. I'd also be OK with a smaller range which is more easily typed in or otherwise humanly processed. Chances are, if you need a private space of 2^24 scale, you can rather easily just pick your own bits from the 2^32 space... W.r.t predicting future scale of ASN ranges, the real "concern" is IMO whether 2^32 is sufficient, or if we'll end up needing 128-bit ASNs eventually... but as long as we avoid trying to put more information in an ASN than it is for, we should be fine. - at most, a scale of one private ASN per physical VM server, "ought to be enough" for internet connected networks, w.r.t any scaling I can imagine. 16M physical VMs? you can probably afford to design a better solution to your overlay networking :> - larger simulations or experiments need not be connected to the internet anyway, or could easily afford some translating gateways to use the full 32 bit space privately on the simulation side - burning through "public" ASN space by allocating large ranges of public ASNs to each network by default (by RIR policy, or any hierarchical story...) is wasteful and designs for rare exceptions rather than the norm, which is simply wrong. much more wise to have a private range in this case. - operators are going to use the numbers, so readability is a really wise thing. all in all, I'm ok with the proposal, and with 2^24 even though I'm hard pressed to see a use case for more than O(100000) private ASNs in practice. but the numbers really should be readable, so 420* is ok, as well. the numbers in the draft are a bad choice in this regard and should be changed. /M From millnert@gmail.com Sat Dec 15 15:35:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22F021F8512 for ; Sat, 15 Dec 2012 15:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rw66e0aIHaI for ; Sat, 15 Dec 2012 15:35:45 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1236F21F84F0 for ; Sat, 15 Dec 2012 15:35:44 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1876207eaa.31 for ; Sat, 15 Dec 2012 15:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=RSdNHUQE2eKfGjWWn57DQmQAeXaymt80YESAnDUd8Fo=; b=L1/CEWcAR5ByAxiZgjxH9qKxFMeIGIrRUIeOm0AuCZ4NJ+iumLDoFNTL1mn6IndCTy NyF656LjRL26ud/mky5xYlaknlgL5I2WhFhwcH0HVrtdR6jo6IQ5ksrmEXXbgbRUCrLu lQ8x/1imj+W6AC7OwIZKyfkjw2jNp1JIZ7WJxO9YfXjEimmziheTjIJhuy6/MiNmhkMA AMwK4jviGMkAzAkRqjT2ZJpd5aPu2jMnxa24K0YyW3GPgGUTdTmKhlPcFUgq54ocXV6P +ZsKGxU/aVJVD8Ok1/IwnSKDHwU/JKMJ3icDYRv2fxYRvuMi3QBtW0vbCMKvKbYVKGs5 hhBg== Received: by 10.14.218.69 with SMTP id j45mr27058298eep.35.1355614544228; Sat, 15 Dec 2012 15:35:44 -0800 (PST) Received: from [192.168.120.17] (h-190-181.a189.priv.bahnhof.se. [85.24.190.181]) by mx.google.com with ESMTPS id q44sm18786224eep.5.2012.12.15.15.35.43 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 15:35:43 -0800 (PST) Message-ID: <1355614542.6115.19.camel@galileo.millnert.se> From: Martin Millnert To: Nick Hilliard Date: Sun, 16 Dec 2012 00:35:42 +0100 In-Reply-To: <50CCFD49.1060307@foobar.org> References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 23:35:45 -0000 On Sat, 2012-12-15 at 22:44 +0000, Nick Hilliard wrote: > On 15/12/2012 01:40, Warren Kumari wrote: > > (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000… :-P ) > > or anything in the range between 420000 -> 429999. This falls bang in the > middle of the likely range that will be assigned to ARIN. Let me hold my > nose for a moment and use asdot format: as420000 == 6.26784, and I can see > this asn being assigned in the foreseeable future in the ARIN service region. > > 900000-999999 seems to be well outside the range of any of the current RIRs > (using current allocation techniques, there could be 6 more RIRs before > there would be any interference). This is a very valid point; operational simplicity let's youtube stay reachable at night. A more clear motivation of why 100000 private ASNs would be insufficient would be interesting to read. /M From jsw@inconcepts.biz Sat Dec 15 16:26:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253A621F8536 for ; Sat, 15 Dec 2012 16:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPvbMhfIqYXj for ; Sat, 15 Dec 2012 16:26:17 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67B21F8513 for ; Sat, 15 Dec 2012 16:26:17 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so7742601ieb.31 for ; Sat, 15 Dec 2012 16:26:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6DEPeBhULcVvld1IPftlVFQapyV62W9flBGIJmmZ4tM=; b=AgKaSNXvjeMcu8UE8wVaBWwD1pGQnrVSnVdoV1yUmbDNkzyeA44PE0zwdqybViTGRO 9/lDZ+YzdgtODQ4da/wgm0fHSYbx3l9SjQxwJekMPDXIXMfLKXrIwY74cjIFu88/6IZB jDp0G424WXolhd7vGXCiEnQ53NPOHx1mUQhEYAgpEBHX30omnzpZhspW0CZ9UrvRifuV ioDgLs2PaMjP2GyH8VAULie5El+k0IvCoKopvW0DcHxDHy+votw6/fKgTayF8AwPUfE9 zTl2UiMgxdNa9W9H60a2LneVI2EyodUN+icaJRM2GeLASTzWsYs1hqYKA/dnCbZ23EjW nABw== MIME-Version: 1.0 Received: by 10.50.220.166 with SMTP id px6mr5532879igc.8.1355617576713; Sat, 15 Dec 2012 16:26:16 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sat, 15 Dec 2012 16:26:16 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <1355614542.6115.19.camel@galileo.millnert.se> References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> <1355614542.6115.19.camel@galileo.millnert.se> Date: Sat, 15 Dec 2012 19:26:16 -0500 Message-ID: From: Jeff Wheeler To: Martin Millnert Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnPDnAirbDUiHoALLSGdehTlR2L11KXjvBuaFhgEir8fo/3LTJThYCEv2Pe3NpGxg15Q/6/ Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 00:26:18 -0000 On Sat, Dec 15, 2012 at 6:35 PM, Martin Millnert wrote: > A more clear motivation of why 100000 private ASNs would be insufficient > would be interesting to read. I would also find that interesting, but I do not need to know that information to be convinced there is wisdom in allocating a large range. I thought 2^128 for IPv6 was stupid. It was an expensive choice, given the challenges which still exist in dealing with 128 bit arithmetic in many environments, FIB consumption, legibility of addresses, and so on. We do have 2^128, though, and uses are being invented for the bits. ARIN policy allows you to basically get huge IPv6 allocations based on nibble-boundaries for your ISP. Some of the largest ISPs can justify IPv6 allocations bigger than /20 (!) today. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From richih.mailinglist@gmail.com Sat Dec 15 17:15:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2500C21F8585 for ; Sat, 15 Dec 2012 17:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axRvlItlPEQX for ; Sat, 15 Dec 2012 17:15:22 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C623321F854D for ; Sat, 15 Dec 2012 17:15:21 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3747308lah.31 for ; Sat, 15 Dec 2012 17:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mmKWIDIMa05QC8u5Yi7sJGo5OVeuNaF0Rv9PnyN2VbQ=; b=M3M51VUIR08ROmdKyS0XtLgKu/ASzFQfSnOgfl+8Z+uVRlu8+1fFstBkU1IK7gRiQV 8SQttI3R/3cKZjIjCQuz1F2XstZvRmHttfyg6NmX/a+emBkoV30xYahRbNjLrk616SCA OSS+++Ra4TQxPC0cYN3JI0BHJLC9AGsuEG+edeDbzD6XPNsgrjnu5UgMlMJXndWN86k0 SoRBbxzt8p6BwpTfMvh/BlXzeaijn5ftikDpMfcz4GP/H7WQDhWAmTe2Wa1sVEB6hj90 mX4nw3zFo3jJs+KuoVCstnXNchY7b3W8oSB3iMWYEAvKWnRjm1ywM7tmlbZg2VzWWx2L 9e5A== Received: by 10.112.47.168 with SMTP id e8mr4103052lbn.46.1355620520731; Sat, 15 Dec 2012 17:15:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.170.132 with HTTP; Sat, 15 Dec 2012 17:15:00 -0800 (PST) In-Reply-To: <50CCFD49.1060307@foobar.org> References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> From: Richard Hartmann Date: Sun, 16 Dec 2012 02:15:00 +0100 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=bcaec553fde096a49304d0edff45 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:15:23 -0000 --bcaec553fde096a49304d0edff45 Content-Type: text/plain; charset=UTF-8 Dear all, I support this draft. I am unsure of where to attach my first reply in this discussion so I picked a more or less random one. There are several points to be made about the preceding discussion so I resorted to replying en bloc, no inline to specific messages. FYI, I am firmly in the operational sector and, obviously, my position reflects that. * This RFC builds upon RFC 1930, so it adds rationale for private AS, it does not need to prove it in the first place, merely to extend the range. I agree that more specific examples to support this draft would be a good thing. Both in this current discussion and for the benefit of anyone reading it in the future. * Like it or not, private AS numbers are here to stay. There's apparently a need for more than a thousand AS numbers and any new range should be chosen so that there are no foreseeable limits. ** This new range should also allow for sub-allocation within one or more private entities ** Adding a second range can ease operational pains if the first one is fragmented for historical or other reasons. Obviously, this will not help in all cases, but it's nice to have backup * Hierarchy is a proven way to contain local complexity, thus reducing global complexity ** With 2^32 AS numbers, it's very likely that operators will not limit themselves to the existing range. It's better to contain this in a well-known range. Otherwise, rogue ASes _will_ happen, over time. ** The global cost of assigning blocks of 10,000 or more AS numbers to end users in ways of new policy, synchronization across RIRs, actual implementation etc can easily be avoided with no or next to no cost * The range needs to be human readable. ** Humans should be able to detect this range at a glance ** Humans will need to implement any filters, especially when vendors have not yet implemented this new range in their code. ** While RE do exist to handle more complex numbers, decimal boundaries make this problem trivial to handle. You don't even need RE, globs will suffice. * Updating of built-in vendor filters will take some time, but claiming that `remove private-as` is ambiguous is setting up a straw-man. Simply extending the syntax would work wonderfully. `remove private-as rfcXXX` may be hamfisted, but you get the general idea. * If two entities merge/tunnel/interconnect otherwise, it's their obligation to plan ahead. I am willing to bet that AS numbers are of lesser concern in most cases than RFC1918 addresses. And even if this argument was valid, it's worse currently than it will be once this draft is published as RFC. Personally, I would tend towards 9,000,000 - 9,999,999 as that will allow ten segments of 100k AS numbers each, but the limits are more or less arbitrary. It's important to me that they are on decimal boundaries, give enough space for future use, and short enough to see at a glance, in this order. Richard --bcaec553fde096a49304d0edff45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

I support this draft.
I am unsure of where to attach my first reply in this discussio= n so I picked a more or less random one. There are several points to be mad= e about the=C2=A0preceding=C2=A0discussion so I resorted to replying en blo= c, no inline to specific messages.
FYI, I am firmly in the operational sector and, obviously, my position= reflects that.


* This RFC builds u= pon RFC 1930, so it adds rationale for private AS, it does not need to prov= e it in the first place, merely to extend the range. I agree that more spec= ific examples to support this draft would be a good thing. Both in this cur= rent discussion and for the benefit of anyone reading it in the future.

* Like it or not, private AS numbers are here to s= tay. There's apparently a need for more than a thousand AS numbers and = any new range should be chosen so that there are no foreseeable limits.
** This new range should also allow for sub-allocation within on= e or more private entities
** Adding a second range can ease oper= ational pains if the first one is fragmented for historical or other reason= s. Obviously, this will not help in all cases, but it's nice to have ba= ckup

* Hierarchy is a proven way to contain local comp= lexity, thus reducing global complexity
** With 2^32 AS numbers, = it's very likely that operators will not limit themselves to the existi= ng range. It's better to contain this in a well-known range. Otherwise,= rogue ASes _will_ happen, over time.
** The global cost of assigning blocks of 10,000 or more AS numbers to= end users in ways of new policy, synchronization across RIRs, actual imple= mentation etc can easily be avoided with no or next to no cost

* The range needs to be human readable.
** Humans = should be able to detect this range at a glance
** Humans will ne= ed to implement any filters, especially when vendors have not yet implement= ed this new range in their code.
** While RE do exist to handle more complex numbers, decimal boundarie= s make this problem trivial to handle. You don't even need RE, globs wi= ll suffice.

* Updating of built-in vendor filters = will take some time, but claiming that `remove private-as` is=C2=A0ambiguou= s is setting up a straw-man. Simply extending the syntax would work wonderf= ully.=C2=A0`remove private-as rfcXXX` may be hamfisted, but you get the gen= eral idea.

* If two entities merge/tunnel/interconnect otherwise, = it's their obligation to plan ahead. I am willing to bet that AS number= s are of lesser concern in most cases than RFC1918 addresses. And even if t= his argument was valid, it's worse currently than it will be once this = draft is published as RFC.


Personally, I would tend towards 9,000,0= 00 - 9,999,999 as that will allow ten segments of 100k AS numbers each, but= the limits are more or less arbitrary. It's important to me that they = are on decimal boundaries, give enough space for future use, and short enou= gh to see at a glance, in this order.


Richard

--bcaec553fde096a49304d0edff45-- From tony.li@tony.li Sat Dec 15 18:27:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1C121F8549 for ; Sat, 15 Dec 2012 18:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR7FY85hoYcr for ; Sat, 15 Dec 2012 18:27:52 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED5E21F8543 for ; Sat, 15 Dec 2012 18:27:51 -0800 (PST) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta13.emeryville.ca.mail.comcast.net with comcast id c2Dd1k0020x6nqcAD2Tr7r; Sun, 16 Dec 2012 02:27:51 +0000 Received: from sjc-vpn7-675.cisco.com ([128.107.239.233]) by omta12.emeryville.ca.mail.comcast.net with comcast id c2RZ1k00Z52qHCY8Y2Rf2m; Sun, 16 Dec 2012 02:25:49 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Sat, 15 Dec 2012 18:25:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> <1355614542.6115.19.camel@galileo.millnert.se> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355624871; bh=pJOiFQEubAx1ZUn15VXdJGMDN79Ut3+AwBhcBzFNLeQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=AEasOYZJSqeo7GvQ+wwJwO22QOFtgfBqY1LUWFZyNJgyDKqjWXBEriFEsFmNA0wva Y/vYBTB4FsF8nyUQcfdC4PMeIL1NypLK0heYqPJvTsmdqZQxrt43jcVxKHZy2rcN9c YZ63e40g/jv7zKZXchD2lQRDa7t70hFclwKK8R4nh3XGP1nOGhMjDmJQgZxMW+zKMu 05plI+sJrBWk+CbbqeXMvkxkJewmQSj6T+k4gnTF5t4wfZRnlnoBJzgyXJE8BOSHmx TrqzTb3gYIVW8rrXxYjPEIjmhX6rxP/MZD4iWJtTjIxLl2iWRqAJmyBnPIgcXbRya4 tnU1qeJrhL35A== Cc: IETF IDR Working Group Subject: [Idr] On FIB sizing... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 02:27:53 -0000 On Dec 15, 2012, at 4:26 PM, Jeff Wheeler wrote: > I thought 2^128 for IPv6 was stupid. It was an expensive choice, > given the challenges which still exist in dealing with 128 bit > arithmetic in many environments, FIB consumption, legibility of > addresses, and so on. =20 As an aside, FIB sizing only varies loosely with the maximum number of = bits in the address because the FIB can be constructed to hold only = prefixes. Thus, what's more important is the average and distribution = of prefix lengths. Thus, (for a core router) the choice of /128 is largely irrelevant when = remote prefixes are all /64 and shorter. For a datacenter switch that = has to store possibly many /128's, this is more of an issue, but is = offset because there is no ARP cache to deal with. Tony From jrmitche@puck.nether.net Sat Dec 15 19:16:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE3B21F8588 for ; Sat, 15 Dec 2012 19:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0Kg7CTUB7Yy for ; Sat, 15 Dec 2012 19:16:07 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6C85921F8586 for ; Sat, 15 Dec 2012 19:16:07 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBG3FwqA014524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 22:15:58 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBG3Fw4Z014523; Sat, 15 Dec 2012 22:15:58 -0500 Date: Sat, 15 Dec 2012 22:15:58 -0500 From: Jon Mitchell To: Nick Hilliard Message-ID: <20121216031557.GA14168@puck.nether.net> References: <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CCFD49.1060307@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Sat, 15 Dec 2012 22:15:58 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 03:16:08 -0000 Funny, so many peerings turned up every day and rarely does anyone mis-configure AS 10001 for AS 101, or if in the odd case it occurs, it is easily corrected. I think we are getting a bit silly if we are suggesting a commmon typo will be 4.2B to 420K... The argument for being at the end of the range is that unless something dramatically changes in regards to AS structure, a 10 digit number is definitely different looking from anything likely to be assigned. Jon On Sat, Dec 15, 2012 at 10:44:25PM +0000, Nick Hilliard wrote: > On 15/12/2012 01:40, Warren Kumari wrote: > > (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000? :-P ) > > or anything in the range between 420000 -> 429999. This falls bang in the > middle of the likely range that will be assigned to ARIN. Let me hold my > nose for a moment and use asdot format: as420000 == 6.26784, and I can see > this asn being assigned in the foreseeable future in the ARIN service region. > > 900000-999999 seems to be well outside the range of any of the current RIRs > (using current allocation techniques, there could be 6 more RIRs before > there would be any interference). > > Nick > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Sat Dec 15 19:25:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045CD21F8584 for ; Sat, 15 Dec 2012 19:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+uonp0pPR1n for ; Sat, 15 Dec 2012 19:25:55 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 56F9B21F84D4 for ; Sat, 15 Dec 2012 19:25:55 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBG3OiPe015651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 22:24:44 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBG3OiY6015649; Sat, 15 Dec 2012 22:24:44 -0500 Date: Sat, 15 Dec 2012 22:24:44 -0500 From: Jon Mitchell To: Martin Millnert Message-ID: <20121216032444.GB14168@puck.nether.net> References: <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> <1355614542.6115.19.camel@galileo.millnert.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355614542.6115.19.camel@galileo.millnert.se> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Sat, 15 Dec 2012 22:24:44 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 03:25:56 -0000 On Sun, Dec 16, 2012 at 12:35:42AM +0100, Martin Millnert wrote: > On Sat, 2012-12-15 at 22:44 +0000, Nick Hilliard wrote: > > On 15/12/2012 01:40, Warren Kumari wrote: > > > (and I sure hope I'm not the poor sod who gets allocated 4200000 or 42000000 or 420000000??? :-P ) > > > > or anything in the range between 420000 -> 429999. This falls bang in the > > middle of the likely range that will be assigned to ARIN. Let me hold my > > nose for a moment and use asdot format: as420000 == 6.26784, and I can see > > this asn being assigned in the foreseeable future in the ARIN service region. > > > > 900000-999999 seems to be well outside the range of any of the current RIRs > > (using current allocation techniques, there could be 6 more RIRs before > > there would be any interference). > > This is a very valid point; operational simplicity let's youtube stay > reachable at night. We just were worrying about someone dropping 3 digits from the number and having a conflict, and now we drop or typo one and we are in the middle of space currently in use or soon to be assigned... hmmm, failing to see the validity of some of the arguments being made here. Also - the one impacted due to a mis-configuration of the number of their private ASN is only themselves... > A more clear motivation of why 100000 private ASNs would be insufficient > would be interesting to read. > The motivation of the draft is over 1K ASN's, various folks have suggested their needs ranged in the 10K numbers today. The motivation for going beyond this is only not having to do this again (this has been repeated in the threads). The criteria for reasonable in my mind should be not consuming a large portion of the addressable space for private ASNs. I think the current draft and new proposal Warrend made still meet these criteria. Jon From jrmitche@puck.nether.net Sat Dec 15 20:02:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310B21F84CE for ; Sat, 15 Dec 2012 20:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xstOgacQRfUI for ; Sat, 15 Dec 2012 20:02:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 543B521F84CD for ; Sat, 15 Dec 2012 20:02:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBG41BqE019764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2012 23:01:11 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBG41A0q019763; Sat, 15 Dec 2012 23:01:10 -0500 Date: Sat, 15 Dec 2012 23:01:10 -0500 From: Jon Mitchell To: Richard Hartmann Message-ID: <20121216040110.GA17417@puck.nether.net> References: <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Sat, 15 Dec 2012 23:01:11 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 04:02:23 -0000 On Sun, Dec 16, 2012 at 02:15:00AM +0100, Richard Hartmann wrote: > > Personally, I would tend towards 9,000,000 - 9,999,999 as that will allow > ten segments of 100k AS numbers each, but the limits are more or less > arbitrary. It's important to me that they are on decimal boundaries, give > enough space for future use, and short enough to see at a glance, in this > order. Isn't it just as easy to spot a 10 digit number starting with 42 easier than a 7 digit number starting with 9, when 5 digit numbers starting with 9 could happen in this lifetime, while 7 8 or 9 digit numbers are unlikely to happen w/o some radical change in how ASNs are used or allocated? It sounds like both you and Nick put some value on the "make it short argument", but the proposal on the table meets your other critiera, I assume you could support it? Btw, what is the value of segments you are referring to, aren't you feel free to make these yourself out of 1M anywhere in the vast amount of space available in any of the proposals on the table? Jon From jsw@inconcepts.biz Sat Dec 15 22:18:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3521F8653 for ; Sat, 15 Dec 2012 22:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAJdtNFPy961 for ; Sat, 15 Dec 2012 22:18:55 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0362621F8652 for ; Sat, 15 Dec 2012 22:18:54 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4471764iaz.31 for ; Sat, 15 Dec 2012 22:18:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=HsHABJLueN2fTYnynmwsCwf+JHh0PoCwUtVahKSiVrc=; b=UDazrz9X4prvsAo7ygtNtSJwKw6G3hkGFyeJM52PS0eTRgNUyMEA8E8crv04PLRX3v XlsVT6w3xeff8/zn3Fe76RTTzl3vIr0+rQrzigRtZcgICnOSgOD3Tt2OonjYijN6Sy7/ uiIAqvrvKq+oLUTAwsdpV7IMMraZb/Z9IY5Rjl6/N85sSaxmt/FghyrMESB5f/QlOj5B hdvF5IoHRFLHmbiibJqAD+3ukM6YTGD5bLr+JTfWVzbH0nNx4IRE73U9HM8nJjg1zBde 7/Y+EcBE2nI3x+IphgD5auZz+K1PD9049EFDEyCkyWYtQeT1F8BG2LtGJqUgx4f8VKTz RXTQ== MIME-Version: 1.0 Received: by 10.42.180.65 with SMTP id bt1mr8364247icb.41.1355638734427; Sat, 15 Dec 2012 22:18:54 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sat, 15 Dec 2012 22:18:54 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CBB294.1000300@umn.edu> <50CCFD49.1060307@foobar.org> <1355614542.6115.19.camel@galileo.millnert.se> Date: Sun, 16 Dec 2012 01:18:54 -0500 Message-ID: From: Jeff Wheeler To: Tony Li Content-Type: multipart/alternative; boundary=90e6ba6e81d83596fb04d0f23d53 X-Gm-Message-State: ALoCoQm+NJdKDO2rU59WyoI3jU7HjsFNtCYZkoRNmyQb+uri9PFIYDIwQkAp58MUmqWNcEPcK8vv Cc: IETF IDR Working Group Subject: Re: [Idr] On FIB sizing... X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 06:18:56 -0000 --90e6ba6e81d83596fb04d0f23d53 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 15, 2012 at 9:25 PM, Tony Li wrote: > As an aside, FIB sizing only varies loosely with the maximum number of bits in the address because the FIB can be constructed to hold only prefixes. Thus, what's more important is the average and distribution of prefix lengths. Certainly true, but you reduce power/heat/die area at the expense of complexity. I would say that vendors have been doing this long enough to have pretty much mastered it, but there are products on the market right now that have sub-optimal FIB scale and will deliver greater FIB scale through software upgrades, once the software people for these boxes have time to actually implement the needed improvements. It is also the reason why people worry about whether or not their box of choice will work right if they decide to configure /120s or whatever. My results have been good, but a few people claim that specific routers do not work well in such circumstances. They are probably not wrong. > Thus, (for a core router) the choice of /128 is largely irrelevant when remote prefixes are all /64 and shorter. For a datacenter switch that has to store possibly many /128's, this is more of an issue, but is offset because *there is no ARP cache to deal with*. It would be nice if that were true. Unfortunately you are not correct. There is no router that will forward based on an L2 address encoded into a global IPv6 L3 address, even as an optional configuration knob on the subnet, egress interface, or adjacency table entry. I wish such router would hurry up and exist because it is a smart idea that has just not been implemented in products that are shipping. Most routers even need to install link-local address L3 to L2 mappings into the data-plane even though this should usually be unnecessary. If you think this means that the number of L3 to L2 mappings in the FIB is effectively doubled for subnets where the attached machines all have 1 global IPv6 address and 1 link-local address, you are right. It means a router that claims to have room for 2000 ND entries can only support 1000 machines in practice. If you think there is no "ARP cache" and thus less problems to consider with IPv6, you should learn about why Cisco has implemented a knob to limit the number of ND entries that can be used on a per-interface basis. ND cache size, churn, exhaustion attacks are a serious concern that operators will have to deal with once IPv6 adoption grows to the point that IPv6-based DDoS becomes common. Most vendors are totally ignoring this problem and it worries many of us. It is especially concerning on platforms like Cisco SUP720 where an attack of this nature will break not only IPv6 but also IPv4. My point is, raising the size of the AS number to 64 bits, or some other ridiculous size, really would not have had data-plane cost the way IPv6 address sizes do. The only place AS numbers are used in the data-plane is netflow, and abstractions can be used in place of real AS numbers there. I am not advocating any scheme that would again raise the AS number space size. I'm just pointing out that it would not increase the cost of FIBs. If anyone thought that hierarchical AS number allocation was a smart idea and private AS numbers should be eliminated by simply making enough global AS to satisfy every org with as many as they want (Randy Bush's position), then hopefully these people spoke up at the time 4-octet AS numbers were standardized. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --90e6ba6e81d83596fb04d0f23d53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 9:25 PM, Tony Li <tony.li@tony.li> wrote:
> As an aside, FIB sizing only va= ries loosely with the maximum number of bits in the address because the FIB= can be constructed to hold only prefixes. =A0Thus, what's more importa= nt is the average and distribution of prefix lengths.

Certainly true, but you reduce power/heat/die area at the expense of co= mplexity. =A0I would say that vendors have been doing this long enough to h= ave pretty much mastered it, but there are products on the market right now= that have sub-optimal FIB scale and will deliver greater FIB scale through= software upgrades, once the software people for these boxes have time to a= ctually implement the needed improvements.

It is also the reason why people worry about whether or not their box o= f choice will work right if they decide to configure /120s or whatever. =A0= My results have been good, but a few people claim that specific routers do = not work well in such circumstances. =A0They are probably not wrong.

> Thus, (for a core router) the choice of /128 is largely irrelevant= when remote prefixes are all /64 and shorter. =A0For a datacenter switch t= hat has to store possibly many /128's, this is more of an issue, but is= offset because there is no ARP cache to deal with.

It would be nice if that were true. =A0Unfortunately you are not correc= t.

There is no router that will forward based on an L2 a= ddress encoded into a global IPv6 L3 address, even as an optional configura= tion knob on the subnet, egress interface, or adjacency table entry. =A0I w= ish such router would hurry up and exist because it is a smart idea that ha= s just not been implemented in products that are shipping.

Most routers even need to install link-local address L3= to L2 mappings into the data-plane even though this should usually be unne= cessary. =A0If you think this means that the number of L3 to L2 mappings in= the FIB is effectively doubled for subnets where the attached machines all= have 1 global IPv6 address and 1 link-local address, you are right. =A0It = means a router that claims to have room for 2000 ND entries can only suppor= t 1000 machines in practice.

If you think there is no "ARP cache" and thus less problems t= o consider with IPv6, you should learn about why Cisco has implemented a kn= ob to limit the number of ND entries that can be used on a per-interface ba= sis. =A0ND cache size, churn, exhaustion attacks are a serious concern that= operators will have to deal with once IPv6 adoption grows to the point tha= t IPv6-based DDoS becomes common. =A0Most vendors are totally ignoring this= problem and it worries many of us. =A0It is especially concerning on platf= orms like Cisco SUP720 where an attack of this nature will break not only I= Pv6 but also IPv4.


My point is, raising the size of the AS number to 64 bits, or some = other ridiculous size, really would not have had data-plane cost the way IP= v6 address sizes do. =A0The only place AS numbers are used in the data-plan= e is netflow, and abstractions can be used in place of real AS numbers ther= e.

I am not advocating any scheme that would again raise t= he AS number space size. =A0I'm just pointing out that it would not inc= rease the cost of FIBs.

If anyone thought that=A0h= ierarchical=A0AS number allocation was a smart idea and private AS numbers = should be eliminated by simply making enough global AS to satisfy every org= with as many as they want (Randy Bush's position), then hopefully thes= e people spoke up at the time 4-octet AS numbers were standardized.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator =A0/ =A0Innovati= ve Network Concepts
--90e6ba6e81d83596fb04d0f23d53-- From nick@foobar.org Sun Dec 16 11:14:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D63B21F887C for ; Sun, 16 Dec 2012 11:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYTxp0kDMrGa for ; Sun, 16 Dec 2012 11:14:37 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3A99B21F886F for ; Sun, 16 Dec 2012 11:14:36 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:b437:529b:3165:e514]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBGJCr3J090001 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 16 Dec 2012 19:12:58 GMT (envelope-from nick@foobar.org) Message-ID: <50CE1D95.2000709@foobar.org> Date: Sun, 16 Dec 2012 19:14:29 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us> <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> In-Reply-To: <20121214174012.GA18502@puck.nether.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 19:14:38 -0000 On 14/12/2012 17:40, Jon Mitchell wrote: > I don't think there seems to be much concensus around any of the > discussions to change the range in the draft but there are a number of > people supporting in it's current state w/o these reservations, there > are literally billions of options we could choose from, especially when > we consider David is now suggesting two ranges (the only other person on > the list who has commented). http://www.foobar.org/~nick/router-bgp-x.pdf This is a graph of the number of google results returned for the quote-enclosed query "router bgp x", for values of x ranging from 64512 to 65535. Couple of things of note, apart from the fact that it isn't data, and that it is more likely to reflect documentation rather than what people have configured on routers: 1. "router bgp 65535" is quite common although it is officially a reserved asn. 2. there are large spikes at the beginning of the range, around 65500, and right near the end of the private ASN range. 3. there are smaller spikes at every asn which is evenly divisible by 100, and also at 65412 (i.e. 64512 with second two digits transposed - there are a lot of dyslexics in the industry), 65432, 64555, 65111. While it's not data, it does lend some credence to a hunch I had that people naturally prefer round numbers and numbers at the beginning / the end of a pre-specified range, and that they largely ignore the numbers in the middle, except for the occasional cutesy number here or there. Speculating wildly, I suspect the underlying reason for this is that people find the numbers they've chosen to be easier to remember when working with them. After all, we're human. Full config at: http://www.foobar.org/~nick/router-bgp-x.dat http://www.foobar.org/~nick/router-bgp-x.gnuplot Nick From jrmitche@puck.nether.net Mon Dec 17 08:29:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E9521F8B73 for ; Mon, 17 Dec 2012 08:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TffhLPXR8cqS for ; Mon, 17 Dec 2012 08:29:12 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 82F3621F8B6E for ; Mon, 17 Dec 2012 08:29:12 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBHGT4WR018032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 11:29:04 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBHGT3tn018031; Mon, 17 Dec 2012 11:29:03 -0500 Date: Mon, 17 Dec 2012 11:29:03 -0500 From: Jon Mitchell To: Nick Hilliard Message-ID: <20121217162903.GA15927@puck.nether.net> References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CE1D95.2000709@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CE1D95.2000709@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 17 Dec 2012 11:29:04 -0500 (EST) Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:29:13 -0000 Inline... On Sun, Dec 16, 2012 at 07:14:29PM +0000, Nick Hilliard wrote: > > 1. "router bgp 65535" is quite common although it is officially a reserved asn. Part of this (I believe) is due to the difference between RFC 1930 and IANA reservation of original range, which is clarified by this draft. Others are people not reading either, which is always likely... > > 2. there are large spikes at the beginning of the range, around 65500, and > right near the end of the private ASN range. > > 3. there are smaller spikes at every asn which is evenly divisible by 100, > and also at 65412 (i.e. 64512 with second two digits transposed - there are > a lot of dyslexics in the industry), 65432, 64555, 65111. > Speculating wildly, I suspect the underlying reason for this is that people > find the numbers they've chosen to be easier to remember when working with > them. After all, we're human. Nick - I assume you are willing to accept a modification to the proposal that makes it 4200000000 - (end) even with your stated preference for a smaller number of digits ? This provides lot's of round numbers that can be subdivided as folks see fit inside their own organizations. I'd point out that operators who plan on using only a small segment of the new space are free to embed silliness or logic (depending on your point of view) into the most significant x's like we have seen with IPv6, CLNS addresses, and other large numbers if they are overly concerned about typos or make it less likely to visually mis-identify a long string of zeros. I don't think we should carve out of the middle of the ASN space for private use if we can avoid it nor think too small since we are making a change and would prefer to progress this proposal rather than debate the billions of options as I've stated before. I'd prefer to minimize changes to the original doc at this point to only those were there is strong concensus, that seems to be developing for a change of the start of range to a decimal boundary (although I'd love to hear from a few others on their preference between the two proposals on the table). Jon From stbryant@cisco.com Mon Dec 17 10:29:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C83121F8BBB; Mon, 17 Dec 2012 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLaiBuWbibVH; Mon, 17 Dec 2012 10:29:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7B21F8B77; Mon, 17 Dec 2012 10:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=512; q=dns/txt; s=iport; t=1355768985; x=1356978585; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=dck+bk0rjEv/+grlwx0T65yVNVJXXdWaTcqbnH0isYw=; b=Y/7BHA3L7q6Mhyqqc9OS+cYhKtkLWmvHTBb0MFokJeWMcTc9KW7YR4S+ XdBU0GaKOWvdA4NlzJGUoikq6+m5tdO0lekh9XQipor7t7WvOwTmKAOKH WTYM+L1PfdwmoU0tuIdJHUPwobJzgFDs+USmB6Bax4uVayfpKfWsCY4rC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHADZiz1CQ/khR/2dsb2JhbABFg0i6axZzgl1AATwWGAMCAQIBSwEMAQcBAYgPn0aaRZEgA5YKkEiCcw X-IronPort-AV: E=Sophos;i="4.84,303,1355097600"; d="scan'208";a="148473663" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2012 18:29:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBHITgJR017592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 18:29:42 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBHITftV009601; Mon, 17 Dec 2012 18:29:41 GMT Message-ID: <50CF64A3.8060208@cisco.com> Date: Mon, 17 Dec 2012 18:29:55 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr mailing list , "mpls@ietf.org" , pce@ietf.org, pim@ietf.org, "idr-chairs@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , pce-chairs@tools.ietf.org, pim-chairs@toosl.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-ads@tools.ietf.org" Subject: [Idr] draft-ietf-karp-routing-tcp-analysis review requested X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:29:50 -0000 Hi all, draft-ietf-karp-routing-tcp-analysis is on the IESG agenda for 10/Jan. It has been through IETF LC, but we realize that it would be useful for the IDR, MPLS, PCE and PIM working groups to pay special attention to the draft review the sections of this draft that are relevant to their (your) work. I would appreciate feedback from anyone in the WG, but it would be helpful if the WG Chairs could nominate at least one person to review the draft on behalf of the WG. Thanks Stewart From internet-drafts@ietf.org Mon Dec 17 12:57:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C797321F8852; Mon, 17 Dec 2012 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jop45HsVXbD; Mon, 17 Dec 2012 12:57:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA4221F882B; Mon, 17 Dec 2012 12:57:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217205735.25501.52113.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 12:57:35 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfd-usable-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:57:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Making Route Flap Damping Usable Author(s) : Cristel Pelsser Randy Bush Keyur Patel Pradosh Mohapatra Olaf Maennel Filename : draft-ietf-idr-rfd-usable-01.txt Pages : 9 Date : 2012-12-17 Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfd-usable-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfc@btconnect.com Mon Dec 17 13:25:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6F21F8832 for ; Mon, 17 Dec 2012 13:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0lUw8D8AFta for ; Mon, 17 Dec 2012 13:25:14 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 79B8E21F8828 for ; Mon, 17 Dec 2012 13:25:14 -0800 (PST) Received: from mail99-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE011.bigfish.com (10.236.130.74) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Dec 2012 21:25:13 +0000 Received: from mail99-co9 (localhost [127.0.0.1]) by mail99-co9-R.bigfish.com (Postfix) with ESMTP id CDBE84A00AE for ; Mon, 17 Dec 2012 21:25:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I146fI542I1432I4015Izz1de0h1202h1e76h1d1ah1d2ahzz8275ch8275dh1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h) Received: from mail99-co9 (localhost.localdomain [127.0.0.1]) by mail99-co9 (MessageSwitch) id 1355779512270123_21794; Mon, 17 Dec 2012 21:25:12 +0000 (UTC) Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.237]) by mail99-co9.bigfish.com (Postfix) with ESMTP id 32F27E004B; Mon, 17 Dec 2012 21:25:12 +0000 (UTC) Received: from AM2PRD0710HT004.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Dec 2012 21:25:12 +0000 Received: from DB3PRD0210HT004.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.165.39) with Microsoft SMTP Server (TLS) id 14.16.245.2; Mon, 17 Dec 2012 21:24:58 +0000 Message-ID: <023f01cddc9c$b89e3f80$4001a8c0@gateway.2wire.net> From: t.petch To: John Scudder , "idr@ietf. org" References: <9C95F98D-B0A1-4018-8164-A00286CE652C@juniper.net> Date: Mon, 17 Dec 2012 21:23:06 +0000 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-Originating-IP: [157.56.253.69] X-FOPE-CRA-Verdict: 157.56.249.213$juniper.net%12218%4%btconnect.com%False%False%0$ X-OriginatorOrg: btconnect.com Subject: Re: [Idr] Low-order attribute flags -- when to zero X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:25:15 -0000 I had a look at RFC1771 and it says "The lower-order four bits of the Attribute Flags octet are . unused. They must be zero (and must be ignored when received)." which I find interestingly different (and clearer). Looking back at revisions thereof, the text changed between January and September 2001 but I have not tracked any discussions as to why. Tom Petch ----- Original Message ----- From: "John Scudder" To: "idr@ietf. org" Sent: Thursday, December 13, 2012 10:04 PM > Folks, > > It recently came to my attention that the following from RFC 4271 has been interpreted in at least two different ways: > > 4.3. UPDATE Message Format > ... > Path Attributes: > ... > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. > > Specifically, the disagreement is regarding "when sent". One school of thought holds that this means "when originated". Another holds that it means "when originated or propagated." > > I'm inclined toward the "when originated" interpretation. This is basically because for transitive attributes, reserved flags aren't good for much if people go resetting them all the time, just for fun. Thus, it makes sense to originate the flags as zero, but to transit them as received. > > I would like to open an erratum against RFC 4271 to clarify this. Some proposed text is below. I thought I'd open the floor for discussion before I file anything. We'd end up discussing it anyway, so this just saves one step in processing the erratum. > > Also: even if we don't use my proposed text, it's demonstrably the case that the text as written is insufficiently clear. Thus we need SOME erratum to clarify it, to whatever the WG consensus is. > > Thanks, > > --John > > Suggested text: > > Type: Technical > Section: RFC 4271 Section 4.3 > Original Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when sent and MUST be ignored when > received. > Corrected Text: > The lower-order four bits of the Attribute Flags octet are > unused. They MUST be zero when originated. When received, any > value MUST be accepted. When a BGP speaker propagates an > attribute, it MUST propagate these flags as received. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jgs@juniper.net Mon Dec 17 13:26:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC21221F882A for ; Mon, 17 Dec 2012 13:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F14QHb2DXNVI for ; Mon, 17 Dec 2012 13:26:04 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1160721F8828 for ; Mon, 17 Dec 2012 13:26:04 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUM+N64xNSG1BOZrMKP6Izt7ynGyeBf1+@postini.com; Mon, 17 Dec 2012 13:26:04 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 17 Dec 2012 13:24:55 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 17 Dec 2012 13:24:54 -0800 Received: from CO9EHSOBE005.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 17 Dec 2012 13:27:54 -0800 Received: from mail87-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Dec 2012 21:24:54 +0000 Received: from mail87-co9 (localhost [127.0.0.1]) by mail87-co9-R.bigfish.com (Postfix) with ESMTP id 31B4426030A for ; Mon, 17 Dec 2012 21:24:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371Ic85fh1432I1528I4015Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275ch17326ah8275dh1033ILz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail87-co9 (localhost.localdomain [127.0.0.1]) by mail87-co9 (MessageSwitch) id 135577949276438_30823; Mon, 17 Dec 2012 21:24:52 +0000 (UTC) Received: from CO9EHSMHS032.bigfish.com (unknown [10.236.132.229]) by mail87-co9.bigfish.com (Postfix) with ESMTP id 06668400060 for ; Mon, 17 Dec 2012 21:24:52 +0000 (UTC) Received: from BL2PRD0512HT003.namprd05.prod.outlook.com (157.56.242.197) by CO9EHSMHS032.bigfish.com (10.236.130.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Dec 2012 21:24:51 +0000 Received: from ddotzler-sslvpn-nc.jnpr.net (66.129.224.52) by pod51010.outlook.com (10.255.233.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Mon, 17 Dec 2012 21:24:49 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_6E366332-9AA2-47EC-A680-0630A3C12CDC" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Mon, 17 Dec 2012 16:24:45 -0500 References: To: "idr@ietf. org" In-Reply-To: X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.52] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:26:05 -0000 --Apple-Mail=_6E366332-9AA2-47EC-A680-0630A3C12CDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" The WGLC period has ended. Thanks to all for your thoughtful comments. = While well-considered positions were advanced both opposing, and = supporting, advancement of the document, there's a clear consensus in = favor of advancing it. So, we will request advancement.=20 There's an ongoing subthread as to what exact range to request. It seems = to be proceeding usefully, so let's extend that part of the discussion = until the solstice (December 21). Please try to confine your comments to = the subject of what range to request.=20 Thanks, --John On Nov 28, 2012, at 4:26 PM, John Scudder wrote: > Folks, >=20 > We have received a request for a working group last call on = draft-ietf-idr-as-private-reservation-00. A URL for the draft is = http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 >=20 > Please send comments to the list by December 14. [*] >=20 > Thanks, >=20 > --John >=20 > [*] Unless the world ends on December 12, in which case send them by = December 12. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --Apple-Mail=_6E366332-9AA2-47EC-A680-0630A3C12CDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" The = WGLC period has ended. Thanks to all for your thoughtful comments. While = well-considered positions were advanced both opposing, and supporting, = advancement of the document, there's a clear consensus in favor of = advancing it. So, we will request = advancement. 

There's an ongoing subthread as to what = exact range to request. It seems to be proceeding usefully, so let's = extend that part of the discussion until the solstice (December 21). = Please try to confine your comments to the subject of what range to = request. 

Thanks,

-= -John

On Nov 28, 2012, at 4:26 PM, John Scudder = <jgs@juniper.net> = wrote:

Folks,

We have received a request for a working = group last call on draft-ietf-idr-as-private-reservation-00. A URL for = the draft is http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00=

Please send comments to the list by December 14. = [*]

Thanks,

--John

[*] Unless the world ends on = December 12, in which case send them by December = 12.
_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr


= --Apple-Mail=_6E366332-9AA2-47EC-A680-0630A3C12CDC-- From internet-drafts@ietf.org Mon Dec 17 14:31:41 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C2021F8943; Mon, 17 Dec 2012 14:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7dAcjUCbF6H; Mon, 17 Dec 2012 14:31:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03D121F8932; Mon, 17 Dec 2012 14:31:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217223140.24364.5731.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 14:31:40 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:31:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Enhanced Route Refresh Capability for BGP-4 Author(s) : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-03.txt Pages : 6 Date : 2012-12-17 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-enhanced-route-refres= h-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Dec 17 14:42:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0598D21F8932; Mon, 17 Dec 2012 14:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2n+oi7xf5jL; Mon, 17 Dec 2012 14:42:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81421F8891; Mon, 17 Dec 2012 14:42:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217224213.1942.77789.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 14:42:13 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:42:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Advertisement of Multiple Paths in BGP Author(s) : Daniel Walton Alvaro Retana Enke Chen John Scudder Filename : draft-ietf-idr-add-paths-08.txt Pages : 8 Date : 2012-12-17 Abstract: In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-add-paths-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-add-paths-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From luayjalil@gmail.com Mon Dec 17 19:47:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADEA21E8040 for ; Mon, 17 Dec 2012 19:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-QgC85gW6X0 for ; Mon, 17 Dec 2012 19:47:16 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7C06921E8039 for ; Mon, 17 Dec 2012 19:47:16 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id l10so139505oag.22 for ; Mon, 17 Dec 2012 19:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=juENqZuEK+QrD5f7k3T56OkUNGMexWxN4Ca8xsJ2JQo=; b=f0rxopwwSz9Iz9f/2ktZ8ExqmCKI5uLjmRzvLzzBDdSWc+wtVsQC4D5wDcjpVhK4F/ YrfMNGtVwRRwaTknZfjjTnau9/n3y51shootTsml3F29/1X7UhyGJurmr1Upfrl+umSd 6Np0Vi3QIc+69Y+/gxxiHwOQwwiPJmuHcKcyV0wBi8tsUPdt/xvlLZXhgbAekQxwopYH NBppI+mg5dRuAmv1k9Ot6rqgWrTvKNikdtMkcjI6PEmQmeh93Gbqjt9jC1neReF5RunR TwYW+uJ4OYgOR701KpJNr03pX03OR3KLIBR6E1jcKcBQojxt8xJDGJvWIe99aEw32Iu3 L6lA== X-Received: by 10.182.146.107 with SMTP id tb11mr476303obb.30.1355802436009; Mon, 17 Dec 2012 19:47:16 -0800 (PST) Received: from xlr8r (76-204-213-170.lightspeed.allntx.sbcglobal.net. [76.204.213.170]) by mx.google.com with ESMTPS id zn9sm387817obb.23.2012.12.17.19.47.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 19:47:14 -0800 (PST) From: "Luay" To: "'John Scudder'" , "'idr@ietf. org'" References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> In-Reply-To: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> Date: Mon, 17 Dec 2012 21:47:13 -0600 Message-ID: <005701cddcd2$5e342150$1a9c63f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3UAvdwPi/ef/biTV6m4tARfc/IeQFfN4zA Content-Language: en-us Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:47:17 -0000 Support Luay -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: Thursday, December 06, 2012 4:39 PM To: idr@ietf. org Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Folks, The authors have requested IDR adopt draft-svshah-interdomain-sla-exchange-03 as a working group document. Please send any comments to the list by the Winter Solstice (December 21). Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From usenet@sxi.dk Tue Dec 18 00:53:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23DD21F87DE for ; Tue, 18 Dec 2012 00:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuOyRkTxcc1W for ; Tue, 18 Dec 2012 00:53:13 -0800 (PST) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id AEEDC21F87D8 for ; Tue, 18 Dec 2012 00:53:12 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id jg9so134692bkc.28 for ; Tue, 18 Dec 2012 00:53:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=rhGF65DzQ45BDbcBkGpGokOkTZgvfTxfWpQ92dViTR4=; b=gnCBXRZfytwHBjoyELZrg13oRVRZ9ucCH2chO/ZYb/ronMeii2/GInQjn9N678kCYP PMrNYqAOXGPHiC10amw+xH+C2SwZ9BDncJqQ+SztcxYnybZYOtjyRIDmPdzSOrRjRJjH pKNOZ9oJsH8IG4lT96zOAMwK/OcXRErqCPT6iD0UXv5sv7Qi1dU7ZGyCoxqhFmnFj+DN PWt86+pG9BZFoX+MGTY10l1V1D4ox49aW1paNg5qChjkIXG0CpN9V8kvKkHvxvv4ZM2p 3F5RiTV7uPNObKYrYktjZuUTyEzvcs0Y3Rn0a+1f2Ry2z3z50/2Pas0ifFRv6lC4K+2O 5ZtA== X-Received: by 10.204.5.205 with SMTP id 13mr397763bkw.111.1355820791137; Tue, 18 Dec 2012 00:53:11 -0800 (PST) Received: from gmail.com ([2a02:188:2:d6:baaa:aaaa:aaad:f00d]) by mx.google.com with ESMTPS id e22sm497535bke.14.2012.12.18.00.53.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 00:53:10 -0800 (PST) Date: Tue, 18 Dec 2012 09:53:08 +0100 From: Allan Eising To: idr@ietf.org Message-ID: <20121218085308.GA22992@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQnU/RVf5qXcKC4caWt/cLK/7rd0GrLD+AMxyImAcDT+798Zyalmxl+78AlL7hRUfCwU5msj Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 08:53:14 -0000 > From: idr-bounces at ietf.org [mailto:idr-bounces at > ietf.org] On Behalf Of John Scudder > Sent: Thursday, December 06, 2012 2:39 PM > To: idr at ietf. org > Subject: [Idr] WG adoption requested for > draft-svshah-interdomain-sla-exchange-03 > > Folks, > > The authors have requested IDR adopt > draft-svshah-interdomain-sla-exchange-03 as a working group document. > > Please send any comments to the list by the Winter Solstice (December 21). > > Thanks, > > --John Support. I see some very interesting possibilities here. From internet-drafts@ietf.org Tue Dec 18 01:38:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C81C21F87F2; Tue, 18 Dec 2012 01:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02EXEv5XN3Pt; Tue, 18 Dec 2012 01:38:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB3721F879F; Tue, 18 Dec 2012 01:38:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121218093818.30258.96602.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 01:38:18 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:38:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : IPv6 Extensions for Route Target Distribution Author(s) : Keyur Patel Robert Raszuk Martin Djernaes Jie Dong Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-03.txt Pages : 7 Date : 2012-12-18 Abstract: The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-ipv6-rt-constrain-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-ipv6-rt-constrain-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Dec 18 07:16:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0151F21F892E for ; Tue, 18 Dec 2012 07:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+TtAwf3LfYZ for ; Tue, 18 Dec 2012 07:16:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 743EF21F874D for ; Tue, 18 Dec 2012 07:16:10 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1C701264412; Tue, 18 Dec 2012 16:16:09 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EAFF027C067; Tue, 18 Dec 2012 16:16:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 18 Dec 2012 16:16:08 +0100 From: To: John Scudder , "idr@ietf. org" Date: Tue, 18 Dec 2012 16:16:07 +0100 Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: Ac3UAvcKss0w9mNdQFq1XDLO02pl2AI+nIOQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E9D4AEA34@PUEXCB1B.nanterre.francetelecom.fr> References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> In-Reply-To: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:16:11 -0000 Dear chairs, I support the wg adopts this I-D. Cheers, Med >-----Message d'origine----- >De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la=20 >part de John Scudder >Envoy=E9 : jeudi 6 d=E9cembre 2012 23:39 >=C0 : idr@ietf. org >Objet : [Idr] WG adoption requested for=20 >draft-svshah-interdomain-sla-exchange-03 > >Folks, > >The authors have requested IDR adopt=20 >draft-svshah-interdomain-sla-exchange-03 as a working group document. > >Please send any comments to the list by the Winter Solstice=20 >(December 21). > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr >= From christian.jacquenet@orange.com Tue Dec 18 07:33:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F4421F8AAF for ; Tue, 18 Dec 2012 07:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFThk4doiJAp for ; Tue, 18 Dec 2012 07:33:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6721F8AB0 for ; Tue, 18 Dec 2012 07:33:16 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 84E3E3B4114; Tue, 18 Dec 2012 16:33:15 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 67E614C06C; Tue, 18 Dec 2012 16:33:15 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 18 Dec 2012 16:33:15 +0100 From: To: John Scudder , "idr@ietf. org" Date: Tue, 18 Dec 2012 16:33:14 +0100 Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: Ac3UAvcKss0w9mNdQFq1XDLO02pl2AI+nIOQAA3gCEA= Message-ID: <19131_1355844795_50D08CBB_19131_1384_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A61EBBA64@PUEXCB1C.nanterre.francetelecom.fr> References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> <94C682931C08B048B7A8645303FDC9F36E9D4AEA34@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9D4AEA34@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:33:21 -0000 Support. Cheers, Christian. >-----Message d'origine----- >De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de=20 >John Scudder Envoy=E9 : jeudi 6 d=E9cembre 2012 23:39 =C0 : idr@ietf. org= =20 >Objet : [Idr] WG adoption requested for >draft-svshah-interdomain-sla-exchange-03 > >Folks, > >The authors have requested IDR adopt >draft-svshah-interdomain-sla-exchange-03 as a working group document. > >Please send any comments to the list by the Winter Solstice (December=20 >21). > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bduvivie@cisco.com Tue Dec 18 12:35:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2E21F85AF for ; Tue, 18 Dec 2012 12:35:07 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7J-LsIUSUU4 for ; Tue, 18 Dec 2012 12:35:07 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1121F8532 for ; Tue, 18 Dec 2012 12:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=472; q=dns/txt; s=iport; t=1355862907; x=1357072507; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6q86/v0cK9srUbn5Yyn/W9pD2+XFPVWtGXjVMS0V9as=; b=gaDwl2P0mIogz3SIZYmSqEaFBcS+OWwth4WZg8piM+nWJrYv5miHRxvF YmGpUldMS/xr7K0QWtNuwdvNGDis2+k1lLvx11/jLQlY2d7SdzVyhkg7q EQG8vp5Xo+D/BMdbamGwpYt/Aw4zgKAOycFVkTWy6P4M6mfcVRk4UrsYV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAFzS0FCtJV2Z/2dsb2JhbABFhXS4MhZzgh8BAQQBAQE3NBsCAQgiFBAnCyUCBBMIiAsMqA6QLQSQK2EDplKCdIIi X-IronPort-AV: E=Sophos;i="4.84,310,1355097600"; d="scan'208";a="154355867" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 18 Dec 2012 20:35:06 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBIKZ6t2022019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Dec 2012 20:35:06 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.171]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 14:35:06 -0600 From: "Bertrand Duvivier (bduvivie)" To: "idr@ietf.org" Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: AQHN3K7S5Bccin6hlkuFHAhy9qbWZpgfA87g Date: Tue, 18 Dec 2012 20:35:06 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1524AF34@xmb-aln-x11.cisco.com> References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> <4931A85EED76CA48BD52F2D94E7FAB0E0318A6@xmb-aln-x09.cisco.com> In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E0318A6@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.113.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 20:35:07 -0000 Hi, I do support it BRGDS Bertrand Duvivier On 12/6/12 2:39 PM, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-svshah-interdomain-sla-exchange-03 as a working group document. > >Please send any comments to the list by the Winter Solstice (December 21). > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From knoll@etit.tu-chemnitz.de Tue Dec 18 15:25:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7207E21F8606 for ; Tue, 18 Dec 2012 15:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIQf0lDHeUD5 for ; Tue, 18 Dec 2012 15:25:13 -0800 (PST) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3821F85FC for ; Tue, 18 Dec 2012 15:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Sender:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3zjA6Tsfvng9BXxQGmAZF0aG4Wcv/QkhUzphuZ8wUYk=; b=ee7HQ+KPCIyPo2h+vhf5wPkGWLvhwX0C/7wr0ecWUzEB6vVAaqodu+v0ag7ZD3yU6hfqLKVemfpxJ9JwBINOjfhmlqvER0X5lan2IYroLvdHXy/HqajnbB1QrcBrzGMu6F+s6qZpbXlNi/gJtM7CWqDcwzbhR/1zWE8ZOAq7sSs=; Received: from pat.hrz.tu-chemnitz.de ([134.109.133.4] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tl6X9-0002zl-KM; Wed, 19 Dec 2012 00:25:11 +0100 Received: from vpnclient-203-182.hrz.tu-chemnitz.de ([134.109.203.182]) by mailbox.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tl6X9-0007RQ-3O; Wed, 19 Dec 2012 00:25:11 +0100 Message-ID: <50D0FB43.7010104@etit.tu-chemnitz.de> Date: Wed, 19 Dec 2012 00:24:51 +0100 From: "Thomas M. Knoll" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Scudder References: <20121218085308.GA22992@gmail.com> In-Reply-To: <20121218085308.GA22992@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: knoll@etit.tu-chemnitz.de X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2012-12-19 00:25:11; e8fec75447561fe7eab6ab66405225f2 X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1355873111-00005597-28CFD77C/0-0/0-0 X-Scan-SA: nick.hrz.tu-chemnitz.de; 2012-12-19 00:25:11; 6c531e0737d018ed3a99487dc420e62d Cc: idr@ietf.org Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:25:14 -0000 I am happy to see increased interest by IDR for interdomain QoS signalling. Thus my +1. Thanks, Thomas -- http://tools.ietf.org/html/draft-knoll-idr-cos-interconnect http://tools.ietf.org/html/draft-knoll-idr-qos-attribute > From: idr-bounces at ietf.org [mailto:idr-bounces at > ietf.org] On Behalf Of John Scudder > Sent: Thursday, December 06, 2012 2:39 PM > To: idr at ietf. org > Subject: [Idr] WG adoption requested for > draft-svshah-interdomain-sla-exchange-03 > > Folks, > > The authors have requested IDR adopt > draft-svshah-interdomain-sla-exchange-03 as a working group document. > > Please send any comments to the list by the Winter Solstice (December 21). > > Thanks, > > --John From wwwrun@rfc-editor.org Tue Dec 18 17:48:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C2021F86CA; Tue, 18 Dec 2012 17:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.87 X-Spam-Level: X-Spam-Status: No, score=-101.87 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x47CDK3vdaUS; Tue, 18 Dec 2012 17:48:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02721F8617; Tue, 18 Dec 2012 17:48:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 29CF7B1E008; Tue, 18 Dec 2012 17:39:42 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121219013942.29CF7B1E008@rfc-editor.org> Date: Tue, 18 Dec 2012 17:39:42 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 6793 on BGP Support for Four-Octet Autonomous System (AS) Number Space X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 01:48:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6793 Title: BGP Support for Four-Octet Autonomous System (AS) Number Space Author: Q. Vohra, E. Chen Status: Standards Track Stream: IETF Date: December 2012 Mailbox: quaizar.vohra@gmail.com, enkechen@cisco.com Pages: 12 Characters: 26366 Obsoletes: RFC4893 Updates: RFC4271 I-D Tag: draft-ietf-idr-rfc4893bis-07.txt URL: http://www.rfc-editor.org/rfc/rfc6793.txt The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From farmer@umn.edu Wed Dec 19 05:58:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD521F8578 for ; Wed, 19 Dec 2012 05:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NBArv++yEIp for ; Wed, 19 Dec 2012 05:58:36 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4359A21F8505 for ; Wed, 19 Dec 2012 05:58:36 -0800 (PST) Received: from mail-ob0-f199.google.com (mail-ob0-f199.google.com [209.85.214.199]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 19 Dec 2012 07:58:16 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f199.google.com [209.85.214.199] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f199.google.com with SMTP id 16so8389547obc.10 for ; Wed, 19 Dec 2012 05:58:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=on99wB6jbHhhfNec7EXRQdYBGAWNBNQs3yyhjhE5/uA=; b=HdVdYQCBoAvHkjPHCqbptRizybuPpDv1Hg044Ox6Gfff/K6oskqMqGGlDq1qEu/+EG HfcfyZcchPxbMk92T0MnmdPNwHAiR4XRFZ2DQp4gFB+s5CPDSGI57OgCb0RXoJMoqfJH 9MclHUxP+kIz22NlYwa9Hc7r7N8Vrus/R81uUjx2Lvyz/E25lBnE9/MghsyrYN0CKjcF fwIJEgcJBXqy/7PxVwQLkHoU3xwfOVvHMflC+cEduj+sekMBejoZ3mKNfpugHcAMiys0 ZtmzikQ44WBpd569GkUAhEyu+6pcfhJ/Pr6TWwHUI00fazkBYkp47HT4D5YYmG+Md/6v AexA== X-Received: by 10.50.161.232 with SMTP id xv8mr6743597igb.22.1355925496143; Wed, 19 Dec 2012 05:58:16 -0800 (PST) X-Received: by 10.50.161.232 with SMTP id xv8mr6743588igb.22.1355925495980; Wed, 19 Dec 2012 05:58:15 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id fa6sm4188839igb.2.2012.12.19.05.58.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 05:58:15 -0800 (PST) Message-ID: <50D1C7F5.6030406@umn.edu> Date: Wed, 19 Dec 2012 07:58:13 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "idr@ietf. org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnG1Uhur52fCMzVaHOeCQbYIY/CpWJx0gmCgD4eSwkKh/A50UHARaPO2hVQLLahGjpHZzqigafcIYfB9pxT0+x528+/x6YXZjX7ad8ycGrgW54OoKOuBEFK6qdKkSqgs1F6I0Aw Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:58:37 -0000 On 12/17/12 15:24 , John G. Scudder wrote: > The WGLC period has ended. Thanks to all for your thoughtful comments. > While well-considered positions were advanced both opposing, and > supporting, advancement of the document, there's a clear consensus in > favor of advancing it. So, we will request advancement. Good to hear. > There's an ongoing subthread as to what exact range to request. It seems > to be proceeding usefully, so let's extend that part of the discussion > until the solstice (December 21). Please try to confine your comments to > the subject of what range to request. On the issue of the exact range; I have trouble supporting the idea of starting the range at 4B or 4.2B, I see no justification for reserving nearly 300M or even 100M ASNs for private use. The original discussion was that the 1023 we have now isn't enough, I agree, as do most of the rest of you it seems. There were numbers in the 10k to 50K range talked about as reasonable numbers that people saw immediate use cases for. It was then discussed to round that up a couple orders of magnitude so we wouldn't have to revisit this again in our life-times. That seemed like a good idea. So, 1M was talked about and since there are now 4B ASNs that didn't sound that unreasonable, its only 0.02% of the 32bit ASNs. And the original 1023 is 1.5% of the 16bit ASNs by comparison. In discussions and through a poll at the working group meeting, the top 24bits of the 32bit range was selected, that's now 16M ASNs, another order of magnitude plus some. That choice was arbitrary, but 24bits is at least explainable as a nice bit boundary, and its still is only 0.4% of the 32bit ASNs, this is what the draft has in it currently. Now the issue of a human/decimal/regexp friendly range has come up as being very desirable, I think this is a valid issue. However, I see no justification to add yet another order of magnitude or more of ASNs to achieve this goal, taking it to the 100M or 300M range of ASNs and using 2% or 7% of the 32bit ASNs. We can start the range at a fairly reasonable point from a human/decimal/regexp friendliness point of view and actually reduce the size of the range just a little in the process, by selecting 4.28B as the beginning of the private ASN range. Leaving just under 15M private ASNs for use. This seems like way more than enough and several orders of magnitude more than any use cases I've heard of. And, there would be no danger of any entity running out, probably any 100 entities for that matter. I just had another thought for making them even more human/decimal/regexp friendly. What if as-plain was changed to use 32bit ones' complement representation. Then the range in the draft would be 4278190080 to 4294967294 in 32bit decimal or -1677215 to -1 in 32bit ones' complement, that's probably not going to happen, but they sure would be human/regexp friendly. :) Also, it doesn't look like this was explored, at least not in the text of RFC 5396. Hey we could even call it as-neg-plain. :) Enough math geek silliness. So, if someone can provide a reasonable justification for 100M private use ASNs, or even 10M for that matter, I'm all ears. Otherwise my suggestion is to start the range at 4.28B Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From rraszuk@gmail.com Wed Dec 19 06:41:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6496821F84FF for ; Wed, 19 Dec 2012 06:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.945 X-Spam-Level: X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toQOcoli7e9A for ; Wed, 19 Dec 2012 06:41:09 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8374621F84ED for ; Wed, 19 Dec 2012 06:41:09 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 17so2819944iea.16 for ; Wed, 19 Dec 2012 06:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+Q9j7dr6Sb+7ZuIphbVToyq6RUsNbgAGCjGyyPAQRuA=; b=kf79mZ7jofqV/tVsOpk2XoUeuyPYpILg0NURT6BBpJmc3HpqgTT2Ae1RfAYKRIGT4y dyysN/jTfQwGLiGn5+0cOuU4vO8fU+rf6ImfjGarQMUKmRfSZFfNjXxRZ1X1QY9Yjv2t Kt250Bna1HkfbzV6G5rGeYFlE6TAJO5Bfgp/7fAd/20hHzG1q1vtRG2ayCOi0YpdhaOr d4PXn+ZVX6UZub0t56zgGGTW7mperg/j1tchR56J5k1TQSdPMnvzF+NL1KfXiqPrDVUz ee9GyTeGE61xHN68aSSmvRwLVWO0T/igBJbn2g8aChNjqHh13o2/kl26zozHr/n/9er9 4kEQ== MIME-Version: 1.0 Received: by 10.42.118.13 with SMTP id v13mr5922847icq.44.1355928069059; Wed, 19 Dec 2012 06:41:09 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Wed, 19 Dec 2012 06:41:08 -0800 (PST) In-Reply-To: <50D1C7F5.6030406@umn.edu> References: <50D1C7F5.6030406@umn.edu> Date: Wed, 19 Dec 2012 15:41:08 +0100 X-Google-Sender-Auth: ZlQba1gIAifNpbhfm66lF97IjoQ Message-ID: From: Robert Raszuk To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:41:10 -0000 Hello David, > So, if someone can provide a reasonable justification for 100M private use > ASNs, or even 10M for that matter, I'm all ears I think we are all observing exponential rate of office backends being outsourced. Also notice that grow of public AS numbers is not that steep. Through last 12 years we allocated 50K ! http://www.potaroo.net/tools/asns/ So IMHO it is not that unrealistic that some global SP (maybe Google, Microsoft, Apple2 etc... :) could offer free Internet access everywhere they could reach or where law mandates free "last mile". Would we want to limit number of their global customers ? Would we really need to invent new hacks to work around private AS number starvation ? Of course it is dead clear that Internet access does not mandate use of BGP even for multihomed sites (example: LISP). But this is IDR so I guess talking about BGP here is ok. My seemingly wild suggestions to offer half of the space as private or think about make AS hierarchical were aiming precisely in such new EBGP (or EBGP-lite) peerings for large numbers of IPv4/IPv6/VPNs customers. If someone would to use this new RFC for such applications let me reverse the question .. do we have sufficient reasons to limit the space to 1M customers ? Are we afraid that even if we reserve 31 bits the public AS will experience shortage anytime soon considering current grow rate of public as number assignments ? Best wishes, R. From jrmitche@puck.nether.net Wed Dec 19 06:57:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5642421F863C for ; Wed, 19 Dec 2012 06:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LqJjk0vGX+1 for ; Wed, 19 Dec 2012 06:57:07 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 133DC21F85E6 for ; Wed, 19 Dec 2012 06:57:07 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBJEv6kP012818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 09:57:06 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBJEv6DZ012817; Wed, 19 Dec 2012 09:57:06 -0500 Date: Wed, 19 Dec 2012 09:57:06 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121219145706.GA3846@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D1C7F5.6030406@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 19 Dec 2012 09:57:06 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:57:08 -0000 On Wed, Dec 19, 2012 at 07:58:13AM -0600, David Farmer wrote: > On 12/17/12 15:24 , John G. Scudder wrote: > >There's an ongoing subthread as to what exact range to request. It seems > >to be proceeding usefully, so let's extend that part of the discussion > >until the solstice (December 21). Please try to confine your comments to > >the subject of what range to request. > > On the issue of the exact range; > > I have trouble supporting the idea of starting the range at 4B or > 4.2B, I see no justification for reserving nearly 300M or even 100M > ASNs for private use. I agree there is no immediate use case I'm aware of for such a large range, I'm failing to see any cons as none of the proposals poses any real threat to the overall space (I think any real threat to future changes in allocation or use of the 4B ASN space to maximum would come from putting the range in places other than the start or end). > > I agree, as do most of the rest of you it seems. There were numbers > in the 10k to 50K range talked about as reasonable numbers that > people saw immediate use cases for. It was then discussed to round Trying to predict the future is hard. BGP on VMs could make these ranges far too small. This is not to meant to say that eBGP with private use ASN's has some specific use case scenario here I think we need to delve into to further the discussion, but it does seem within the realm of possibility that a single organization (NOT AN ISP or someone assigning numbers externally) could exceed a 10-100K range with certain use cases. This is a viable enough business that companies are selling BGP routers on VM's as products... > that up a couple orders of magnitude so we wouldn't have to revisit > this again in our life-times. That seemed like a good idea. So, 1M I think this continues to be a very good idea so this issue does not need to be re-visited. > another order of magnitude plus some. That choice was arbitrary, The original range was arbitrary, the new range is arbitrary, most naming and numbering is. By putting it at end of range it is somewhat less abitrary as it's a convention at least. > Now the issue of a human/decimal/regexp friendly range has come up > as being very desirable, I think this is a valid issue. However, I > see no justification to add yet another order of magnitude or more > of ASNs to achieve this goal, taking it to the 100M or 300M range of > ASNs and using 2% or 7% of the 32bit ASNs. I agree 7% is too big. 2% does not seem unreasonable to me. > > We can start the range at a fairly reasonable point from a > human/decimal/regexp friendliness point of view and actually reduce > the size of the range just a little in the process, by selecting > 4.28B as the beginning of the private ASN range. Leaving just under > 15M private ASNs for use. This seems like way more than enough and I'm OK with this proposal as well. It (42[8-9]...) is not quite as identifiable or human friendly as 42... , but fairly close. In the view of the overall space, I don't think this is a a vastly different proposal (in other words, the savings of this number of ASNs may not be useful, but I'm fine with it, although I still prefer Warren's suggestion). Maybe some others would like to weigh in on one of the above options now that it's a focused discussion (otherwise I plan to make the small edits discussed in previous threads and move the start of range to 42xxxxxxxx so we can close this out...) Jon From jsw@inconcepts.biz Wed Dec 19 07:12:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC18321F8696 for ; Wed, 19 Dec 2012 07:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x651leIatJaG for ; Wed, 19 Dec 2012 07:12:32 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6721F8621 for ; Wed, 19 Dec 2012 07:12:31 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so2861532ieb.39 for ; Wed, 19 Dec 2012 07:12:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=12A/Pqt4waZPf4XXxf4L4jNgwMH6E7SobsFAJ5HPoU0=; b=ZBQohFkUAz0nZD4n3WCNwuHzibQQLunJPCE/4hLtyA7PjBkGg6ScsiQ2R/AEtztL3f F3RnBKJ1Xc5HK32bu0FObTu+9CzvmNbOWW3geMFhKpqQMkfvpvfmpwKdBNvv1PUqg0Qp 5v2P3ljx7CHbUQ4FYtrQAlWAHRjZeH583ObvyXR9HmTcxWfyQie1mc6lqRfezRAP8CZE 3izBClv5cNn06Ti7yoVf8Z50LtwO6Ky2bn5ckXvBGPq5l0TSXFRL+TIxcRw4Sqvm0hbk VdaQspHOSymWarlB1RBkDpmJvBhG0kjNh6fbMAgaRWSJXLpt/ZJeW5/o2lX3lqVoAW0V nRsw== MIME-Version: 1.0 Received: by 10.50.187.225 with SMTP id fv1mr2297493igc.96.1355929951387; Wed, 19 Dec 2012 07:12:31 -0800 (PST) Received: by 10.64.132.33 with HTTP; Wed, 19 Dec 2012 07:12:31 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20121219145706.GA3846@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> Date: Wed, 19 Dec 2012 10:12:31 -0500 Message-ID: From: Jeff Wheeler To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlAqEH8UF6Jn8l4Cv8f4A/D1EDEoPpjQ9TBIWgBJapNBS4llRZmVsr5mlHfLejyC6Tlhxce Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:12:39 -0000 On Wed, Dec 19, 2012 at 9:57 AM, Jon Mitchell wrote: > I agree 7% is too big. 2% does not seem unreasonable to me. Do you foresee other kinds of large reservations being made from the 32-bit ASN space? If NO, then 7% is not too big. If it were, 2% would also be too big. If you think public ASNs will be exhausted again in the future, and having 5% more public ASNs will prevent that eventual exhaustion, I'd love to see a basis for that prediction. Basically, what I'm saying is, if 7% is too big then now is a good time to start talking about 64-bit ASNs. Everyone knew the 16-bit ASN space would probably need expansion, and most folks I know came to that realization in the mid- to late-1990s. It's 2012 now and we still do not have an extended BGP community formatted as 32:32 bits, which is needed by numerous operators for BGP route advertisement control. Some major transit networks still don't have 32-bit ASN support for their customers. If 15 years isn't enough to go from problem realization to feature-complete and widely-deployed fix, then please, stop worrying about 7% or 2% and start crying that "the sky is falling," so you can have 64-bit ASNs before you run out of 32-bit ones. If YES, you do imagine other large reservations being made from the 32-bit ASN space, have there been any proposals? Will these proposals, combined with existing public ASN use, exhaust 93% of the 32-bit space but not 98% of it? The only "threat" I see to the 32-bit ASN space is the notion that RIR policy should allow delegation of large blocks of ASNs to organizations (companies, service providers) for whatever uses they can imagine. If that happens, I do not think +/- 5% global ASN pool size will make a difference. Either such RIR policy will run the ASNs out, or it won't. > Maybe some others would like to weigh in on one of the above options now > that it's a focused discussion (otherwise I plan to make the small edits > discussed in previous threads and move the start of range to > 42xxxxxxxx so we can close this out...) I asked some operators about decimal vs bit-aligned, and virtually all feel strongly in favor of decimal-alignment. I asked some to choose between starting a larger private range at 900k, 9000k, or 4.2b, and found there is much less interest in even expressing an opinion at that point. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jrmitche@puck.nether.net Wed Dec 19 07:20:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC4921F87AE for ; Wed, 19 Dec 2012 07:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3B4-QzqRO58 for ; Wed, 19 Dec 2012 07:20:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id C2DCC21F87A6 for ; Wed, 19 Dec 2012 07:20:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBJFKMer017626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 10:20:22 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBJFKM5D017625; Wed, 19 Dec 2012 10:20:22 -0500 Date: Wed, 19 Dec 2012 10:20:22 -0500 From: Jon Mitchell To: Robert Raszuk Message-ID: <20121219152021.GB3846@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 19 Dec 2012 10:20:22 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:20:23 -0000 On Wed, Dec 19, 2012 at 03:41:08PM +0100, Robert Raszuk wrote: > Hello David, > > > So, if someone can provide a reasonable justification for 100M private use > > ASNs, or even 10M for that matter, I'm all ears > > I think we are all observing exponential rate of office backends being > outsourced. Also notice that grow of public AS numbers is not that > steep. Through last 12 years we allocated 50K ! > http://www.potaroo.net/tools/asns/ I agree that this is the case. > So IMHO it is not that unrealistic that some global SP (maybe Google, > Microsoft, Apple2 etc... :) could offer free Internet access > everywhere they could reach or where law mandates free "last mile". > Would we want to limit number of their global customers ? Would we > really need to invent new hacks to work around private AS number > starvation ? Of course it is dead clear that Internet access does not > mandate use of BGP even for multihomed sites (example: LISP). But this > is IDR so I guess talking about BGP here is ok. > > My seemingly wild suggestions to offer half of the space as private or > think about make AS hierarchical were aiming precisely in such new > EBGP (or EBGP-lite) peerings for large numbers of IPv4/IPv6/VPNs > customers. > > If someone would to use this new RFC for such applications let me > reverse the question .. do we have sufficient reasons to limit the > space to 1M customers ? Are we afraid that even if we reserve 31 bits > the public AS will experience shortage anytime soon considering > current grow rate of public as number assignments ? I think there is hope that there will be interesting growth on the Internet or globally unique identifier use cases with Public ASN registrations and that RIR policies may change to encourage these use cases over time. It's hard to tell if you are seriously suggesting a 50% proposal still, but I would consider this is a substantive change to the intent, motivation and content of the draft which is for a single organization (and Private Use) and would probably require a new draft. I can't accept a proposal to move to 50% in the draft and there seemed to be no energy from anyone that this is the right direction. It also seems to then remove the possibility that these types of allocations would be from Public space, and disallow other proposals such as the one you started a seperate thread about by consuming too much of the overall space to make them acceptable any longer (there by forcing more use cases with large number of ASN needs into Private Use space). However if your overall point is that 10M - 100M is not unreasonable for this draft as is, I agree and think certain variations of use cases (more the backend ones) you identified above would be Private Use if a single organization is allocating and managing the ASNs (in my mind more likely the large office backend customers than a provider, or a provider using BGP in these scenarios transparently / not managed by the customer). Jon From rraszuk@gmail.com Wed Dec 19 07:25:28 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B264021F8A6A for ; Wed, 19 Dec 2012 07:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtJuL7kfKo0M for ; Wed, 19 Dec 2012 07:25:25 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id D251C21F8A67 for ; Wed, 19 Dec 2012 07:25:24 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id gj3so2033254lbb.11 for ; Wed, 19 Dec 2012 07:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=q0clJ9qHq6tfOhH4C2XV+yQEa75QX8rPslnRPVe9X3k=; b=K3Eis6VAYyctU0AitT3yExb8VzZd+G+wjeUlNhwW52znx1xxqGCeaWHSuvbUj73Cjc Pr6Gqsyy41A84/4U40puvb3OfRkx0f9h2ZVq2grbrlqdYo17IAdjoo2bGc0L1L/Fo7tJ QsDVd98+0DY0IdQSbmk+3o7cCVV0qC46io5lyXfcyqp/thR0ChQSGql+cJzKT4JE6pTE 3nLm0B6N5HJ6DulUAfEJNZ9d5cKHjQbXZVvdF0FbzAIE9ZnU1UigwdmIuRXvbTf3IQBW kWSiGuWytktPCAP+z8v8+ZfIfPFtA0DUUgEUiuU2v4XreACLdlZEjsqPSOvDJmBFS4YP cUpA== MIME-Version: 1.0 Received: by 10.112.44.229 with SMTP id h5mr2549229lbm.12.1355930723782; Wed, 19 Dec 2012 07:25:23 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.39.36 with HTTP; Wed, 19 Dec 2012 07:25:23 -0800 (PST) In-Reply-To: <20121219152021.GB3846@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219152021.GB3846@puck.nether.net> Date: Wed, 19 Dec 2012 16:25:23 +0100 X-Google-Sender-Auth: g8NyYqr6jPmh6TvQ0JJGgeWJ220 Message-ID: From: Robert Raszuk To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:25:28 -0000 Hi Jon, > However if your overall point is that 10M - 100M is not unreasonable for > this draft as is, I agree and think certain variations of use cases > (more the backend ones) you identified above would be Private Use if a > single organization is allocating and managing the ASNs (in my mind more > likely the large office backend customers than a provider, or a provider > using BGP in these scenarios transparently / not managed by the customer). That's precisely my overall point. The 50% was just the example of illustration so we see the full pendulum here not just it's small section ;-) Cheers, R. From nick@foobar.org Wed Dec 19 07:35:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF92C21F8820 for ; Wed, 19 Dec 2012 07:35:31 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt5DaFZfpnQ5 for ; Wed, 19 Dec 2012 07:35:30 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A5E8521F8430 for ; Wed, 19 Dec 2012 07:35:29 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBJFXmhu036646 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 15:33:48 GMT (envelope-from nick@foobar.org) Message-ID: <50D1DEBF.7040500@foobar.org> Date: Wed, 19 Dec 2012 15:35:27 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CE1D95.2000709@foobar.org> <20121217162903.GA15927@puck.nether.net> In-Reply-To: <20121217162903.GA15927@puck.nether.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:35:31 -0000 Hi Jon, On 17/12/2012 16:29, Jon Mitchell wrote: > Nick - I assume you are willing to accept a modification to the proposal > that makes it 4200000000 - (end) I've floated the idea with a couple of operations people, and the small sample that were interested are split between 4200000000 and the lower proposed ranges. Personally, I'm strongly in favour of the lower ranges, but at this stage, the bikeshed doesn't need any more paint thrown at it. Regarding Dave's concerns about allocating so many, this is a complete non issue. It's going to be a long while before we get from assigning 50k ASNs to 4199999999. Even if we do, we'll have generated such momentum in terms of allocation that it will be necessary to move to 64 bit ASNs, which we can do using a similar style of transition technology that we used for asn16 -> asn32. I.e. if you've reached 93% of the potential range, that's well beyond the point at which you need to plan to expand the range. So I'd say go ahead with 4200000000-end. Thanks for taking Jeff's and my comments on board - very much appreciated. Nick From kriswamy@cisco.com Wed Dec 19 11:54:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903DA21F86C0 for ; Wed, 19 Dec 2012 11:54:18 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi2nZEp0Mx8c for ; Wed, 19 Dec 2012 11:54:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1955721F86AC for ; Wed, 19 Dec 2012 11:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=620; q=dns/txt; s=iport; t=1355946858; x=1357156458; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=d5ervO+BAfrI5nDtlxdzbi+YHQvxDx51IyaKfvrPmcI=; b=BMEs1dYSeR0KT3CmA3pxe4ikzgSmQs81Ew6D5uJnNDHjgQLLrQ/3e3wf OnQP6GQummXgpdERRJp29IBLJFJol9J8UklvWvX89xvcSVyBdxsqopniv y4m1BVd4EFF4hxGpCcrzokrzIvAk5yvYuH3FLQ9dj4VPJekRdwms0J1oV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAAQa0lCtJXG8/2dsb2JhbABEhXS4CRZzgh4BAQEEAQEBNzQXBgEIEQQBAQsUCS4LFAkJAQQTCIgLDJZaoVQEjE2DYmEDplKCdIIi X-IronPort-AV: E=Sophos;i="4.84,318,1355097600"; d="scan'208";a="154567646" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 19 Dec 2012 19:54:17 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBJJsHnh032351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Dec 2012 19:54:17 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.86]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 13:54:17 -0600 From: "Krishna Muddenahally Ananthamurthy (kriswamy)" To: "idr@ietf.org" Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: Ac3eIqALHhfJxdXBQZ+xWgWR9J7q4A== Date: Wed, 19 Dec 2012 19:54:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 00:00:27 -0000 Support -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = Scudder Sent: Thursday, December 06, 2012 2:39 PM To: idr@ietf. org Subject: [Idr] WG adoption requested for draft-svshah-interdomain-sla-excha= nge-03 Folks, The authors have requested IDR adopt draft-svshah-interdomain-sla-exchange-= 03 as a working group document. Please send any comments to the list by the Winter Solstice (December 21). Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From richih.mailinglist@gmail.com Thu Dec 20 03:49:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CE721F86C1 for ; Thu, 20 Dec 2012 03:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WEKqNdIa8At for ; Thu, 20 Dec 2012 03:49:56 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 642BD21F8623 for ; Thu, 20 Dec 2012 03:49:56 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id l5so2830392lah.11 for ; Thu, 20 Dec 2012 03:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IwCyseXuOiTvcv31IeEQUgLhWPc/tFvdFzEXS/BWaJw=; b=gKoNWk7C/UGUoSrV9+fjArPOkFadJQjZfhs/06ZIh4jMdDeOB23hcNeudMMK1QJ8rw 7S4tvWRmhrjzs9VELSDdXCmUQ0GzsgvQjJcj/sRZ3bX/+qn+OJHSYl3jtgF2VCNFr110 BYzTHtr6qibCTGXRHwpfza4tqq+kgbxM8uP/b1uyWqDI+ZM8nksYBqhVRYuV7Q2GX9sf BiYsVtYLPZLahImkZQcdkWvt3tDf53WZJUM0jUVwFmlryO9dJDlgxy7oW34JVhnpu+0D Y/QdiJLnEoHCq2KdYJHWPWa9iQURQFPMC9r04ODycTVoTPfRka3KMHRIsNSExJru2uUj tj3g== Received: by 10.152.131.168 with SMTP id on8mr8579754lab.38.1356004195093; Thu, 20 Dec 2012 03:49:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.170.132 with HTTP; Thu, 20 Dec 2012 03:49:35 -0800 (PST) In-Reply-To: <50D1DEBF.7040500@foobar.org> References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CE1D95.2000709@foobar.org> <20121217162903.GA15927@puck.nether.net> <50D1DEBF.7040500@foobar.org> From: Richard Hartmann Date: Thu, 20 Dec 2012 12:49:35 +0100 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=f46d0433a0fc5ccc3f04d14754b9 Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:49:57 -0000 --f46d0433a0fc5ccc3f04d14754b9 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 19, 2012 at 4:35 PM, Nick Hilliard wrote: > the bikeshed doesn't need any more paint thrown at it. > Agreed. I.e. if you've reached 93% of the potential range, that's > well beyond the point at which you need to plan to expand the range. > Also agreed. So I'd say go ahead with 4200000000-end. Thanks for taking Jeff's and my > comments on board - very much appreciated. > And yet another agreement. I believe that operational concerns have all been addressed so I'd like to state "support" once again. RIchard --f46d0433a0fc5ccc3f04d14754b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 19, 2012 at 4:35 PM, Nick Hilliard <nick@foob= ar.org> wrote:
=C2=A0
=C2=A0the bikeshed doesn't need any more paint thrown at it.
<= /blockquote>

Agreed.=C2=A0


I.e. if you've reached 93% of the potential range, that's
well beyond the point at which you need to plan to expand the range.

Also agreed.
=C2=A0

So I'd say go ahead with 4200000000-end. =C2=A0Thanks for taking Jeff&#= 39;s and my
comments on board - very much appreciated.

<= div style>And yet another agreement.

<= br>
I believe that operational concerns have all been addre= ssed so I'd like to state "support" once again.


RIchard
--f46d0433a0fc5ccc3f04d14754b9-- From internet-drafts@ietf.org Thu Dec 20 06:55:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0F921F8982; Thu, 20 Dec 2012 06:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orp3sZqFj540; Thu, 20 Dec 2012 06:55:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D49E21F88DE; Thu, 20 Dec 2012 06:55:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121220145537.26966.28483.idtracker@ietfa.amsl.com> Date: Thu, 20 Dec 2012 06:55:37 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-private-reservation-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:55:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Autonomous System (AS) Reservation for Private Use Author(s) : Jon Mitchell Filename : draft-ietf-idr-as-private-reservation-01.txt Pages : 4 Date : 2012-12-20 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and should not be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as-private-reservation-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From farmer@umn.edu Thu Dec 20 07:04:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E53421F894F for ; Thu, 20 Dec 2012 07:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5jHwhVHR+rz for ; Thu, 20 Dec 2012 07:04:10 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id B3ED021F8626 for ; Thu, 20 Dec 2012 07:04:10 -0800 (PST) Received: from mail-ie0-f197.google.com (mail-ie0-f197.google.com [209.85.223.197]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 09:04:00 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f197.google.com [209.85.223.197] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f197.google.com with SMTP id 16so14301107iea.4 for ; Thu, 20 Dec 2012 07:04:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=WNvAfg+MPdJ1vNGX6IuxAq5Zw9ixEcsateE1q+xYqyQ=; b=GonL7As5QSe/TKQ/DxXrDPnFCmeIY34c2G5Ua3YqOGHceLl+rdU4teD9iyRcwD8xDX yzc9P5GhD1Ec2oGep5eQ8FBHQ48WSCk3F9kMPlDGkntsqFSkLvjCtoozRu5b2mHA6YlL 0cArXTtowd1h9Rck2PUz9T13rFNIKOYn+o4nlubO7WQmiWI+2VT4tBJ9G3FWAWiqYIoX ZsPLESThigkPNnkMBb8iq6UE6XGdesywC6OYLofjf9smvyDpTkJd+3xgfoFqPUKIHCx3 qxFVRa1wRr60MJdn+lr1bCkh/aN6uKVxZ0sXEzHrFFfzHZGswzJM9dSxLqIa3d8VPMMV E0rQ== X-Received: by 10.50.194.196 with SMTP id hy4mr10212680igc.52.1356015840199; Thu, 20 Dec 2012 07:04:00 -0800 (PST) X-Received: by 10.50.194.196 with SMTP id hy4mr10212667igc.52.1356015840093; Thu, 20 Dec 2012 07:04:00 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id lu10sm2972780igc.15.2012.12.20.07.03.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 07:03:59 -0800 (PST) Message-ID: <50D328DC.2020906@umn.edu> Date: Thu, 20 Dec 2012 09:03:56 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> In-Reply-To: <20121129191043.GA9189@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlh+2YpkDTmcuC9rhARIrBWeUx0vr0G2aOBb2G5FlwJR4g7rEu2zVdsfmPBnoe21c57XAhIY1ApQNZvssWFi03pUZmtw7nJDgnlsHUdt0Tp2ryzFzHogU85vk0W2Zkb+zCCckSh Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:04:11 -0000 I know the last call is over so ignore this if you wish; However, I've been thinking about the issue of filtering private ASNs through out the discussion, but I hadn't identified what was bugging me until now. Here are a couple quotes for some context; On 11/29/12 13:10 , Jon Mitchell wrote: > Any network can filter private ASNs as well as various other types of > ASNs on ingress that they do not want to not accept/propogate. This > draft will have no impact on whether people tend to do that correctly or > not in my opinion. Folks who have no use for more than a thousand > internal use ASNs today are not likely to use this new range. On 11/30/12 14:15 , Brian Dickson wrote:> > If you see it on the Public Internet, it does not belong and can be > ignored safely, and should not be propagated to one's Internet > peers/customers. But several others have made similar comments as well. This is basically covered in Section 3 "Operational Considerations" in the draft. Here is what it says now; If private use ASNs are used and prefixes are originated from these private use ASNs which are destined to the Internet, private use ASNs must be removed from the AS_PATH before being advertised to the global Internet. Operators are cautioned to ensure any filters or implementation specific features that recognize private use ASNs have been updated to recognize both ranges prior to making use of the newer, numerically higher range of private use ASNs. I like that this says "private use ASNs must be removed from the AS_PATH before being advertised to the global Internet." However, it finally hit me that in the quotes above, and in others as well, we have said "if you see private use ASNs on the global Internet you can filter them." But, this is only implied by the text in section 3, not explicitly stated. So, I suggest that section 3 also explicitly state that operators may filter private use ASNs they receive from the global Internet. So here is some suggested text. Operators may drop or disregard any prefix received from the global Internet that is originated from or that contains a private use ASN in the AS_PATH. This may result in unpredictable connectivity for any prefix originated from or containing a private use ASN in the AS_PATH. Therefore, all operators using private use ASNs to originate prefixes or passing an AS_PATH that contains private use ASNs to the global Internet, must remove all private use ASNs from the AS_PATH before being advertised to the global Internet. Furthermore, operators are cautioned to ensure any filters or implementation specific features that recognize private use ASNs have been updated to recognize both ranges prior to making use of the newer, numerically higher range of private use ASNs. Again the intent of the change is to explicitly state operators can filter any prefixes received from the global Internet that uses private use ASNs. In addition to stating you must not send the to the global Internet in the first place. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jrmitche@puck.nether.net Thu Dec 20 07:27:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7774421F8202 for ; Thu, 20 Dec 2012 07:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm9WdWFJDegh for ; Thu, 20 Dec 2012 07:27:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5866421F8414 for ; Thu, 20 Dec 2012 07:27:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKFRLv8016627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 10:27:21 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKFRLVR016622; Thu, 20 Dec 2012 10:27:21 -0500 Date: Thu, 20 Dec 2012 10:27:21 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121220152721.GA3551@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D328DC.2020906@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 10:27:21 -0500 (EST) Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:27:23 -0000 David - I just posted a new rev of the doc which I hope is final incorporating the changes discussed on the list previously (must have just crossed in the wires with this email). I made slight changes to the section you describe, although I put the focus on filtering on the user of private ASNs (outbound). I think whether or not filtering inbound or not is a good idea is largely operator preference (I'm personally in favor as it pushes the drop closest to the source of the error which I'm generally in favor of) and the draft is not meant to dictate specific behavior (this is not a BCP doc) in this regard however it seems like if you are using private ASN's, it will simplify things a bit from a troubleshooting standpoint to not mis-identify a leaked private ASN as one of your own by inbound filtering at your border, but the impact in either case is the same and minimal (routes that are leaked are the ones impacted only - encouraging those who leak to fix their issues). Also, it should be noted none of these issues are new (related to the new range), although some of them may have to be revisited as Pradosh pointed out if remove private implementations are not updated, and that is the focus of the text change I did make. Jon On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote: > I know the last call is over so ignore this if you wish; However, > I've been thinking about the issue of filtering private ASNs through > out the discussion, but I hadn't identified what was bugging me > until now. > > Here are a couple quotes for some context; > > On 11/29/12 13:10 , Jon Mitchell wrote: > >Any network can filter private ASNs as well as various other types of > >ASNs on ingress that they do not want to not accept/propogate. This > >draft will have no impact on whether people tend to do that correctly or > >not in my opinion. Folks who have no use for more than a thousand > >internal use ASNs today are not likely to use this new range. > > On 11/30/12 14:15 , Brian Dickson wrote:> > > If you see it on the Public Internet, it does not belong and can be > > ignored safely, and should not be propagated to one's Internet > > peers/customers. > > But several others have made similar comments as well. > > This is basically covered in Section 3 "Operational Considerations" > in the draft. Here is what it says now; > > If private use ASNs are used and prefixes are originated from these > private use ASNs which are destined to the Internet, private use ASNs > must be removed from the AS_PATH before being advertised to the > global Internet. Operators are cautioned to ensure any filters or > implementation specific features that recognize private use ASNs have > been updated to recognize both ranges prior to making use of the > newer, numerically higher range of private use ASNs. > > I like that this says "private use ASNs must be removed from the > AS_PATH before being advertised to the global Internet." However, > it finally hit me that in the quotes above, and in others as well, > we have said "if you see private use ASNs on the global Internet you > can filter them." But, this is only implied by the text in section > 3, not explicitly stated. So, I suggest that section 3 also > explicitly state that operators may filter private use ASNs they > receive from the global Internet. > > So here is some suggested text. > > Operators may drop or disregard any prefix received from the global > Internet that is originated from or that contains a private use ASN > in the AS_PATH. This may result in unpredictable connectivity for > any prefix originated from or containing a private use ASN in the > AS_PATH. Therefore, all operators using private use ASNs to > originate prefixes or passing an AS_PATH that contains private use > ASNs to the global Internet, must remove all private use ASNs from > the AS_PATH before being advertised to the global Internet. > Furthermore, operators are cautioned to ensure any filters or > implementation specific features that recognize private use ASNs > have been updated to recognize both ranges prior to making use of > the newer, numerically higher range of private use ASNs. > > Again the intent of the change is to explicitly state operators can > filter any prefixes received from the global Internet that uses > private use ASNs. In addition to stating you must not send the to > the global Internet in the first place. > > Thanks > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ From randy@psg.com Thu Dec 20 07:55:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9964C21F86D2 for ; Thu, 20 Dec 2012 07:55:37 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LuqjWXAyZgR for ; Thu, 20 Dec 2012 07:55:37 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E121F892E for ; Thu, 20 Dec 2012 07:55:37 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TliT7-000Jbc-Vw; Thu, 20 Dec 2012 15:55:34 +0000 Date: Thu, 20 Dec 2012 10:55:32 -0500 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20121220152721.GA3551@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:55:37 -0000 i have a strange question at this late date. why is this draft in idr at all? it is not protocol, it is ops. i would think it would be in grow. and certainly, grow should at least review it. randy From farmer@umn.edu Thu Dec 20 08:15:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0308921F88E1 for ; Thu, 20 Dec 2012 08:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jHcuKlAWaGE for ; Thu, 20 Dec 2012 08:15:32 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE2521F88DD for ; Thu, 20 Dec 2012 08:15:32 -0800 (PST) Received: from mail-ie0-f198.google.com (mail-ie0-f198.google.com [209.85.223.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 10:14:46 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f198.google.com [209.85.223.198] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f198.google.com with SMTP id c10so14702069ieb.1 for ; Thu, 20 Dec 2012 08:14:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=EEfZXEkYZ609xBZFwCQXsI2DRdVeL7RyD/PSPoJNcHo=; b=LBsigJK3k2SUXDCu4UVijcAmrGtVJBLLtAUIWUJt+bfwsKjIM7k0GQw05YyrjRJecj w2oRoa5+jsvk4hbaxkoKeQu1esyO43WTeaswrho+geIza976r2QhrCKvDCYkGzOPvjTv wieVD0j9O8AUnK/sDNShRgkT3tgPcHTxrTW1RlwHVUd+aUVgIkvrYTZP0oFV/aeWT9Bm g1/8YxKgXgBJ9vf2qLkJPOzJ+pUU+oVK54Yf6IEf4J/shI8m5bea0jfQtW+w/r3ZCOF8 oIiLS2mJkDf/hptWmZmdMwRsD6vOlUTW1s6Ptpf9dqyeElu8eoFs0MVOnOuZbeCS2mJK 2vUQ== X-Received: by 10.42.75.6 with SMTP id y6mr9385208icj.30.1356020086096; Thu, 20 Dec 2012 08:14:46 -0800 (PST) X-Received: by 10.42.75.6 with SMTP id y6mr9385199icj.30.1356020085979; Thu, 20 Dec 2012 08:14:45 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id pr7sm13449239igc.16.2012.12.20.08.14.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 08:14:45 -0800 (PST) Message-ID: <50D33972.8090302@umn.edu> Date: Thu, 20 Dec 2012 10:14:42 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> In-Reply-To: <20121220152721.GA3551@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlJ3gfLwmt1chsJCplWVaEYg5AVDlufpC/VikeRBwp3bdSwqy/Xq/X/cWUuRNSF7GU6u7amCOOD2l+6lN1GOnrw6s912LbsdNyQez0gMaHPeuTTBjsnk7iakHapdr+94Ec+727m Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:15:33 -0000 On 12/20/12 09:27 , Jon Mitchell wrote: > > David - > > I just posted a new rev of the doc which I hope is final incorporating > the changes discussed on the list previously (must have just crossed in > the wires with this email). Yep, I saw it right after clicking send. > I made slight changes to the section you > describe, although I put the focus on filtering on the user of private > ASNs (outbound). > > I think whether or not filtering inbound or not is a good idea is > largely operator preference (I'm personally in favor as it pushes the > drop closest to the source of the error which I'm generally in favor of) > and the draft is not meant to dictate specific behavior (this is not a > BCP doc) in this regard however it seems like if you are using private > ASN's, it will simplify things a bit from a troubleshooting standpoint > to not mis-identify a leaked private ASN as one of your own by inbound > filtering at your border, but the impact in either case is the same and > minimal (routes that are leaked are the ones impacted only - encouraging > those who leak to fix their issues). I'm OK with the focus being on outbound filtering and outbound filtering and being required with a "MUST" clause. However, I believe that inbound filtering should be explicitly allowed, but not required, with a "MAY" clause being included as well. However, there is the old mantra of "trust but verify". So I think we need to be explicit that any other operator "MAY" filter inbound. If you get the balance right this can be use to reenforce your focus that operators "MUST" filter outbound. I'll agree my suggested text below did not get the balance right and focuses to much on the inbound filtering. However, both your original and new text don't make it explicit that an operator "MAY" filter inbound if they wish. That is what I would like to see added somehow. > Also, it should be noted none of these issues are new (related to the > new range), although some of them may have to be revisited as Pradosh > pointed out if remove private implementations are not updated, and that > is the focus of the text change I did make. Completely agree, not a new issue. However, we are touching the text, and vendors are going to need to touch code, so now is the time to fix issues, especially if they lead to divergent interpretations. > Jon > > > On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote: ... >> So here is some suggested text. >> >> Operators may drop or disregard any prefix received from the global >> Internet that is originated from or that contains a private use ASN >> in the AS_PATH. This may result in unpredictable connectivity for >> any prefix originated from or containing a private use ASN in the >> AS_PATH. Therefore, all operators using private use ASNs to >> originate prefixes or passing an AS_PATH that contains private use >> ASNs to the global Internet, must remove all private use ASNs from >> the AS_PATH before being advertised to the global Internet. >> Furthermore, operators are cautioned to ensure any filters or >> implementation specific features that recognize private use ASNs >> have been updated to recognize both ranges prior to making use of >> the newer, numerically higher range of private use ASNs. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nick@foobar.org Thu Dec 20 08:32:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCF21F89F2 for ; Thu, 20 Dec 2012 08:32:39 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhTq59eeoJLl for ; Thu, 20 Dec 2012 08:32:38 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1DF21F89C1 for ; Thu, 20 Dec 2012 08:32:31 -0800 (PST) X-Envelope-To: Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBKGUn3Z049438 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 20 Dec 2012 16:30:50 GMT (envelope-from nick@foobar.org) Message-ID: <50D33D9D.3070400@foobar.org> Date: Thu, 20 Dec 2012 16:32:29 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr@ietf.org References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> In-Reply-To: <50D33972.8090302@umn.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:32:39 -0000 On 20/12/2012 16:14, David Farmer wrote: > I'm OK with the focus being on outbound filtering and outbound filtering > and being required with a "MUST" clause. I don't think the IETF is too hot on the idea of "MUST" appearing in non normative documents? Nick From farmer@umn.edu Thu Dec 20 08:48:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378E821F88C5 for ; Thu, 20 Dec 2012 08:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eacj1szh5F0i for ; Thu, 20 Dec 2012 08:48:09 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 81FDA21F855A for ; Thu, 20 Dec 2012 08:48:09 -0800 (PST) Received: from mail-ob0-f200.google.com (mail-ob0-f200.google.com [209.85.214.200]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 10:47:58 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f200.google.com [209.85.214.200] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f200.google.com with SMTP id wd20so14921376obb.7 for ; Thu, 20 Dec 2012 08:47:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=S1y6vpbU/YyrTMr8lXUVqcoSuoFv+J7mHD7GgcExjWs=; b=UgdpIT9ygzR7LPiLXQYoGzw4Xt91b60GUjgoCQqDnxYWVrWUzQE0NkdOoJDDjD/5KO FDP8fTe0yHBeDjZWtvfNDq1b6aqBikjPJ9Ih28HH2HneGJC+8/Kf57yisnEFDyBy+eco asqIQVeCqmQg2UI8A3jjJf+yNglCn6uQhcZQOS9g+qhwzMpJ73UnpZ8zxVcNMQCZt9JP chikGhqTEvCOzeqP8BPPkkgcBWxdafSHa9h9InEYUhc+e7EeTgOw7/9ldECiif+743x9 b3iXXMgqxUsVFTHK7Ao4PXJtOcaoBAp29pE2X3Z8e/R9HAMv98sKYFNf/d3z9jInbeaQ yS8g== X-Received: by 10.42.249.80 with SMTP id mj16mr9479055icb.53.1356022078713; Thu, 20 Dec 2012 08:47:58 -0800 (PST) X-Received: by 10.42.249.80 with SMTP id mj16mr9478981icb.53.1356022077523; Thu, 20 Dec 2012 08:47:57 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id gk1sm7221990igc.5.2012.12.20.08.47.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 08:47:56 -0800 (PST) Message-ID: <50D3413A.8030904@umn.edu> Date: Thu, 20 Dec 2012 10:47:54 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> In-Reply-To: <20121219145706.GA3846@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnxg3dA2Cv1sRszsdUYXKGfyMqEsebEjFdYqG0UKjEtd+CCalLZNHmGXcbPRZrcuwr7avzO7YMOtTB6q1F6f3jRLYdAiTxg7NNnrzMddehp/F6OlnAHk6lyRk0EujGwArhIQKYj Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:48:10 -0000 On 12/19/12 08:57 , Jon Mitchell wrote: > Maybe some others would like to weigh in on one of the above options now > that it's a focused discussion (otherwise I plan to make the small edits > discussed in previous threads and move the start of range to > 42xxxxxxxx so we can close this out...) OK, I'll relent, 4.2B it is. But, we need to be clear about why we are selecting this; which is to make regexp matching of private use ASNs easier. The idea is to allow the simple regexp of 42???????? to match private use ASNs. However, this makes a few assumptions. 1. While not part of the Private Use ASN range, the intended regexp also matches the reserved ASN 4294967295, and therefore 4294967295 can never be a valid ASN in an AS_PATH. 2. The intended regexp would select ASNs beyond the 32bit ASN range, if they were valid, that is 4294967296 through 4299999999. Therefore, if the ASN range were ever expanded to make these valid ASNs, the private use ASN range would also need to be expanded to be included these ASNs as well. If we want to use 4.2B as the starting point to simplify regexp matching of the private use range then these assumptions need to be explicitly stated in the draft. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jsw@inconcepts.biz Thu Dec 20 08:52:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD9621F84F2 for ; Thu, 20 Dec 2012 08:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD4eub4x9pZo for ; Thu, 20 Dec 2012 08:52:25 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9221F85D9 for ; Thu, 20 Dec 2012 08:52:25 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so4927298iea.24 for ; Thu, 20 Dec 2012 08:52:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Grmy1lUmr9QUrrRikNTrIXbC2Tbo6LRSLW/9RiACpFk=; b=nSBuBhax7xanzxLTjo9ZwXS/XAgKd1sdjGj+j5K3AlUIE5B6Pz2NRm7Ml6TE2tX1Hb lNi5MxZLYBLdzeGZTyjeOfP4L+gy7EOFGG0z+y8xf3/9DEj8azTBbiLEHD5DGO2o1o5I WUwhEml3AYs73BUQOS7EvOP9ye27f6EK3qgDYT/clDg6XGjIJYNmKNblawkyDtTvGXeW DKzKOZpwCCNmMBb7V7c9J77tJGesWZe2wpRmLP/dVYzZcejoTf/Z7IG7JuwpWqHC+2t7 1kADwtE8zL7sOqO6ci3OLq4kXAzoq+36SkHIOHROwchNbadMl4LrogPXH/5P+8CsLMdG kjKg== MIME-Version: 1.0 Received: by 10.50.170.102 with SMTP id al6mr10751910igc.70.1356022344234; Thu, 20 Dec 2012 08:52:24 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 20 Dec 2012 08:52:23 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <50D3413A.8030904@umn.edu> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> Date: Thu, 20 Dec 2012 11:52:23 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnHNTYx4HnpjGigJ8uYf3IlF5WYXlVtcSnzlQh7LnkoV78oF/SRFXxpauvn3ppi9gQzORuT Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:52:32 -0000 On Thu, Dec 20, 2012 at 11:47 AM, David Farmer wrote: > 1. While not part of the Private Use ASN range, the intended regexp also > matches the reserved ASN 4294967295, and therefore 4294967295 can never be a > valid ASN in an AS_PATH. Fortunately, it can never be a valid ASN in an AS_PATH. So it won't matter if a regexp matches it as private. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From farmer@umn.edu Thu Dec 20 08:59:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8881621F85E8 for ; Thu, 20 Dec 2012 08:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKCjOA+F4O9y for ; Thu, 20 Dec 2012 08:59:25 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id F26B021F859A for ; Thu, 20 Dec 2012 08:59:24 -0800 (PST) Received: from mail-ia0-f198.google.com (mail-ia0-f198.google.com [209.85.210.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 10:59:15 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f198.google.com [209.85.210.198] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f198.google.com with SMTP id m10so9832437iam.5 for ; Thu, 20 Dec 2012 08:59:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=769/w5DYeEMsv//Wptm5gzevXFZ3+wbg/SmpDZuB9Q4=; b=ZqbtqWpCYiqvhuF279oqf3ie8c4SGM3veHfkGF7rp3h50GvF/FLpmbzSN8QG13rAUO wqOoeiRJeivN78E0nlPvbP8ddtN7XfNOt6Z877Gd8OtK1fFJDmsWieT5NRbqdo2t/EiP MsbCmVIHfo6H39TH/b3ezE1c9LALOMcSTWbTmeHXNx0X1MQN3n6vIYtRYiXI+gudBFXg J5UCIj8Tzjz33PHLhCdcVo2GGrkMKp+KsWqFg6EuoQvESubGV7Iqrb1uopKJCZAiV1DD LyJcxAkDDYiZD8FhcutmalrEACteWAAmRgeR+E+zRWlpceO6pnsfe2zyTouMflrP6MQx hmhg== X-Received: by 10.50.106.199 with SMTP id gw7mr10662604igb.26.1356022754765; Thu, 20 Dec 2012 08:59:14 -0800 (PST) X-Received: by 10.50.106.199 with SMTP id gw7mr10662601igb.26.1356022754705; Thu, 20 Dec 2012 08:59:14 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id uz1sm7220034igb.16.2012.12.20.08.59.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 08:59:13 -0800 (PST) Message-ID: <50D343DF.80609@umn.edu> Date: Thu, 20 Dec 2012 10:59:11 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jeff Wheeler References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl8vqqwmZ9E7Gh9lPLFr7G7S4Xw2ngumKwq1IxIKkY9t+o5zCdet46V+MbKikSBzIzx8wS8Vo/69ZOwuRz4d+XA4jCMzIClpYUpu73B9CA4EtYSQ3YNcYEBykYxdu/UAteR80QP Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:59:25 -0000 On 12/20/12 10:52 , Jeff Wheeler wrote: > On Thu, Dec 20, 2012 at 11:47 AM, David Farmer wrote: >> 1. While not part of the Private Use ASN range, the intended regexp also >> matches the reserved ASN 4294967295, and therefore 4294967295 can never be a >> valid ASN in an AS_PATH. > > Fortunately, it can never be a valid ASN in an AS_PATH. So it won't > matter if a regexp matches it as private. I agree, but I'm not sure where this is explicitly stated, its not in RFC 6793. So, unless it is explicitly stated somewhere else it needs to be stated here. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From randy@psg.com Thu Dec 20 09:03:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66B621F85DA for ; Thu, 20 Dec 2012 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40C0EucLvO0Q for ; Thu, 20 Dec 2012 09:03:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 826CE21F850C for ; Thu, 20 Dec 2012 09:03:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TljXG-000KEc-IC; Thu, 20 Dec 2012 17:03:54 +0000 Date: Thu, 20 Dec 2012 12:03:54 -0500 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <50D33D9D.3070400@foobar.org> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:03:57 -0000 > I don't think the IETF is too hot on the idea of "MUST" appearing in non > normative documents? normative is how a document is referred to by another document, and one can never know that. and, despite common rumor, one can have 2119 language in an info or bcp. rand From jared@puck.nether.net Thu Dec 20 09:04:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A4021F8953 for ; Thu, 20 Dec 2012 09:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UxjHv5rrS6p for ; Thu, 20 Dec 2012 09:04:40 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id B49FC21F894F for ; Thu, 20 Dec 2012 09:04:38 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKH4cUh032220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 12:04:38 -0500 Received: (from jared@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKH4cNJ032219; Thu, 20 Dec 2012 12:04:38 -0500 Date: Thu, 20 Dec 2012 12:04:38 -0500 From: Jared Mauch To: David Farmer Message-ID: <20121220170437.GB28958@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D3413A.8030904@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 12:04:38 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:04:42 -0000 On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote: > On 12/19/12 08:57 , Jon Mitchell wrote: > > >Maybe some others would like to weigh in on one of the above options now > >that it's a focused discussion (otherwise I plan to make the small edits > >discussed in previous threads and move the start of range to > >42xxxxxxxx so we can close this out...) > > OK, I'll relent, 4.2B it is. But, we need to be clear about why we > are selecting this; which is to make regexp matching of private use > ASNs easier. > > The idea is to allow the simple regexp of 42???????? to match > private use ASNs. However, this makes a few assumptions. > > 1. While not part of the Private Use ASN range, the intended regexp > also matches the reserved ASN 4294967295, and therefore 4294967295 > can never be a valid ASN in an AS_PATH. I think this poses the need to have vendors replace regex with something where you can specify a list or range of the integers you wish to match. I have wanted to tie prefix to the integer string encoded in AS_PATH for some time and there is no effective way to do this. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From farmer@umn.edu Thu Dec 20 09:11:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1321F89A4 for ; Thu, 20 Dec 2012 09:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9mUBBHIeFbG for ; Thu, 20 Dec 2012 09:11:20 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 84A6C21F84F9 for ; Thu, 20 Dec 2012 09:11:20 -0800 (PST) Received: from mail-ia0-f200.google.com (mail-ia0-f200.google.com [209.85.210.200]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 11:11:15 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f200.google.com [209.85.210.200] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f200.google.com with SMTP id f6so9871050iag.11 for ; Thu, 20 Dec 2012 09:11:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=2tQuK1tqojx3jeAyjz9e2ggmldWsyhwwYatBU6iba7k=; b=oME+W+3tnme2E5nIfRIw4KLLFP2xmTnLenVan6JSBvBExRad6qDzWOTpnB/3L4Kktx ZDCDdp/VNNrNAlri4EeANemEM4Z0nIEkptIQBq/UNcHiQM4soG3LEl1N+P2h28hCSrLp gY85xIiuyQMBOcjA6MUQvXepXKO+4uJ5F0fjSE7rq6nnl114rSEe/cZIzR7V/ieKT5Oy 931/4IRxZK+sEsyV+9qkjgWZatpbsCLT1+e+QBI/CNFPh+EfRMIxGac/gbG8SqMoPs/T mUORVWWApT1f7hT0mRQwU4N/mRjwZ7ctuaVSdirJ91MLmFYkSRFay8ZMT65Zk9LpHNL1 EK2g== X-Received: by 10.50.169.106 with SMTP id ad10mr6239082igc.88.1356023474888; Thu, 20 Dec 2012 09:11:14 -0800 (PST) X-Received: by 10.50.169.106 with SMTP id ad10mr6239077igc.88.1356023474804; Thu, 20 Dec 2012 09:11:14 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id yf6sm7284251igb.0.2012.12.20.09.11.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 09:11:13 -0800 (PST) Message-ID: <50D346AF.4010107@umn.edu> Date: Thu, 20 Dec 2012 11:11:11 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nick Hilliard References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> In-Reply-To: <50D33D9D.3070400@foobar.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQll3yj+HeeFTYKUwOwji7NitjJP4OqDj7Pag8XqDOJXIbgv1Hqnb44j9sNOReqlSgpXOZH7kISU2GD23hBEvu/0xONXKZ48BM/DPZ6eeIbRaz7SddT72Eda3nOv66n4URc7QsJd Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:11:21 -0000 On 12/20/12 10:32 , Nick Hilliard wrote: > On 20/12/2012 16:14, David Farmer wrote: >> I'm OK with the focus being on outbound filtering and outbound filtering >> and being required with a "MUST" clause. > > I don't think the IETF is too hot on the idea of "MUST" appearing in non > normative documents? To be clear, the draft uses the word "must", which I take as the normal English meaning of the word. I was using "MUST" and "MAY" in my email to add emphasis, not to make normative statements. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer@umn.edu Thu Dec 20 09:25:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9DA21F8A69 for ; Thu, 20 Dec 2012 09:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VWYHBFtUmpw for ; Thu, 20 Dec 2012 09:25:37 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 72A1321F8A68 for ; Thu, 20 Dec 2012 09:25:34 -0800 (PST) Received: from mail-ob0-f199.google.com (mail-ob0-f199.google.com [209.85.214.199]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 11:25:20 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f199.google.com [209.85.214.199] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f199.google.com with SMTP id 16so15087944obc.6 for ; Thu, 20 Dec 2012 09:25:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=FXVj1Nk/Rxaxl+b315Dl5Q5HaB0Urd4ISk32DXdV+dY=; b=DTk+6TN+9cfUD5QbM3sOIQ025uR1voFw5CkYWJpopQqMnykeU3CtEg5DKrzTn6x2js y3nBNVwihlELbodcrCT8ZqX05h+G9F/BbTDNv2+RTyqzS0YS/njKGzt62qKmhQyx8qjN lmRtfJZ21p1m9RCpyCdbcbFIOWQlqtkqaEOGpNw/IaZDk5P6iIfbhg9trgXctfJCR0vj gXYBS1urdg0lvW9FANMbY66tqyOSbMxIM6honBeIsM72jqUn36Pc2xyVaaKgPIhGAwfL lBOxkRg+5a9utYydtrhQBkYu8NJzlQ+FlyMvPgVyW9fpVj8Iqri45prSwFywDpikhmnj dTNQ== X-Received: by 10.42.68.203 with SMTP id y11mr9734893ici.26.1356024319823; Thu, 20 Dec 2012 09:25:19 -0800 (PST) X-Received: by 10.42.68.203 with SMTP id y11mr9734886ici.26.1356024319756; Thu, 20 Dec 2012 09:25:19 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id ww6sm13612278igb.2.2012.12.20.09.25.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 09:25:18 -0800 (PST) Message-ID: <50D349FD.9060700@umn.edu> Date: Thu, 20 Dec 2012 11:25:17 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jared Mauch References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> <20121220170437.GB28958@puck.nether.net> In-Reply-To: <20121220170437.GB28958@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnFsd6j8vCgiO0opY1zFsrJmhMIrWaID7kCH1WTzgUmQbRI7tWkqcMfVMYF0P73983dzyLN5AIjWIwxpApqibsNXOH08mLjA6Srv975jIEqVDoBMp0vJ5DZdItavGh2Bk94VY76 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:25:55 -0000 On 12/20/12 11:04 , Jared Mauch wrote: > On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote: >> On 12/19/12 08:57 , Jon Mitchell wrote: >> >>> Maybe some others would like to weigh in on one of the above options now >>> that it's a focused discussion (otherwise I plan to make the small edits >>> discussed in previous threads and move the start of range to >>> 42xxxxxxxx so we can close this out...) >> >> OK, I'll relent, 4.2B it is. But, we need to be clear about why we >> are selecting this; which is to make regexp matching of private use >> ASNs easier. >> >> The idea is to allow the simple regexp of 42???????? to match >> private use ASNs. However, this makes a few assumptions. >> >> 1. While not part of the Private Use ASN range, the intended regexp >> also matches the reserved ASN 4294967295, and therefore 4294967295 >> can never be a valid ASN in an AS_PATH. > > I think this poses the need to have vendors replace regex > with something where you can specify a list or range of the integers > you wish to match. > > I have wanted to tie prefix to the integer string encoded in AS_PATH > for some time and there is no effective way to do this. If we had something like that, we wouldn't care about 4.2B, which was my point along time ago about this being "CLI/Config semantics issue and not a standards or allocation issue". But, we're deciding to make the special allocation to suite this issue, I'm fine with that. We just have to be explicit about the issues this choice creates. There is no perfect answer here. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jrmitche@puck.nether.net Thu Dec 20 09:38:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E55121F8A51 for ; Thu, 20 Dec 2012 09:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uQfYubfaQgT for ; Thu, 20 Dec 2012 09:38:13 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9165821F8A42 for ; Thu, 20 Dec 2012 09:38:13 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKHcCgL004997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 12:38:12 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKHcCxC004994; Thu, 20 Dec 2012 12:38:12 -0500 Date: Thu, 20 Dec 2012 12:38:12 -0500 From: Jon Mitchell To: Randy Bush Message-ID: <20121220173812.GA1910@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 12:38:13 -0500 (EST) Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:38:14 -0000 This was discussed upfront with WG chairs from both initially, and I agree it is odd that you would bring it up at this late date. I personally believe that this an update of RFC 1930 which was IDR product and a bit out of GROW charter since the focus of this draft is not about global Internet. IDR charter includes support for four-octet AS numbers in BGP, and I believe it fits well into that. IDR description also states it supports use of BGP-4 by IPv4 and IPv6 networks, which this draft continues to make room for growth in the use of the protocol outside of Internet use cases. Also this draft is a reservation document, not an operations document, but I agree also not a protocol extension of any kind. I'm not against a GROW review (maybe one of the chairs, AD or IESG will recommend it anyway), however it also appears many of the active participants of GROW have already participated in the discussion. Jon On Thu, Dec 20, 2012 at 10:55:32AM -0500, Randy Bush wrote: > i have a strange question at this late date. why is this draft in idr > at all? it is not protocol, it is ops. i would think it would be in > grow. and certainly, grow should at least review it. > > randy From jrmitche@puck.nether.net Thu Dec 20 09:48:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD3621F88DE for ; Thu, 20 Dec 2012 09:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk-C2CAq3gES for ; Thu, 20 Dec 2012 09:48:38 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3821F88DD for ; Thu, 20 Dec 2012 09:48:37 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKHma2v006421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 12:48:36 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKHmaqJ006420; Thu, 20 Dec 2012 12:48:36 -0500 Date: Thu, 20 Dec 2012 12:48:36 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121220174836.GB1910@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D33972.8090302@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 12:48:36 -0500 (EST) Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:48:39 -0000 David - Just to close this out, I don't plan to make these additional changes to the draft. I don't plan on saying operators MUST filter private use ASN's outbound specfically with an AS_PATH filter list or dictate to operators anything they must do except not to send private use ASN's to the Internet, which is the same guidance given in RFC 1930 and already in the draft. Operators are inventive and can use whatever tool to do this they please (community/prefix based could be used if they know which communities or prefixes come from private ASNs for instance). On the inbound filtering, operators may filter /25 or longer, their own address space, private or public ASN's or anything else they please in my opinion, and none of this needs to be codified in this draft, however is certainly welcomed in BCP documents. We've already established in many threads that the worse case is a prefix from a mis-configured (leaked to Internet Private Use ASN) is dropped. Jon On Thu, Dec 20, 2012 at 10:14:42AM -0600, David Farmer wrote: > On 12/20/12 09:27 , Jon Mitchell wrote: > > > >David - > > > >I just posted a new rev of the doc which I hope is final incorporating > >the changes discussed on the list previously (must have just crossed in > >the wires with this email). > > Yep, I saw it right after clicking send. > > >I made slight changes to the section you > >describe, although I put the focus on filtering on the user of private > >ASNs (outbound). > > > >I think whether or not filtering inbound or not is a good idea is > >largely operator preference (I'm personally in favor as it pushes the > >drop closest to the source of the error which I'm generally in favor of) > >and the draft is not meant to dictate specific behavior (this is not a > >BCP doc) in this regard however it seems like if you are using private > >ASN's, it will simplify things a bit from a troubleshooting standpoint > >to not mis-identify a leaked private ASN as one of your own by inbound > >filtering at your border, but the impact in either case is the same and > >minimal (routes that are leaked are the ones impacted only - encouraging > >those who leak to fix their issues). > > I'm OK with the focus being on outbound filtering and outbound > filtering and being required with a "MUST" clause. However, I > believe that inbound filtering should be explicitly allowed, but not > required, with a "MAY" clause being included as well. > > However, there is the old mantra of "trust but verify". So I think > we need to be explicit that any other operator "MAY" filter inbound. > If you get the balance right this can be use to reenforce your focus > that operators "MUST" filter outbound. > > I'll agree my suggested text below did not get the balance right and > focuses to much on the inbound filtering. However, both your > original and new text don't make it explicit that an operator "MAY" > filter inbound if they wish. That is what I would like to see added > somehow. > > >Also, it should be noted none of these issues are new (related to the > >new range), although some of them may have to be revisited as Pradosh > >pointed out if remove private implementations are not updated, and that > >is the focus of the text change I did make. > > Completely agree, not a new issue. However, we are touching the > text, and vendors are going to need to touch code, so now is the > time to fix issues, especially if they lead to divergent > interpretations. > > >Jon > > > > > >On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote: > ... > >>So here is some suggested text. > >> > >> Operators may drop or disregard any prefix received from the global > >> Internet that is originated from or that contains a private use ASN > >> in the AS_PATH. This may result in unpredictable connectivity for > >> any prefix originated from or containing a private use ASN in the > >> AS_PATH. Therefore, all operators using private use ASNs to > >> originate prefixes or passing an AS_PATH that contains private use > >> ASNs to the global Internet, must remove all private use ASNs from > >> the AS_PATH before being advertised to the global Internet. > >> Furthermore, operators are cautioned to ensure any filters or > >> implementation specific features that recognize private use ASNs > >> have been updated to recognize both ranges prior to making use of > >> the newer, numerically higher range of private use ASNs. > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ From jsw@inconcepts.biz Thu Dec 20 09:50:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE821F8A71 for ; Thu, 20 Dec 2012 09:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaCpGtyHtwN2 for ; Thu, 20 Dec 2012 09:50:47 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFEC21F8931 for ; Thu, 20 Dec 2012 09:50:47 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id qd14so4902318ieb.20 for ; Thu, 20 Dec 2012 09:50:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KGx68BP2XCrUUOrxhTNjkxabuNzGCeSflUarzU1A5Vw=; b=ZZHNPn9KevxE60yGUNiYG2nQLI2fX0zIW5HqaYGRum5/etOkx0jweXzjRF4+sPQYd5 nBhpjKGoeozN5PRAo9Wqoc1Y99uWwaM1OsW/p30jnMBg4ROxJLANNC2fXVC/1DEls/GT PGRGDVrbYB9aA7zAdb7NW/7ONbPFoyRH3ZHT9FbuxO6U4nCnIkc+MtKl2jGZDS1BAllN M7dYyHKdEUGgFUUrFYvmy+CEzAysfGb1+YME7oSf9sgXvuDSkRRw7PbUAVx2gYdRZBdX 512uCYhemh/1AEhNVsuoqWRWadyJqtiKW9WSZ6syQnqpTQwDAeB24DiLrVDjFk8aw1B1 NN1Q== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr10905370igb.45.1356025846396; Thu, 20 Dec 2012 09:50:46 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 20 Dec 2012 09:50:46 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20121220170437.GB28958@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> <20121220170437.GB28958@puck.nether.net> Date: Thu, 20 Dec 2012 12:50:46 -0500 Message-ID: From: Jeff Wheeler To: Jared Mauch Content-Type: multipart/alternative; boundary=e89a8f3ba01be178b304d14c5e4d X-Gm-Message-State: ALoCoQlHpIYb04q+tsSyPZl1LFF+qTTj9pqIExtJY7T32K7agQjb6oiVti7RCRTDrpjsSV4gLjAc Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:50:48 -0000 --e89a8f3ba01be178b304d14c5e4d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 20, 2012 at 12:04 PM, Jared Mauch wrote: > I think this poses the need to have vendors replace regex > with something where you can specify a list or range of the integers > you wish to match. This already exists in major implementations. Most of us are so used to how regexps work in other environments, we don't realize there is more than one way. For example, on a Juniper box, do this: root@Juniper> show route aspath-regex ".* [3000-3999] .*" terse ... matches plenty of routes like you'd hope ... Similar thing works on Cisco. Unfortunately the regexp engines used for offline processing (Perl, grep, whatever) are usually not customized for dealing with AS_PATH expressions. $ perl -wne 'print if / [6000-6999] /;' routes-from-tinet.txt |head -3 inet.0: 423540 destinations, 1806800 routes (423540 active, 0 holddown, 0 hidden) 5.144.136.0/21 A.B.C.D 0 3257 22652 22652 8304 I 18.0.0.0/8 A.B.C.D 90 3257 174 3 I Obviously, the above won't "do what you mean" in Perl. But with the proposed extended Private ASN range 4.2B+, you will be able to match that using any common regexp engine. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --e89a8f3ba01be178b304d14c5e4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 20, 2012 at 12:04 PM, Jared Mauch <jared@puck.nether.net> wrote:
> =A0 =A0 =A0 = =A0 I think this poses the need to have vendors replace regex
> with = something where you can specify a list or range of the integers
> you wish to match.

This already exists in major implementations= . =A0Most of us are so used to how regexps work in other environments, we d= on't realize there is more than one way. =A0For example, on a Juniper b= ox, do this:
= root@Juniper> show route aspath-regex ".* [3000-3999] .*" ters= e
=A0... matches plenty of routes like you'd hope ...

Similar thing works on Cisco. =A0Unfortunately the regexp engine= s used for offline processing (Perl, grep, whatever) are usually not custom= ized for dealing with AS_PATH expressions.
$ perl = -wne 'print if / [6000-6999] /;' routes-from-tinet.txt |head -3
inet.0: 423540 destinations, 1806800 routes (423540 active, 0 hol= ddown, 0 hidden)
=A0 5.1= 44.136.0/21 =A0 =A0 =A0 =A0 =A0A.B.C.D =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A03257 22652 22652 8304 I
=A0 18.0.0.0/8 =A0 =A0 =A0 =A0 =A0 = =A0 =A0A.B.C.D =A0 =A0 =A0 =A0 90 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3257 174 = 3 I

Obviously, the above won't &q= uot;do what you mean" in Perl. =A0But with the proposed extended Priva= te ASN range 4.2B+, you will be able to match that using any common regexp = engine.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator =A0/ =A0Innovative Ne= twork Concepts
--e89a8f3ba01be178b304d14c5e4d-- From jrmitche@puck.nether.net Thu Dec 20 10:05:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131D121F895C for ; Thu, 20 Dec 2012 10:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+epu+2P0AhZ for ; Thu, 20 Dec 2012 10:05:42 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 688E321F8920 for ; Thu, 20 Dec 2012 10:05:42 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKI5fEK008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 13:05:41 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKI5fl1008848; Thu, 20 Dec 2012 13:05:41 -0500 Date: Thu, 20 Dec 2012 13:05:41 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20121220180541.GC1910@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D3413A.8030904@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 13:05:42 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:05:43 -0000 On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote: > On 12/19/12 08:57 , Jon Mitchell wrote: > > >Maybe some others would like to weigh in on one of the above options now > >that it's a focused discussion (otherwise I plan to make the small edits > >discussed in previous threads and move the start of range to > >42xxxxxxxx so we can close this out...) > > > The idea is to allow the simple regexp of 42???????? to match > private use ASNs. However, this makes a few assumptions. Human identifiable range was the primary concern raised with regex implementation another given justification for changing the recommendation to IANA for the start of range. > > 1. While not part of the Private Use ASN range, the intended regexp > also matches the reserved ASN 4294967295, and therefore 4294967295 > can never be a valid ASN in an AS_PATH. The draft does not state how to construct a regex, this is out of scope for the draft. Some operators may not even choose or need to filter private use ASN's inbound or outbound based on their requirements/design. > > 2. The intended regexp would select ASNs beyond the 32bit ASN range, > if they were valid, that is 4294967296 through 4299999999. > Therefore, if the ASN range were ever expanded to make these valid > ASNs, the private use ASN range would also need to be expanded to be > included these ASNs as well. Certainly something operators should concern themselves with when discussions start on moving beyond 4 byte ASNs (maybe a note about it could be attached to that draft). On a side note, do you plan on this before or after IPv6 exhaustion? > If we want to use 4.2B as the starting point to simplify regexp > matching of the private use range then these assumptions need to be > explicitly stated in the draft. I disagree, I prefer not delving how to construct regex's properly or stating how they work in various implementations in a simple IANA reservation draft. From jared@puck.nether.net Thu Dec 20 10:08:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC721F8A88 for ; Thu, 20 Dec 2012 10:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvtMLJ-UePkR for ; Thu, 20 Dec 2012 10:08:18 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2343E21F8920 for ; Thu, 20 Dec 2012 10:07:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKI7JBM009070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 13:07:19 -0500 Received: (from jared@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKI7Jsq009069; Thu, 20 Dec 2012 13:07:19 -0500 Date: Thu, 20 Dec 2012 13:07:19 -0500 From: Jared Mauch To: Jeff Wheeler Message-ID: <20121220180719.GE28958@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> <20121220170437.GB28958@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 13:07:20 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:08:19 -0000 On Thu, Dec 20, 2012 at 12:50:46PM -0500, Jeff Wheeler wrote: > On Thu, Dec 20, 2012 at 12:04 PM, Jared Mauch wrote: > > I think this poses the need to have vendors replace regex > > with something where you can specify a list or range of the integers > > you wish to match. > > This already exists in major implementations. Most of us are so used to > how regexps work in other environments, we don't realize there is more than > one way. For example, on a Juniper box, do this: > root@Juniper> show route aspath-regex ".* [3000-3999] .*" terse > ... matches plenty of routes like you'd hope ... > > Similar thing works on Cisco. Unfortunately the regexp engines used for > offline processing (Perl, grep, whatever) are usually not customized for > dealing with AS_PATH expressions. > $ perl -wne 'print if / [6000-6999] /;' routes-from-tinet.txt |head -3 > inet.0: 423540 destinations, 1806800 routes (423540 active, 0 holddown, 0 > hidden) > 5.144.136.0/21 A.B.C.D 0 3257 22652 > 22652 8304 I > 18.0.0.0/8 A.B.C.D 90 3257 174 3 I > > Obviously, the above won't "do what you mean" in Perl. But with the > proposed extended Private ASN range 4.2B+, you will be able to match that > using any common regexp engine. Not likely: RP/0/RSP0/CPU0:r07.dllstx09.us.bb#sh bgp regexp [65000-1024000] BGP router identifier x.x.x.x, local AS number 65000 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0xe0000000 RD version: 70417360 BGP main routing table version 70417360 BGP scan interval 60 secs Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.0.0.0/24 x.x.x.x 0 0 3356 15169 i * i x.x.x.x 4294967294 100 0 1299 15169 i * i x.x.x.x 4294967294 100 0 1299 15169 i * i x.x.x.x 4294967294 100 0 3356 15169 i * i x.x.x.x 4294967294 100 0 3356 15169 i * i x.x.x.x 4294967294 100 0 1299 15169 i ... This is on modern code built and released in the past 6 months. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jrmitche@puck.nether.net Thu Dec 20 10:15:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51321F86B0 for ; Thu, 20 Dec 2012 10:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg38AhPlziWq for ; Thu, 20 Dec 2012 10:15:51 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8D70F21F8626 for ; Thu, 20 Dec 2012 10:15:51 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKIFlH1010037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 13:15:47 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKIFl4S010031; Thu, 20 Dec 2012 13:15:47 -0500 Date: Thu, 20 Dec 2012 13:15:47 -0500 From: Jon Mitchell To: Jared Mauch Message-ID: <20121220181547.GA9172@puck.nether.net> References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> <20121220170437.GB28958@puck.nether.net> <20121220180719.GE28958@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121220180719.GE28958@puck.nether.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 13:15:48 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:15:52 -0000 On Thu, Dec 20, 2012 at 01:07:19PM -0500, Jared Mauch wrote: > On Thu, Dec 20, 2012 at 12:50:46PM -0500, Jeff Wheeler wrote: > > On Thu, Dec 20, 2012 at 12:04 PM, Jared Mauch wrote: > > > I think this poses the need to have vendors replace regex > > > with something where you can specify a list or range of the integers > > > you wish to match. > > > > This already exists in major implementations. Most of us are so used to > > how regexps work in other environments, we don't realize there is more than > > one way. For example, on a Juniper box, do this: > > root@Juniper> show route aspath-regex ".* [3000-3999] .*" terse > > ... matches plenty of routes like you'd hope ... > > > > Similar thing works on Cisco. Unfortunately the regexp engines used for > > Not likely: > This is my experience as well, I believe that was XR output which even has the CLI say ios-regex for their as-path filters even, implying this is true for most if not all Cisco implementations. The range operator appears to be a single character/digit function only. I agree better tools in general are warranted from lot's of vendors but don't think this document is the right place for specifying those. Jon From farmer@umn.edu Thu Dec 20 11:43:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7660221F888F for ; Thu, 20 Dec 2012 11:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfFgqJL2uP18 for ; Thu, 20 Dec 2012 11:43:58 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9321F85A3 for ; Thu, 20 Dec 2012 11:43:57 -0800 (PST) Received: from mail-ob0-f200.google.com (mail-ob0-f200.google.com [209.85.214.200]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 13:43:45 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f200.google.com [209.85.214.200] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f200.google.com with SMTP id wd20so15683354obb.11 for ; Thu, 20 Dec 2012 11:43:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=yA+mUfzbqK7I2CgbsphPvwp1lca4nKb2SnXbq5Lmyo4=; b=LTU9+trkliJZm0aKF6/Xi/uV8iHQdlHcRSyVCpq1laeukE5XMojAlMmPBOUPaZkJJU EYxPv8+fsMB+kv5AaoRYUIa5mwh2sxwDLbz6tiX+pOtBKoW3VAZVcLcE2AKp1googPY7 iz9Sq8jq3IYxKydeiOTKQJ8bjEOej+0DzRCd9empKiEgYDhWF8Xoa3jLu7iZV0lezwvY Vb9j3MtnEJKUV14JoJ6DdjD9bru9cVzLzEIjfM/+YNfKmXHELzJp+DDPzLho8EJh/f9i WceLEK3yDpg1Ke2RL74H6EvdO1xxUgJqfW2zfTDuQ37+UwloeD5ZUdazrXz9UxngMbpo ME7w== X-Received: by 10.50.91.230 with SMTP id ch6mr6679199igb.92.1356032624978; Thu, 20 Dec 2012 11:43:44 -0800 (PST) X-Received: by 10.50.91.230 with SMTP id ch6mr6679194igb.92.1356032624899; Thu, 20 Dec 2012 11:43:44 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu (x-134-84-88-75.nts.umn.edu. [134.84.88.75]) by mx.google.com with ESMTPS id 10sm13873621ign.5.2012.12.20.11.43.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 11:43:44 -0800 (PST) Message-ID: <50D36A6E.5040908@umn.edu> Date: Thu, 20 Dec 2012 13:43:42 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <20121220174836.GB1910@puck.nether.net> In-Reply-To: <20121220174836.GB1910@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkhUGWgMWr7UtJPT/+jd43WZzvskNISLGpUjbI7CwQDJT1YvPmnLzxq31Az6mPY8y6RyGbgA1ERDiuDVukQy5gcYDDUMlJpewn81xk0lvhVTSLOXrBLRfsstc7y76bKQGxiTzNJ Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:43:59 -0000 On 12/20/12 11:48 , Jon Mitchell wrote: > > David - > > Just to close this out, I don't plan to make these additional changes to > the draft. I don't plan on saying operators MUST filter private use > ASN's outbound specfically with an AS_PATH filter list or dictate to > operators anything they must do except not to send private use ASN's to > the Internet, which is the same guidance given in RFC 1930 and already > in the draft. Operators are inventive and can use whatever tool to do > this they please (community/prefix based could be used if they know > which communities or prefixes come from private ASNs for instance). The -01 draft says "Private Use ASNs must be removed from the AS_PATH before being advertised to the global Internet." This is perfect, how this is accomplished is completely up to the operator. But, it says you MUST remove Private ASNs outbound to the Internet. > On the inbound filtering, operators may filter /25 or longer, their own > address space, private or public ASN's or anything else they please in > my opinion, and none of this needs to be codified in this draft, however > is certainly welcomed in BCP documents. We've already established in > many threads that the worse case is a prefix from a mis-configured > (leaked to Internet Private Use ASN) is dropped. All I was looking for was something making explicit and reinforcing to those using Private Use ASNs, everyone else MAY disregard prefixes using Private Use ASNs inbound from the Internet. Which is why they MUST remove Private ASNs outbound to the Internet. Its in their own interest that they remove the Private Use ASNs not everyone else. But if you believe that belongs in a separate BCP then OK, but them my question would be why doesn't this whole section belong in a separate BCP. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From randy@psg.com Thu Dec 20 13:17:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD2021F8A9F for ; Thu, 20 Dec 2012 13:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH2A4y4TH2gg for ; Thu, 20 Dec 2012 13:17:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29221F8A9D for ; Thu, 20 Dec 2012 13:17:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TlnUp-000KzF-MM; Thu, 20 Dec 2012 21:17:39 +0000 Date: Thu, 20 Dec 2012 16:17:40 -0500 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20121220174836.GB1910@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <20121220174836.GB1910@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:17:42 -0000 > Just to close this out, I don't plan to make these additional changes to > the draft. thanks. see you in ietf last call. randy From neil@domino.org Thu Dec 20 13:38:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B18C21F8995 for ; Thu, 20 Dec 2012 13:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvS02gbRwVCX for ; Thu, 20 Dec 2012 13:38:07 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF521F8994 for ; Thu, 20 Dec 2012 13:38:06 -0800 (PST) Received: from mail198-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Dec 2012 21:38:05 +0000 Received: from mail198-ch1 (localhost [127.0.0.1]) by mail198-ch1-R.bigfish.com (Postfix) with ESMTP id C77883800E6; Thu, 20 Dec 2012 21:38:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.5; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzzz1de0h1202h1e76h1d1ah1d2ahzzz2fh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1155h) Received-SPF: pass (mail198-ch1: domain of domino.org designates 157.56.252.5 as permitted sender) client-ip=157.56.252.5; envelope-from=neil@domino.org; helo=DB3PRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail198-ch1 (localhost.localdomain [127.0.0.1]) by mail198-ch1 (MessageSwitch) id 1356039483493366_5758; Thu, 20 Dec 2012 21:38:03 +0000 (UTC) Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail198-ch1.bigfish.com (Postfix) with ESMTP id 766633400FD; Thu, 20 Dec 2012 21:38:03 +0000 (UTC) Received: from DB3PRD0310HT002.eurprd03.prod.outlook.com (157.56.252.5) by CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Dec 2012 21:38:03 +0000 Received: from DB3PRD0310MB391.eurprd03.prod.outlook.com ([169.254.6.204]) by DB3PRD0310HT002.eurprd03.prod.outlook.com ([10.255.44.37]) with mapi id 14.16.0245.002; Thu, 20 Dec 2012 21:38:02 +0000 From: "Neil J. McRae" To: Nick Hilliard Thread-Topic: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Thread-Index: AQHN19SJFGWtHywUjEujt618CpD7NpgT/xGAgAFmc4CAAFkiAIABEaWAgAGvMACAABT+AIADPwKAgAFkHICAAxWwgIAB96Ni Date: Thu, 20 Dec 2012 21:38:02 +0000 Message-ID: <3CD6D775-69F8-4508-85FF-F0B94169BE87@domino.org> References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CE1D95.2000709@foobar.org> <20121217162903.GA15927@puck.nether.net>, <50D1DEBF.7040500@foobar.org> In-Reply-To: <50D1DEBF.7040500@foobar.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.176.97.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: domino.org Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:38:07 -0000 I echo Randy's view that this needs grow to look at it. > can do using a similar style of transition technology that we used for > asn16 -> asn32. I.e. if you've reached 93% of the potential range, that'= s > well beyond the point at which you need to plan to expand the range. transition technologies they work really well ! Because we never compromise= them do we!? Neil.= From nick@foobar.org Thu Dec 20 13:52:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A50121F8994 for ; Thu, 20 Dec 2012 13:52:35 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR1fZENk7GVh for ; Thu, 20 Dec 2012 13:52:34 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8235B21F8717 for ; Thu, 20 Dec 2012 13:52:32 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBKLogHP052338 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 21:50:47 GMT (envelope-from nick@foobar.org) Message-ID: <50D38896.5080900@foobar.org> Date: Thu, 20 Dec 2012 21:52:22 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Neil J. McRae" References: <20121211185917.GA21813@puck.nether.net> <50C78C29.3070406@foobar.org> <50C8B8D9.4090903@umn.edu> <50C9039E.1050104@foobar.org> <20121213144147.GB4524@puck.nether.net> <50CB52E0.7080602@foobar.org> <20121214174012.GA18502@puck.nether.net> <50CE1D95.2000709@foobar.org> <20121217162903.GA15927@puck.nether.net>, <50D1DEBF.7040500@foobar.org> <3CD6D775-69F8-4508-85FF-F0B94169BE87@domino.org> In-Reply-To: <3CD6D775-69F8-4508-85FF-F0B94169BE87@domino.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IDR Working Group Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:52:35 -0000 On 20/12/2012 21:38, Neil J. McRae wrote: > I echo Randy's view that this needs grow to look at it. No major objection to that. Does that happen now, or once it's finished WGLC? > transition technologies they work really well ! Because we never compromise them do we!? all things considered, the asn16->asn32 migration is going remarkably well. I'd say the idea is mature enough so that if we need to do an asn32 -> asn64 migration in 2.5 million years time (based on current asn usage figures), it would probably proceed well enough that we don't need to worry to much about it at this stage. That's if we make it past the end of the world tomorrow. Nick From shares@ndzh.com Thu Dec 20 13:56:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F51F21F890E for ; Thu, 20 Dec 2012 13:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.774 X-Spam-Level: * X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1tGe2BkOmeT for ; Thu, 20 Dec 2012 13:56:54 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B021F8566 for ; Thu, 20 Dec 2012 13:56:51 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Randy Bush'" , "'Nick Hilliard'" , "Jon Mitchell" References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> In-Reply-To: Date: Thu, 20 Dec 2012 16:56:27 -0500 Message-ID: <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIYFQnBxEap+Ysjo1QAfAojpVhvjQJIkh77AXh1CiMCFViB0gF9v/6AAmbGo3oB7YiCWgKv2FVeARrxtCkBsTl3FAI7u/5OAja6J+QDCNUD15bIyWug Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:56:59 -0000 Randy and Nick: Please note that Randy is correct about the use of MUST language, and it is an appropriate editorial question for WG LC or the period between WG LC and IETF LC ending. For my clarification, why is the following text using "must" without the MUST language? If Private Use ASNs are used and prefixes are originated from these ASNs which are destined to the Internet, Private Use ASNs must be removed from the AS_PATH before being advertised to the global Internet. In my reading of this text, it is specifying the 2119 language. In this case the text would be: If Private Use ASNs are used and prefixes are originated from these ASNs which are destined to the Internet, Private Use ASNs MUST be removed from the AS_PATH before being advertised to the global Internet. I look forward to the authors comment on this point. Since this document is modifying a BCP (RFC1930), it is likely to be a BCP. Please note I consider this an issue that the authors need to address this RFC2119 issue. Please note this type of editorial review is normal during the post WG-LC when the chairs perform an editing review prior writing up a IESG Shepherding report. I am not widening our restricted request for advice on the WG LC agreement. We are still focus this week on the range. May you have Shalom in your Holidays, Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Thursday, December 20, 2012 12:04 PM To: Nick Hilliard Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > I don't think the IETF is too hot on the idea of "MUST" appearing in > non normative documents? normative is how a document is referred to by another document, and one can never know that. and, despite common rumor, one can have 2119 language in an info or bcp. rand _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Thu Dec 20 14:38:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D655721F8A9B for ; Thu, 20 Dec 2012 14:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95WZk38aCobb for ; Thu, 20 Dec 2012 14:38:32 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 007F721F8931 for ; Thu, 20 Dec 2012 14:38:31 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKMcKP6023351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 17:38:20 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKMcK8E023350; Thu, 20 Dec 2012 17:38:20 -0500 Date: Thu, 20 Dec 2012 17:38:20 -0500 From: Jon Mitchell To: Susan Hares Message-ID: <20121220223820.GA19458@puck.nether.net> References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 17:38:20 -0500 (EST) Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:38:33 -0000 I'm comfortable making the change to a capital MUST for this sentence and adding the appropriate reference to RFC 2119 as necessary. I'm just not comfortable telling operators how to perform that action as there are a number of options to do so, which was my point to David (and he seemed to be ok with). I will make the changes as necessary to the abstract where this statement exists as well. As for BCP versus info, I leave that up to the chairs, but this does not obsolete or otherwise change text in RFC 1930 outside of the IANA considerations section (RFC 1930 is primarily about justification for an ASN). There is no "practice" being advocated by the draft to be best or current, outside of the practice of not sending Private Use ASNs to the Internet. Jon On Thu, Dec 20, 2012 at 04:56:27PM -0500, Susan Hares wrote: > Randy and Nick: > > Please note that Randy is correct about the use of MUST language, and it is > an appropriate editorial question for WG LC or the period between WG LC and > IETF LC ending. > > For my clarification, why is the following text using "must" without the > MUST language? > > If Private Use ASNs are used and prefixes are originated from these > ASNs which are destined to the Internet, Private Use ASNs must be > removed from the AS_PATH before being advertised to the global > Internet. > > In my reading of this text, it is specifying the 2119 language. In this > case the text would be: > > If Private Use ASNs are used and prefixes are originated from these > ASNs which are destined to the Internet, Private Use ASNs MUST be > removed from the AS_PATH before being advertised to the global > Internet. > > I look forward to the authors comment on this point. Since this document is > modifying a BCP (RFC1930), it is likely to be a BCP. Please note I consider > this an issue that the authors need to address this RFC2119 issue. Please > note this type of editorial review is normal during the post WG-LC when the > chairs perform an editing review prior writing up a IESG Shepherding report. > > > > I am not widening our restricted request for advice on the WG LC agreement. > We are still focus this week on the range. > > May you have Shalom in your Holidays, > > Sue > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy > Bush > Sent: Thursday, December 20, 2012 12:04 PM > To: Nick Hilliard > Cc: idr@ietf.org > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > I don't think the IETF is too hot on the idea of "MUST" appearing in > > non normative documents? > > normative is how a document is referred to by another document, and one can > never know that. > > and, despite common rumor, one can have 2119 language in an info or bcp. > > rand > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Thu Dec 20 14:43:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413E221F8920 for ; Thu, 20 Dec 2012 14:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wL3Q5RuJHi2 for ; Thu, 20 Dec 2012 14:43:52 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8E39821F8566 for ; Thu, 20 Dec 2012 14:43:52 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKMhggA024478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 17:43:42 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKMhgvv024477; Thu, 20 Dec 2012 17:43:42 -0500 Date: Thu, 20 Dec 2012 17:43:42 -0500 From: Jon Mitchell To: Randy Bush Message-ID: <20121220224342.GB19458@puck.nether.net> References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <20121220174836.GB1910@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 17:43:42 -0500 (EST) Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:43:53 -0000 Randy - please see my commment to Susan, could you see if that addresses your concern, or are you suggesting that the draft states operators SHOULD do inbound AS_PATH filtering on private ASNs (I'm not sure this is even common practice today, although some operators do so). Since you deleted the context of the change you agreed with David on (he had suggested a couple), it's a bit hard to infer your meaning. Jon On Thu, Dec 20, 2012 at 04:17:40PM -0500, Randy Bush wrote: > > Just to close this out, I don't plan to make these additional changes to > > the draft. > > thanks. see you in ietf last call. > > randy From shares@ndzh.com Thu Dec 20 14:56:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D20A21F8A9A for ; Thu, 20 Dec 2012 14:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.592 X-Spam-Level: * X-Spam-Status: No, score=1.592 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZXeku-iAqqE for ; Thu, 20 Dec 2012 14:56:01 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 61D2521F8A8F for ; Thu, 20 Dec 2012 14:56:01 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jon Mitchell'" References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> In-Reply-To: <20121220223820.GA19458@puck.nether.net> Date: Thu, 20 Dec 2012 17:55:39 -0500 Message-ID: <025801cddf05$22871100$67953300$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9mBi0H3A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, Pete Resnick Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:56:02 -0000 Jon: My understanding of your text is that it operationally MUST be done. I like you, will leave the "how to" to implementations and operators. If it's a filters or pure fairy-magic, it is fine by me. I do not think this MUST modification implies the method. My understanding from my wonderful Routing ADs is something that modifies a BCP (RFC1930) is generally a BCP. However, we'll let Stewart Bryant (our Routing AD) weigh in on that fact. Sue -----Original Message----- From: Jon Mitchell [mailto:jrmitche@puck.nether.net] Sent: Thursday, December 20, 2012 5:38 PM To: Susan Hares Cc: 'Randy Bush'; 'Nick Hilliard'; idr@ietf.org; stbryant@cisco.com Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 I'm comfortable making the change to a capital MUST for this sentence and adding the appropriate reference to RFC 2119 as necessary. I'm just not comfortable telling operators how to perform that action as there are a number of options to do so, which was my point to David (and he seemed to be ok with). I will make the changes as necessary to the abstract where this statement exists as well. As for BCP versus info, I leave that up to the chairs, but this does not obsolete or otherwise change text in RFC 1930 outside of the IANA considerations section (RFC 1930 is primarily about justification for an ASN). There is no "practice" being advocated by the draft to be best or current, outside of the practice of not sending Private Use ASNs to the Internet. Jon On Thu, Dec 20, 2012 at 04:56:27PM -0500, Susan Hares wrote: > Randy and Nick: > > Please note that Randy is correct about the use of MUST language, and > it is an appropriate editorial question for WG LC or the period > between WG LC and IETF LC ending. > > For my clarification, why is the following text using "must" without > the MUST language? > > If Private Use ASNs are used and prefixes are originated from these > ASNs which are destined to the Internet, Private Use ASNs must be > removed from the AS_PATH before being advertised to the global > Internet. > > In my reading of this text, it is specifying the 2119 language. In > this case the text would be: > > If Private Use ASNs are used and prefixes are originated from these > ASNs which are destined to the Internet, Private Use ASNs MUST be > removed from the AS_PATH before being advertised to the global > Internet. > > I look forward to the authors comment on this point. Since this > document is modifying a BCP (RFC1930), it is likely to be a BCP. Please note I consider > this an issue that the authors need to address this RFC2119 issue. Please > note this type of editorial review is normal during the post WG-LC > when the chairs perform an editing review prior writing up a IESG Shepherding report. > > > > I am not widening our restricted request for advice on the WG LC agreement. > We are still focus this week on the range. > > May you have Shalom in your Holidays, > > Sue > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Thursday, December 20, 2012 12:04 PM > To: Nick Hilliard > Cc: idr@ietf.org > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > I don't think the IETF is too hot on the idea of "MUST" appearing in > > non normative documents? > > normative is how a document is referred to by another document, and > one can never know that. > > and, despite common rumor, one can have 2119 language in an info or bcp. > > rand > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Thu Dec 20 15:02:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76521F8A9D for ; Thu, 20 Dec 2012 15:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqtg8LusU2MX for ; Thu, 20 Dec 2012 15:02:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 689EA21F8A8F for ; Thu, 20 Dec 2012 15:02:17 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBKN26fv028550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 18:02:07 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKN26l6028547; Thu, 20 Dec 2012 18:02:06 -0500 Date: Thu, 20 Dec 2012 18:02:06 -0500 From: Jon Mitchell To: Susan Hares Message-ID: <20121220230206.GA26708@puck.nether.net> References: <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <025801cddf05$22871100$67953300$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025801cddf05$22871100$67953300$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 18:02:07 -0500 (EST) Cc: idr@ietf.org, Pete Resnick Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:02:22 -0000 I agree with the understanding (in fact one might say this is implied already by this being for Private Use). A question for you or Randy.. does this make RFC 2119 a normative or informative reference given this is not a standards track document? If Normative, should I include the prescribed "Specification of Requirements" section text as well? On Thu, Dec 20, 2012 at 05:55:39PM -0500, Susan Hares wrote: > Jon: > > My understanding of your text is that it operationally MUST be done. I > like you, will leave the "how to" to implementations and operators. If > it's a filters or pure fairy-magic, it is fine by me. I do not think this > MUST modification implies the method. > > My understanding from my wonderful Routing ADs is something that modifies a > BCP (RFC1930) is generally a BCP. However, we'll let Stewart Bryant (our > Routing AD) weigh in on that fact. > > Sue > > > -----Original Message----- > From: Jon Mitchell [mailto:jrmitche@puck.nether.net] > Sent: Thursday, December 20, 2012 5:38 PM > To: Susan Hares > Cc: 'Randy Bush'; 'Nick Hilliard'; idr@ietf.org; stbryant@cisco.com > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > I'm comfortable making the change to a capital MUST for this sentence and > adding the appropriate reference to RFC 2119 as necessary. I'm just not > comfortable telling operators how to perform that action as there are a > number of options to do so, which was my point to David (and he seemed to be > ok with). I will make the changes as necessary to the abstract where this > statement exists as well. > > As for BCP versus info, I leave that up to the chairs, but this does not > obsolete or otherwise change text in RFC 1930 outside of the IANA > considerations section (RFC 1930 is primarily about justification for an > ASN). There is no "practice" being advocated by the draft to be best or > current, outside of the practice of not sending Private Use ASNs to the > Internet. > > Jon > > On Thu, Dec 20, 2012 at 04:56:27PM -0500, Susan Hares wrote: > > Randy and Nick: > > > > Please note that Randy is correct about the use of MUST language, and > > it is an appropriate editorial question for WG LC or the period > > between WG LC and IETF LC ending. > > > > For my clarification, why is the following text using "must" without > > the MUST language? > > > > If Private Use ASNs are used and prefixes are originated from these > > ASNs which are destined to the Internet, Private Use ASNs must be > > removed from the AS_PATH before being advertised to the global > > Internet. > > > > In my reading of this text, it is specifying the 2119 language. In > > this case the text would be: > > > > If Private Use ASNs are used and prefixes are originated from these > > ASNs which are destined to the Internet, Private Use ASNs MUST be > > removed from the AS_PATH before being advertised to the global > > Internet. > > > > I look forward to the authors comment on this point. Since this > > document is modifying a BCP (RFC1930), it is likely to be a BCP. Please > note I consider > > this an issue that the authors need to address this RFC2119 issue. > Please > > note this type of editorial review is normal during the post WG-LC > > when the chairs perform an editing review prior writing up a IESG > Shepherding report. > > > > > > > > I am not widening our restricted request for advice on the WG LC > agreement. > > We are still focus this week on the range. > > > > May you have Shalom in your Holidays, > > > > Sue > > > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > > Randy Bush > > Sent: Thursday, December 20, 2012 12:04 PM > > To: Nick Hilliard > > Cc: idr@ietf.org > > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > > > I don't think the IETF is too hot on the idea of "MUST" appearing in > > > non normative documents? > > > > normative is how a document is referred to by another document, and > > one can never know that. > > > > and, despite common rumor, one can have 2119 language in an info or bcp. > > > > rand > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From nick@foobar.org Thu Dec 20 15:03:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B608B21F8AAC for ; Thu, 20 Dec 2012 15:03: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeZKqiI3xalT for ; Thu, 20 Dec 2012 15:03:01 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7517321F8AA6 for ; Thu, 20 Dec 2012 15:03:00 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBKN1BpR052976 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 23:01:16 GMT (envelope-from nick@foobar.org) Message-ID: <50D3991B.2040809@foobar.org> Date: Thu, 20 Dec 2012 23:02:51 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> In-Reply-To: <20121220223820.GA19458@puck.nether.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:03:02 -0000 On 20/12/2012 22:38, Jon Mitchell wrote: > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm just > not comfortable telling operators how to perform that action as there > are a number of options to do so, which was my point to David (and he > seemed to be ok with). I will make the changes as necessary to the > abstract where this statement exists as well. If it's of interest, rfc 6666 ran into much the same issue recently with the issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD rather than MUST because there probably were situations where there might be valid operational reasons for leaking the prefix to a peer. I would think the same arguments hold for a private ASN range. http://tools.ietf.org/html/rfc6666#section-5 Nick From shares@ndzh.com Thu Dec 20 15:20:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4921F8A89 for ; Thu, 20 Dec 2012 15:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-ZdlUzojLqW for ; Thu, 20 Dec 2012 15:20:51 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 592EF21F8A87 for ; Thu, 20 Dec 2012 15:20:51 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jon Mitchell'" References: <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <025801cddf05$22871100$67953300$@ndzh.com> <20121220230206.GA26708@puck.nether.net> In-Reply-To: <20121220230206.GA26708@puck.nether.net> Date: Thu, 20 Dec 2012 18:20:11 -0500 Message-ID: <027501cddf08$8fecddd0$afc69970$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtiIJaRiMZrLA/U6LEix2ZqyylugKv2FVeARrxtCkBsTl3FAI7u/5OAja6J+QDCNUD1wGYjEL1AlZ1Rv0CmIJ73AMX4xQxly5JTdA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, 'Pete Resnick' Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:20:52 -0000 Jon: Please refer to my comment on BCP as I believe it must be a BCP since it modifies a BCP. In a BCP, I believe the MUST uses RFC 2119. I believe, the WG chairs can change it to a BCP given it modifies a BCP - as an editorial change. I've asked for Stewart Bryant to give us a read on the BCP issue. And as always, the WG will speak if up someone objects. Sue -----Original Message----- From: Jon Mitchell [mailto:jrmitche@puck.nether.net] Sent: Thursday, December 20, 2012 6:02 PM To: Susan Hares Cc: 'Randy Bush'; 'Nick Hilliard'; idr@ietf.org; stbryant@cisco.com; Pete Resnick Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 I agree with the understanding (in fact one might say this is implied already by this being for Private Use). A question for you or Randy.. does this make RFC 2119 a normative or informative reference given this is not a standards track document? If Normative, should I include the prescribed "Specification of Requirements" section text as well? On Thu, Dec 20, 2012 at 05:55:39PM -0500, Susan Hares wrote: > Jon: > > My understanding of your text is that it operationally MUST be done. I > like you, will leave the "how to" to implementations and operators. If > it's a filters or pure fairy-magic, it is fine by me. I do not think > this MUST modification implies the method. > > My understanding from my wonderful Routing ADs is something that > modifies a BCP (RFC1930) is generally a BCP. However, we'll let > Stewart Bryant (our Routing AD) weigh in on that fact. > > Sue > > > -----Original Message----- > From: Jon Mitchell [mailto:jrmitche@puck.nether.net] > Sent: Thursday, December 20, 2012 5:38 PM > To: Susan Hares > Cc: 'Randy Bush'; 'Nick Hilliard'; idr@ietf.org; stbryant@cisco.com > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm > just not comfortable telling operators how to perform that action as > there are a number of options to do so, which was my point to David > (and he seemed to be ok with). I will make the changes as necessary > to the abstract where this statement exists as well. > > As for BCP versus info, I leave that up to the chairs, but this does > not obsolete or otherwise change text in RFC 1930 outside of the IANA > considerations section (RFC 1930 is primarily about justification for > an ASN). There is no "practice" being advocated by the draft to be > best or current, outside of the practice of not sending Private Use > ASNs to the Internet. > > Jon > > On Thu, Dec 20, 2012 at 04:56:27PM -0500, Susan Hares wrote: > > Randy and Nick: > > > > Please note that Randy is correct about the use of MUST language, > > and it is an appropriate editorial question for WG LC or the period > > between WG LC and IETF LC ending. > > > > For my clarification, why is the following text using "must" without > > the MUST language? > > > > If Private Use ASNs are used and prefixes are originated from these > > ASNs which are destined to the Internet, Private Use ASNs must be > > removed from the AS_PATH before being advertised to the global > > Internet. > > > > In my reading of this text, it is specifying the 2119 language. In > > this case the text would be: > > > > If Private Use ASNs are used and prefixes are originated from these > > ASNs which are destined to the Internet, Private Use ASNs MUST be > > removed from the AS_PATH before being advertised to the global > > Internet. > > > > I look forward to the authors comment on this point. Since this > > document is modifying a BCP (RFC1930), it is likely to be a BCP. > > Please > note I consider > > this an issue that the authors need to address this RFC2119 issue. > Please > > note this type of editorial review is normal during the post WG-LC > > when the chairs perform an editing review prior writing up a IESG > Shepherding report. > > > > > > > > I am not widening our restricted request for advice on the WG LC > agreement. > > We are still focus this week on the range. > > > > May you have Shalom in your Holidays, > > > > Sue > > > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf > > Of Randy Bush > > Sent: Thursday, December 20, 2012 12:04 PM > > To: Nick Hilliard > > Cc: idr@ietf.org > > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > > > I don't think the IETF is too hot on the idea of "MUST" appearing > > > in non normative documents? > > > > normative is how a document is referred to by another document, and > > one can never know that. > > > > and, despite common rumor, one can have 2119 language in an info or bcp. > > > > rand > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Thu Dec 20 15:24:28 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1824121F896B for ; Thu, 20 Dec 2012 15:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.351 X-Spam-Level: * X-Spam-Status: No, score=1.351 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erHyJvLVwg88 for ; Thu, 20 Dec 2012 15:24:27 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0C21F8920 for ; Thu, 20 Dec 2012 15:24:27 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nick Hilliard'" , "'Jon Mitchell'" References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> In-Reply-To: <50D3991B.2040809@foobar.org> Date: Thu, 20 Dec 2012 18:24:08 -0500 Message-ID: <027701cddf09$1d074d90$5715e8b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9Ai04lyGYB1L9MA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:24:28 -0000 Nick: I'd be interested in you suggesting the situations would be valid to leak the AS private path AS to a peer, before we downgrade to a "SHOULD". Sue -----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org] Sent: Thursday, December 20, 2012 6:03 PM To: Jon Mitchell Cc: Susan Hares; 'Randy Bush'; idr@ietf.org; stbryant@cisco.com Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 On 20/12/2012 22:38, Jon Mitchell wrote: > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm > just not comfortable telling operators how to perform that action as > there are a number of options to do so, which was my point to David > (and he seemed to be ok with). I will make the changes as necessary > to the abstract where this statement exists as well. If it's of interest, rfc 6666 ran into much the same issue recently with the issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD rather than MUST because there probably were situations where there might be valid operational reasons for leaking the prefix to a peer. I would think the same arguments hold for a private ASN range. http://tools.ietf.org/html/rfc6666#section-5 Nick From edc@google.com Thu Dec 20 15:34:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180C521F8AA6 for ; Thu, 20 Dec 2012 15:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJY4TjBzdiAQ for ; Thu, 20 Dec 2012 15:34:44 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4C03721F8AA5 for ; Thu, 20 Dec 2012 15:34:44 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id j15so3050860qaq.20 for ; Thu, 20 Dec 2012 15:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2iceCE/+6cMrfIK9cuFUcCqXPpzCbH22W+dKb0tDxLM=; b=N+J7i2a8/O9iZFhf14AkV9yOY38h5VKnEfQbt1NVv9Jlt0CRLI5EPwuOOja6CVJt90 XFvabJckYa41TL9vLm+Ut+bsfVstPtzMnSR/vo5xI6CqTLbN/MhX7afKKEDC5jaTGV90 utNAIat1shaXGc2I2nfQSeIvBYFp0RcqlS8K8aGGBUMHh9acxv+zJjRfbZKqAyvXMH9t phofncWiwFKqsVrt6pgd6mDHaGCbhdv3MhihVLseYcnpL8IzepI3FxjG2rwOnWhygX09 kdajWVa78DNBIz3b/+zsikySl6eKAG9iyWiwsi8lyl7amuPaclwtgA2/Mk/Oya4BJF3Q U/QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2iceCE/+6cMrfIK9cuFUcCqXPpzCbH22W+dKb0tDxLM=; b=UYkmadnh9GLTajDOSGHFa++olVEqeakf0ncqopgHWf/+qWEDUdiemVJO2RBzk6RBET VW9nh/wWCgAOeQpxRzxcboKz4GBgxOlnxR/D/WHQAgb53CQflH90dFB+300wW/QaNkVj WI0g7v7SvYn75CS/Jh8PIGPOac23RYHecyy/HF3qPSWFq0rcT3+mbrchvjCKZrtMKjcA iHtVQXfqGUtmlgguQxoimEp4swTxZ7GK80CH0qjMwnIhrkGQI8zP0ndLgO0YbUGMlZHJ 3LbjLHUhkFBuSyyqF1HIVsDvwpFg/xsrspYfHHfxWZD3GC9pU2ER47Tm+TC4/CAl0rXj M/pA== Received: by 10.224.101.68 with SMTP id b4mr1503210qao.29.1356046477901; Thu, 20 Dec 2012 15:34:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.141 with HTTP; Thu, 20 Dec 2012 15:33:57 -0800 (PST) In-Reply-To: <50D3991B.2040809@foobar.org> References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> From: Edward Crabbe Date: Thu, 20 Dec 2012 15:33:57 -0800 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=20cf3066817b9d417604d1512cef X-Gm-Message-State: ALoCoQlVpp+9ZejFzi6y/kZR62Lunn3XHPaH9doa0u1N7nE0QIgXHwkUeSK4y8gEFB2RvwQqxphcs5bo4FcxZLLwjACTtqIsuEi6PYFo5CdgEz/iYrWi1eaY1yjWB0+QKHYetVJjwCtd3OUScS4shPELxR+Xm0JAx7TrEe5fh9HqLPJZEi1Xrngfhp/6phcLNGcvGd9Xjjlf Cc: idr wg , Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:34:45 -0000 --20cf3066817b9d417604d1512cef Content-Type: text/plain; charset=ISO-8859-1 +1 Acquisitions, ASN merges etc may all involve use of private ASN space between consenting parties. I think this is a SHOULD. On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard wrote: > On 20/12/2012 22:38, Jon Mitchell wrote: > > I'm comfortable making the change to a capital MUST for this sentence > > and adding the appropriate reference to RFC 2119 as necessary. I'm just > > not comfortable telling operators how to perform that action as there > > are a number of options to do so, which was my point to David (and he > > seemed to be ok with). I will make the changes as necessary to the > > abstract where this statement exists as well. > > If it's of interest, rfc 6666 ran into much the same issue recently with > the issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD > rather than MUST because there probably were situations where there might > be valid operational reasons for leaking the prefix to a peer. I would > think the same arguments hold for a private ASN range. > > http://tools.ietf.org/html/rfc6666#section-5 > > Nick > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --20cf3066817b9d417604d1512cef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Acquisitions, AS= N merges etc may all involve use of private ASN space between consenting pa= rties. =A0I think this is a SHOULD. =A0


On Thu,= Dec 20, 2012 at 3:02 PM, Nick Hilliard <nick@foobar.org> wrot= e:
On 20/12/2012 22:38, Jon M= itchell wrote:
> I'm comfortable making the change to a capital MUST for this sente= nce
> and adding the appropriate reference to RFC 2119 as necessary. =A0I= 9;m just
> not comfortable telling operators how to perform that action as there<= br> > are a number of options to do so, which was my point to David (and he<= br> > seemed to be ok with). =A0I will make the changes as necessary to the<= br> > abstract where this statement exists as well.

If it's of interest, rfc 6666 ran into much the same issue recent= ly with
the issue of leaking the rtbh prefix to ebgp peers. =A0We decided on SHOULD=
rather than MUST because there probably were situations where there might be valid operational reasons for leaking the prefix to a peer. I would
think the same arguments hold for a private ASN range.

= http://tools.ietf.org/html/rfc6666#section-5

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--20cf3066817b9d417604d1512cef-- From shares@ndzh.com Thu Dec 20 16:01:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8894F21F8A70 for ; Thu, 20 Dec 2012 16:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.267 X-Spam-Level: * X-Spam-Status: No, score=1.267 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kyTp3yNDBSU for ; Thu, 20 Dec 2012 16:01:50 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9933321F8A6B for ; Thu, 20 Dec 2012 16:01:49 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Edward Crabbe'" , "'Nick Hilliard'" References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> In-Reply-To: Date: Thu, 20 Dec 2012 19:01:29 -0500 Message-ID: <028a01cddf0e$55168d90$ff43a8b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01CDDEE4.6C4392D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9Ai04lyEBLBVY65f9+zxQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:01:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_028B_01CDDEE4.6C4392D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Edward: +1 - that Certainly Acquisitions and ASN mergers will cause multiple private ASNs. The draft's text says : " Private Use ASNs must be removed from the AS_Path before being advertised to the global Internet." The question is not whether it goes out of a single Private ASN, but whether it cross the global Internet. For example, if several private DCs band together to have a private exchange beyond the reaches of the global Internet, I have no reason to specify what happens with private ASN behind in those private party exchanges. How do certain Acquisition and ASN mergers cause private ASN to cross the global Internet? And why are these private AS not being hidden by a public AS or AS Confederation. Sue From: Edward Crabbe [mailto:edc@google.com] Sent: Thursday, December 20, 2012 6:34 PM To: Nick Hilliard Cc: Jon Mitchell; idr wg; Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 +1 Acquisitions, ASN merges etc may all involve use of private ASN space between consenting parties. I think this is a SHOULD. On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard wrote: On 20/12/2012 22:38, Jon Mitchell wrote: > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm just > not comfortable telling operators how to perform that action as there > are a number of options to do so, which was my point to David (and he > seemed to be ok with). I will make the changes as necessary to the > abstract where this statement exists as well. If it's of interest, rfc 6666 ran into much the same issue recently with the issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD rather than MUST because there probably were situations where there might be valid operational reasons for leaking the prefix to a peer. I would think the same arguments hold for a private ASN range. http://tools.ietf.org/html/rfc6666#section-5 Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_028B_01CDDEE4.6C4392D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Edward:

 

+1 – that Certainly Acquisitions and ASN mergers will cause = multiple private ASNs.

 

The draft’s text says :

 

“ Private Use ASNs must be removed from the AS_Path before = being advertised to the global Internet.” =  

 

The question is not whether it goes out of a single Private ASN, but = whether it cross the global Internet.  For example, if several = private DCs band together to have a private exchange beyond the reaches = of the global Internet, I have no reason to specify what happens with = private ASN behind in those private party exchanges. =

 

How do certain Acquisition and ASN mergers cause private ASN to cross = the global Internet?  And why are these private AS not being hidden = by a public AS or AS Confederation.

 

Sue

 

From:= = Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, = December 20, 2012 6:34 PM
To: Nick Hilliard
Cc: Jon = Mitchell; idr wg; Susan Hares
Subject: Re: [Idr] WGLC on = draft-ietf-idr-as-private-reservation-00

 

+1=

 

Acquisitions,= ASN merges etc may all involve use of private ASN space between = consenting parties.  I think this is a SHOULD. =  

 

On Thu, Dec = 20, 2012 at 3:02 PM, Nick Hilliard <nick@foobar.org> = wrote:

On = 20/12/2012 22:38, Jon Mitchell wrote:
> I'm comfortable making the = change to a capital MUST for this sentence
> and adding the = appropriate reference to RFC 2119 as necessary.  I'm just
> = not comfortable telling operators how to perform that action as = there
> are a number of options to do so, which was my point to = David (and he
> seemed to be ok with).  I will make the = changes as necessary to the
> abstract where this statement exists = as well.

If it's of = interest, rfc 6666 ran into much the same issue recently with
the = issue of leaking the rtbh prefix to ebgp peers.  We decided on = SHOULD
rather than MUST because there probably were situations where = there might
be valid operational reasons for leaking the prefix to a = peer. I would
think the same arguments hold for a private ASN = range.

http://tools.ietf.org/html/rfc6666#section-5

Nick


_________= ______________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_028B_01CDDEE4.6C4392D0-- From edc@google.com Thu Dec 20 16:08:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A144C21F87E6 for ; Thu, 20 Dec 2012 16:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zzS5WyrqnID for ; Thu, 20 Dec 2012 16:08:43 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id A4CFF21F87B4 for ; Thu, 20 Dec 2012 16:08:43 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id l8so3051061qaq.7 for ; Thu, 20 Dec 2012 16:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hNLvj4COCugeh3PPCNNrMFb86DL/L31MB4G/J1PPVSQ=; b=UP8HRjNaMO5zadnLR5VekMvP37SJ2gOsEpb7/3AO8iMtv0LcnhxsyEtPLQKm4ErHIx N5RUByQ4lFfFE8luNC1by7S24UCthAuFn8J2YhBS7VuqCY2HCdQY5isUTh6x3JkadyJS KQpYH3SMA+1zTOTJuOCJXSdvLDmP1Un3KkFHVwENfHs/MXkX6JjJ7C4iKZY2NXjSF86z bzeydOh6pXHcNJVDQsODJbb+LEQKW7skSvaepsNMqNtYpfUhF1GNObL5759qHgRKenX0 CrUxY3GGcfegZwtNmSeaUjffkqmPJGGWnMc7OKDsSuHNnalu5RDAUTylrk/ZipvuE7/r 7QCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=hNLvj4COCugeh3PPCNNrMFb86DL/L31MB4G/J1PPVSQ=; b=lYFoe9q1gu0IcSt83gyp8rD0DUmIAnxGX3yqqn7vGlGhJEExPWtvz7daDCkSSfJUPi 21qsgIcr8c3HayT/H+PFLyXAw7D4dJy2cFHynhmcMhKdIkdGXiGz4MS6ao8YKtKjcBmm XoQxVWtBQa02rqhRGuiTe1Jk6irbfQsWQTsTm5+pat+wXTpr9EZV2dUl+Vo4W7jIOcVL rp58DhWwGWEutzl1x5l1aReEzlalBifvCKK1w08rdt3mcqZVjd7miIXT38MWnit1UUco TxjEQGAxpGW6qrgwKT+qyUz+kA8HvCFNQgsGMPla+Pu4yRWXSpSyUmNQR6vCH2iTdXIc ZWHg== Received: by 10.224.196.70 with SMTP id ef6mr5753666qab.14.1356048522991; Thu, 20 Dec 2012 16:08:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.141 with HTTP; Thu, 20 Dec 2012 16:08:02 -0800 (PST) In-Reply-To: <028a01cddf0e$55168d90$ff43a8b0$@ndzh.com> References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <028a01cddf0e$55168d90$ff43a8b0$@ndzh.com> From: Edward Crabbe Date: Thu, 20 Dec 2012 16:08:02 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=20cf300faea382d8bb04d151a637 X-Gm-Message-State: ALoCoQk08tJ2neHjCGIPmfYnbZZBhF8mujLr20+Pw2ggmHUVrVLy1AKNUfigsnvLYKfPxAK+c8uTvWlReFm48J9de8nSrFDpHD1oa0zMIbudF2zo2IFy0Iu5ruxv8ZAxhqIsvuU/feJGFuxHEOhhUckWaFwFn3yIfLVZtf1CXhuPFXkOoCUH49hPfTEYuP0eK0Y6fZrrnjhJ Cc: idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:08:44 -0000 --20cf300faea382d8bb04d151a637 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yep, agree with MUST usage for 'the global internet", but not for arbitrary ebgp peers, per Nick's mail. On Thu, Dec 20, 2012 at 4:01 PM, Susan Hares wrote: > Edward:**** > > ** ** > > +1 =96 that Certainly Acquisitions and ASN mergers will cause multiple > private ASNs. **** > > ** ** > > The draft=92s text says :**** > > ** ** > > =93 Private Use ASNs must be removed from the AS_Path before being > advertised to the global Internet.=94 **** > > ** ** > > The question is not whether it goes out of a single Private ASN, but > whether it cross the global Internet. For example, if several private DC= s > band together to have a private exchange beyond the reaches of the global > Internet, I have no reason to specify what happens with private ASN behin= d > in those private party exchanges. **** > > ** ** > > How do certain Acquisition and ASN mergers cause private ASN to cross the > global Internet? And why are these private AS not being hidden by a publ= ic > AS or AS Confederation. **** > > ** ** > > Sue **** > > ** ** > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* Thursday, December 20, 2012 6:34 PM > *To:* Nick Hilliard > *Cc:* Jon Mitchell; idr wg; Susan Hares > > *Subject:* Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00**** > > ** ** > > +1**** > > ** ** > > Acquisitions, ASN merges etc may all involve use of private ASN space > between consenting parties. I think this is a SHOULD. **** > > ** ** > > On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard wrote:**= * > * > > On 20/12/2012 22:38, Jon Mitchell wrote: > > I'm comfortable making the change to a capital MUST for this sentence > > and adding the appropriate reference to RFC 2119 as necessary. I'm jus= t > > not comfortable telling operators how to perform that action as there > > are a number of options to do so, which was my point to David (and he > > seemed to be ok with). I will make the changes as necessary to the > > abstract where this statement exists as well.**** > > If it's of interest, rfc 6666 ran into much the same issue recently with > the issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD > rather than MUST because there probably were situations where there might > be valid operational reasons for leaking the prefix to a peer. I would > think the same arguments hold for a private ASN range. > > http://tools.ietf.org/html/rfc6666#section-5 > > Nick**** > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr**** > > ** ** > --20cf300faea382d8bb04d151a637 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yep, agree with MUST usage fo= r 'the global internet", but not for arbitrary ebgp peers, per Nic= k's mail. =A0


On Thu,= Dec 20, 2012 at 4:01 PM, Susan Hares <shares@ndzh.com> wrote:=

Edward:

=A0

+1 =96 that Certainly Acquisitions and ASN me= rgers will cause multiple private ASNs.

=A0<= /p>

The draft=92s text say= s :

=A0<= /p>

=93 Private Use ASNs m= ust be removed from the AS_Path before being advertised to the global Inter= net.=94 =A0

=A0<= /p>

The question is not wh= ether it goes out of a single Private ASN, but whether it cross the global = Internet. =A0For example, if several private DCs band together to have a pr= ivate exchange beyond the reaches of the global Internet, I have no reason = to specify what happens with private ASN behind in those private party exch= anges.

=A0<= /p>

How do certain Acquisi= tion and ASN mergers cause private ASN to cross the global Internet? =A0And= why are these private AS not being hidden by a public AS or AS Confederati= on.

=A0<= /p>

Sue

=A0<= /p>

From: Edwar= d Crabbe [mailto:edc@go= ogle.com]
Sent: Thursday, December 20, 2012 6:34 PM
To: Nick Hilliar= d
Cc: Jon Mitchell; idr wg; Susan Hares


Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservat= ion-00

=A0

+1

=A0

Acquisitions, ASN merges etc may all i= nvolve use of private ASN space between consenting parties. =A0I think this= is a SHOULD. =A0

=A0

=

On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard <nick@foobar.org> wrote:

On 20= /12/2012 22:38, Jon Mitchell wrote:
> I'm comfortable making the = change to a capital MUST for this sentence
> and adding the appropriate reference to RFC 2119 as necessary. =A0I= 9;m just
> not comfortable telling operators how to perform that acti= on as there
> are a number of options to do so, which was my point to= David (and he
> seemed to be ok with). =A0I will make the changes as necessary to the<= br>> abstract where this statement exists as well.<= /p>

If it's of interest, rfc 666= 6 ran into much the same issue recently with
the issue of leaking the rtbh prefix to ebgp peers. =A0We decided on SHOULD=
rather than MUST because there probably were situations where there mig= ht
be valid operational reasons for leaking the prefix to a peer. I woul= d
think the same arguments hold for a private ASN range.

http://tools.= ietf.org/html/rfc6666#section-5

Nick


___________________________= ____________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=A0


--20cf300faea382d8bb04d151a637-- From jrmitche@puck.nether.net Thu Dec 20 16:21:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4BA21F8A6B for ; Thu, 20 Dec 2012 16:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2fTkravcjiZ for ; Thu, 20 Dec 2012 16:21:06 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3321F87B1 for ; Thu, 20 Dec 2012 16:21:06 -0800 (PST) Received: from [192.168.1.7] (pool-98-118-242-200.clppva.fios.verizon.net [98.118.242.200]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBL0KrHo006307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 19:20:54 -0500 References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: <027701cddf09$1d074d90$5715e8b0$@ndzh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5A90C164-8E47-4A56-986F-634A1217E55E@puck.nether.net> X-Mailer: iPhone Mail (10A523) From: Jon Mitchell Date: Thu, 20 Dec 2012 19:20:52 -0500 To: Susan Hares X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 19:20:54 -0500 (EST) Cc: "" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:21:08 -0000 I agree that any use case that requires the text to move to should is probab= ly not a Private Use case by definition. -Jon On Dec 20, 2012, at 6:24 PM, "Susan Hares" wrote: > Nick: >=20 > I'd be interested in you suggesting the situations would be valid to leak > the AS private path AS to a peer, before we downgrade to a "SHOULD".=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Nick Hilliard [mailto:nick@foobar.org]=20 > Sent: Thursday, December 20, 2012 6:03 PM > To: Jon Mitchell > Cc: Susan Hares; 'Randy Bush'; idr@ietf.org; stbryant@cisco.com > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 >=20 > On 20/12/2012 22:38, Jon Mitchell wrote: >> I'm comfortable making the change to a capital MUST for this sentence=20 >> and adding the appropriate reference to RFC 2119 as necessary. I'm=20 >> just not comfortable telling operators how to perform that action as=20 >> there are a number of options to do so, which was my point to David=20 >> (and he seemed to be ok with). I will make the changes as necessary=20 >> to the abstract where this statement exists as well. >=20 > If it's of interest, rfc 6666 ran into much the same issue recently with t= he > issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD rath= er > than MUST because there probably were situations where there might be vali= d > operational reasons for leaking the prefix to a peer. I would think the sa= me > arguments hold for a private ASN range. >=20 > http://tools.ietf.org/html/rfc6666#section-5 >=20 > Nick >=20 From farmer@umn.edu Thu Dec 20 16:35:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263321F8A67 for ; Thu, 20 Dec 2012 16:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYQzxLz9pMoU for ; Thu, 20 Dec 2012 16:35:21 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 161A521F89D3 for ; Thu, 20 Dec 2012 16:35:21 -0800 (PST) Received: from mail-ob0-f197.google.com (mail-ob0-f197.google.com [209.85.214.197]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 18:35:15 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f197.google.com [209.85.214.197] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f197.google.com with SMTP id v19so16854868obq.8 for ; Thu, 20 Dec 2012 16:35:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=iYoMkTiqP58GY0UdAaUeg6OorYLnPyG4ClHmUYXNV1U=; b=ji1JZ8VUA0KNw/Ug2mFcgqZcsAoIQ9IWLZszCkv9IUzGlV7Ku3nvxG/b9bmqYvzQcW IWH6fTu/6AYYaWXnNgOkMrFBqZO4AdG8MiDbGtecOhJDq03ABnm5zirq2LKsGZbdY/MA S7gwiUns3THAjs8hB1RQJeJfNX502xYm/874QB2hnPFjnH/1xGgm7u0E8zLGkufMhSkV ZwKscTMf127hvgCA95fJ9CqJrvdJIhaq4JwtSSHSuyGG1vWVzGa1u04HqpKpLXX12CJq EGNIhp7sgnVcBvJ3qqhGhRmaqQSwHXRMP0C+hcOvJCQo7NNvYVnaG45KYugQa/V0rIcp gUDA== X-Received: by 10.50.150.142 with SMTP id ui14mr7102139igb.93.1356050115075; Thu, 20 Dec 2012 16:35:15 -0800 (PST) X-Received: by 10.50.150.142 with SMTP id ui14mr7102136igb.93.1356050114966; Thu, 20 Dec 2012 16:35:14 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu ([2607:ea00:101:2001:64e9:647f:19ab:d14f]) by mx.google.com with ESMTPS id fa6sm8216643igb.2.2012.12.20.16.35.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 16:35:14 -0800 (PST) Message-ID: <50D3AEC0.7070503@umn.edu> Date: Thu, 20 Dec 2012 18:35:12 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu> <20121220180541.GC1910@puck.nether.net> In-Reply-To: <20121220180541.GC1910@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlIBGqH5zC+LYcvtonk0J1Gs3aAdYUgneFK1e6bzQLkhB8RpYjEXaJVNSbm2mUAaO5VxFG56D8oXlkNZOKr4aE/SdTzsDP2Cc58zgrM9msti737ItWH3eX9351sVmuLPpU/2aCr Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:35:22 -0000 On 12/20/12 12:05 , Jon Mitchell wrote: > > On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote: >> On 12/19/12 08:57 , Jon Mitchell wrote: >> >>> Maybe some others would like to weigh in on one of the above options now >>> that it's a focused discussion (otherwise I plan to make the small edits >>> discussed in previous threads and move the start of range to >>> 42xxxxxxxx so we can close this out...) >> >> >> The idea is to allow the simple regexp of 42???????? to match >> private use ASNs. However, this makes a few assumptions. > > Human identifiable range was the primary concern raised with regex > implementation another given justification for changing the > recommendation to IANA for the start of range. Bull!! Lets be honest here, 10 digits without any separators doesn't meet any definition of human friendly I can think of. Also, humans would recognize 4.28B and above just about as easy as 4.2B and above, the real reason to go to 4.2B is it makes the regexp much simpler. I'm fine with that, but its to make regexp easy. However, picking 4.2B to make the staring point human/decimal/regexp friendly but completely ignoring the any issues at end point isn't going to work either. >> 1. While not part of the Private Use ASN range, the intended regexp >> also matches the reserved ASN 4294967295, and therefore 4294967295 >> can never be a valid ASN in an AS_PATH. > > The draft does not state how to construct a regex, this is out of scope > for the draft. Some operators may not even choose or need to filter > private use ASN's inbound or outbound based on their > requirements/design. That argument doesn't fly, because you are saying that they MUST filter outbound to the Internet. Yes, if there not announcing to the Internet, then there isn't an issue, but that is a common enough use case that it makes scene to provide some guidance on how to properly implement the filter you are saying they must implement. You don't need to cover every possible solution, but saying that regular expression of the from 42????????, where "?" selects 0-9, would provide a very big hint. However, my primary motivation in bringing up the end point issues aren't operational, but is to ensure future protocol work doesn't create an issue with how people use the Private Use range. If there were some future protocol changes, especially anything that required 4294967295 to be valid within the AS_PATH, there could be issues. I don't think anyone thinks this should happen, but its not explicit anywhere. I'm only trying to make sure we don't making a similar mistake that was made with AS65535 in RFC 1930, that we are fixing now. As a mater of fact this could be an issue with any range, no matter what size we pick, at the top of the 32bit ASN range. The regexp issues with 4.2B is only one possible issue. There could easily be issues with 4294967295 and your original range. It would be problematic for many reason if 4294967295 became a valid ASN within AS_PATH. If we're going to pick a range at the very top end of the 32bit ASNs then that should be made clear. Also, you say were picking 4.2B primarily to be human friendly. But, there is nothing human friendly about 4294967294 being part of the range and that 4294967295 is not part of the range. So at the very least we should make it abundantly clear 4294967295 is not part of the range. Maybe something like this, creating a new section; X. Other Reserved ASNs It should be noted that 65535 and 4294967295 are reserved ASNs, documented in the IANA Autonomous System Numbers Registry [IANA.AS]. These two ASNs are the numerically highest values in the two-octet and four-octet AS number spaces respectively. While directly adjacent to the Private Use ASNs they are not part of either Private Use ASN range, and MUST never be used as Private Use ASNs. However, any protocol changes effecting the status of these two ASNs should consider any impact on how the Private Use ASNs are used. This makes it abundantly clear that these two ASNs are not part of the Private Use ranges, this conspicuously corrects RFC 1930 regarding 65535. Further, it makes it clear there are no other valid ASNs above 4294967295 that need to be worried about. Finally, it make it clear that the current status of these two ASNs as reserved is important to the Private Use ranges and that any changes could have an impact on the use of Private Use ASNs. >> 2. The intended regexp would select ASNs beyond the 32bit ASN range, >> if they were valid, that is 4294967296 through 4299999999. >> Therefore, if the ASN range were ever expanded to make these valid >> ASNs, the private use ASN range would also need to be expanded to be >> included these ASNs as well. > > Certainly something operators should concern themselves with when > discussions start on moving beyond 4 byte ASNs (maybe a note about it > could be attached to that draft). On a side note, do you plan on this > before or after IPv6 exhaustion? Again its not the operators I'm worried about, its how future protocol work would interact the assumptions we are making about the validity of picking 4.2B as the starting point, and basically ignoring the end point issues. This is mostly a hand wave for the operators, and that's fine, it will probably just work. But, if the protocol guys do something in the future today's operational hand wave could become tomorrows ugly problem. >> If we want to use 4.2B as the starting point to simplify regexp >> matching of the private use range then these assumptions need to be >> explicitly stated in the draft. > > I disagree, I prefer not delving how to construct regex's properly or > stating how they work in various implementations in a simple IANA > reservation draft. While I'd prefer we did cover the whole regexp thing, that's not really necessary to deal with these issues. If you include something like the text above regarding 4294967295, it makes it clear there are range endpoint issues that should be considered carefully. I'd be OK dropping any discussion of what happens if you expand the ASN range, that is probably out of scope. But the above text makes it clear that there are no valid ASNs above 4294967295, that should be enough of a hint if you don't cover the regexp stuff explicitly. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From shares@ndzh.com Thu Dec 20 16:41:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78FA21F8AA6 for ; Thu, 20 Dec 2012 16:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.197 X-Spam-Level: * X-Spam-Status: No, score=1.197 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GXgd2Wjng7w for ; Thu, 20 Dec 2012 16:41:07 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8054721F8A67 for ; Thu, 20 Dec 2012 16:41:07 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Edward Crabbe'" References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <028a01cddf0e$55168d90$ff43a8b0$@ndzh.com> In-Reply-To: Date: Thu, 20 Dec 2012 19:40:47 -0500 Message-ID: <02b501cddf13$d1fa0ad0$75ee2070$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B6_01CDDEE9.E92625B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9Ai04lyEBLBVY6wHIReRPAhYVXs2X3xTdgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:41:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B6_01CDDEE9.E92625B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ed: + 1 agree to your point. Therefore, I think the text is fine with the MUST as it is. Sue From: Edward Crabbe [mailto:edc@google.com] Sent: Thursday, December 20, 2012 7:08 PM To: Susan Hares Cc: Nick Hilliard; Jon Mitchell; idr wg Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 Yep, agree with MUST usage for 'the global internet", but not for arbitrary ebgp peers, per Nick's mail. On Thu, Dec 20, 2012 at 4:01 PM, Susan Hares wrote: Edward: +1 - that Certainly Acquisitions and ASN mergers will cause multiple private ASNs. The draft's text says : " Private Use ASNs must be removed from the AS_Path before being advertised to the global Internet." The question is not whether it goes out of a single Private ASN, but whether it cross the global Internet. For example, if several private DCs band together to have a private exchange beyond the reaches of the global Internet, I have no reason to specify what happens with private ASN behind in those private party exchanges. How do certain Acquisition and ASN mergers cause private ASN to cross the global Internet? And why are these private AS not being hidden by a public AS or AS Confederation. Sue From: Edward Crabbe [mailto:edc@google.com] Sent: Thursday, December 20, 2012 6:34 PM To: Nick Hilliard Cc: Jon Mitchell; idr wg; Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 +1 Acquisitions, ASN merges etc may all involve use of private ASN space between consenting parties. I think this is a SHOULD. On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard wrote: On 20/12/2012 22:38, Jon Mitchell wrote: > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm just > not comfortable telling operators how to perform that action as there > are a number of options to do so, which was my point to David (and he > seemed to be ok with). I will make the changes as necessary to the > abstract where this statement exists as well. If it's of interest, rfc 6666 ran into much the same issue recently with the issue of leaking the rtbh prefix to ebgp peers. We decided on SHOULD rather than MUST because there probably were situations where there might be valid operational reasons for leaking the prefix to a peer. I would think the same arguments hold for a private ASN range. http://tools.ietf.org/html/rfc6666#section-5 Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_02B6_01CDDEE9.E92625B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ed:

 

+ 1 agree to your point.  Therefore,  I think the text is = fine with the MUST as it is.   

 

Sue

 

 

From:= = Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, = December 20, 2012 7:08 PM
To: Susan Hares
Cc: Nick = Hilliard; Jon Mitchell; idr wg
Subject: Re: [Idr] WGLC on = draft-ietf-idr-as-private-reservation-00

 

Yep, agree = with MUST usage for 'the global internet", but not for arbitrary = ebgp peers, per Nick's mail. =  

 

On Thu, Dec = 20, 2012 at 4:01 PM, Susan Hares <shares@ndzh.com> = wrote:

Edward:

 

+1 – that Certainly Acquisitions and ASN mergers will cause = multiple private ASNs.

 

The draft’s text says :

 

“ Private Use ASNs must be removed from the AS_Path before = being advertised to the global Internet.” =  

 

The question is not whether it goes out of a single Private ASN, but = whether it cross the global Internet.  For example, if several = private DCs band together to have a private exchange beyond the reaches = of the global Internet, I have no reason to specify what happens with = private ASN behind in those private party exchanges. =

 

How do certain Acquisition and ASN mergers cause private ASN to cross = the global Internet?  And why are these private AS not being hidden = by a public AS or AS Confederation.

 

Sue

 

From:= = Edward Crabbe [mailto:edc@google.com]
Sent: Thursday, = December 20, 2012 6:34 PM
To: Nick Hilliard
Cc: Jon = Mitchell; idr wg; Susan Hares


Subjec= t: Re: [Idr] WGLC on = draft-ietf-idr-as-private-reservation-00

 <= /o:p>

+1

 =

Acquisitions,= ASN merges etc may all involve use of private ASN space between = consenting parties.  I think this is a SHOULD. =  

 =

On Thu, Dec = 20, 2012 at 3:02 PM, Nick Hilliard <nick@foobar.org> = wrote:

On = 20/12/2012 22:38, Jon Mitchell wrote:
> I'm comfortable making the = change to a capital MUST for this sentence
> and adding the = appropriate reference to RFC 2119 as necessary.  I'm just
> = not comfortable telling operators how to perform that action as = there
> are a number of options to do so, which was my point to = David (and he
> seemed to be ok with).  I will make the = changes as necessary to the
> abstract where this statement exists = as well.

If it's of = interest, rfc 6666 ran into much the same issue recently with
the = issue of leaking the rtbh prefix to ebgp peers.  We decided on = SHOULD
rather than MUST because there probably were situations where = there might
be valid operational reasons for leaking the prefix to a = peer. I would
think the same arguments hold for a private ASN = range.

http://tools.ietf.org/html/rfc6666#section-5

Nick


_________= ______________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 =

 

------=_NextPart_000_02B6_01CDDEE9.E92625B0-- From farmer@umn.edu Thu Dec 20 16:52:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E821E803D for ; Thu, 20 Dec 2012 16:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGYLfY8+HSaX for ; Thu, 20 Dec 2012 16:52:15 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2C21E803C for ; Thu, 20 Dec 2012 16:52:15 -0800 (PST) Received: from mail-oa0-f71.google.com (mail-oa0-f71.google.com [209.85.219.71]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Dec 2012 18:52:04 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f71.google.com [209.85.219.71] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f71.google.com with SMTP id n12so17234832oag.10 for ; Thu, 20 Dec 2012 16:52:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=gQhUMl1sVbVWEfwQmhxw3Lc/o3nsXhfYCyb6vwom6Do=; b=KPD8yWu30P1a4A08HStw2WPQq8qplgFQzylgCVuCloL3xbttxkymUfdKjFvQnPHakL u/G0yn+JDnZfTsv/ttMBOL9FOz6Y5YwxJl7hqfiQoSu+H4viiIiewu5s4wEllG4bhucz o+6ms4rgjbMNM9ejFVVUxg+GdBBH0R9Mx2ZOa2qbsNIsY9XjjBF/tKzZJxW/h+Hn4bJy Z1cfoM/FSSvZnRi2EkML4Cj/V2exNrWlSSFKBUXEGD2gkEYuyxSuRSyw/XCHbrM0ZZUj 20YPq38Sd53L87y0Ia6i1CUQwJ4WMb9Jrexazb60r9WJBM+Cj6e60Hf2NLE9G6HdcSee 5Rzg== X-Received: by 10.42.94.8 with SMTP id z8mr10463916icm.36.1356051124360; Thu, 20 Dec 2012 16:52:04 -0800 (PST) X-Received: by 10.42.94.8 with SMTP id z8mr10463910icm.36.1356051124284; Thu, 20 Dec 2012 16:52:04 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu (x-134-84-88-75.nts.umn.edu. [134.84.88.75]) by mx.google.com with ESMTPS id s3sm8221950igb.14.2012.12.20.16.52.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 16:52:03 -0800 (PST) Message-ID: <50D3B2B1.1030504@umn.edu> Date: Thu, 20 Dec 2012 18:52:01 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jon Mitchell References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> In-Reply-To: <20121220223820.GA19458@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkPVHyCgekcBt+zv9RU+WlV4bbP6AG0vptaZqeUT0LyBUpSc7+UBaZzVY3frn9qW4YSLHyjA73+YftYpTj0LCYClKQP4CxxgyL75yUpO84ggGmHIMKZz9KYp05eOlXVr6zXWIHA Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:52:15 -0000 On 12/20/12 16:38 , Jon Mitchell wrote: > > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm just > not comfortable telling operators how to perform that action as there > are a number of options to do so, which was my point to David (and he > seemed to be ok with). I will make the changes as necessary to the > abstract where this statement exists as well. If you go to a capital MUST on the outbound to the global Internet then I fine with not say everyone else MAY disregard inbound from the global Internet. However, if that MUST was changed to SHOULD then I would would want an everyone else MAY disregard inbound from the global Internet. > As for BCP versus info, I leave that up to the chairs, but this does not > obsolete or otherwise change text in RFC 1930 outside of the IANA > considerations section (RFC 1930 is primarily about justification for an > ASN). There is no "practice" being advocated by the draft to be best or > current, outside of the practice of not sending Private Use ASNs to the > Internet. BCP is what I think it should be. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jsw@inconcepts.biz Thu Dec 20 17:19:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B157021E8037 for ; Thu, 20 Dec 2012 17:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsDx8TYF-XQK for ; Thu, 20 Dec 2012 17:19:30 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09C21E8034 for ; Thu, 20 Dec 2012 17:19:30 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id u21so3493251ial.36 for ; Thu, 20 Dec 2012 17:19:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=poCfEvYzZQpwrG7gFGt/eWthD6GpQXMHkb6xZS6a5PY=; b=JBPr78R9gf9kjyF3L/PJwNowIO8x8v0sR5Vn+c/dih3epswpXUNrOBmaONA3ud23AL jjxvxdUcUIPKhwjqMxfoQkINlWsgfueRgZkoseMusqEN29h4/GIFpCljbtuyaQye3o2h wwUxN6E1Bbf9gM+8RszkTuWgOhvSfVIn8t20lsNil6t0UaLZkxkmTK7H0Dz05XUIyr/P 4LoRsWPslG92YfRiV5BLW73/Z/el/cLGiuzpVMW1oLNS0tVJozAhSL00bHlTHUTQFunX diiQs/TsCsqmJlpiFJ5qhtPsLOzDDdvppxVN3itp26Bk+MKOUd7Qud9lgFgJ5ShyPJe0 X4sg== MIME-Version: 1.0 Received: by 10.50.170.102 with SMTP id al6mr11884665igc.70.1356052769685; Thu, 20 Dec 2012 17:19:29 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 20 Dec 2012 17:19:29 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <027701cddf09$1d074d90$5715e8b0$@ndzh.com> References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> Date: Thu, 20 Dec 2012 20:19:29 -0500 Message-ID: From: Jeff Wheeler To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlJtzkFe3JO/i6yRTrjb2q6nL519r40EudV6v17di8ksCJXbGYkwDNlkkCjyW8h67+Nekhg Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 01:19:31 -0000 On Thu, Dec 20, 2012 at 6:24 PM, Susan Hares wrote: > I'd be interested in you suggesting the situations would be valid to leak > the AS private path AS to a peer, before we downgrade to a "SHOULD". This is happening in the DFZ today. You don't have to take my word for it. Log onto a router and check. You can even find 65535 in DFZ AS_PATHs even though that is not a valid ASN! I think it's called a Private ASN and by its very nature, it ought not appear in a DFZ AS_PATH. However, since some networks are actually doing this right now, perhaps it is worth asking them why. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From nick@foobar.org Fri Dec 21 03:43:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F4921F86D8 for ; Fri, 21 Dec 2012 03:43:33 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQXGMWcydV76 for ; Fri, 21 Dec 2012 03:43:32 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 40DAE21F8909 for ; Fri, 21 Dec 2012 03:43:31 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.dyn.netability.ie (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBLBffMS059229 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 11:41:42 GMT (envelope-from nick@foobar.org) Message-ID: <50D44B5A.4080308@foobar.org> Date: Fri, 21 Dec 2012 11:43:22 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Susan Hares References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> In-Reply-To: <027701cddf09$1d074d90$5715e8b0$@ndzh.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 11:43:33 -0000 On 20/12/2012 23:24, Susan Hares wrote: > I'd be interested in you suggesting the situations would be valid to leak > the AS private path AS to a peer, before we downgrade to a "SHOULD". the proposed text states: "If Private Use ASNs are used and prefixes are originated from these ASNs which are destined to the Internet, Private Use ASNs must be removed from the AS_PATH before being advertised to the global Internet." To start off, there's the usual problem: what do we mean when we talk about "the Internet"? In fact there's more to the situation. We're dealing with operational stuff here rather than protocol specification, i.e. human behaviour rather than computer specifications. I'd have no problem with throwing "MUST" around when dealing with protocol handling, but when it gets to operational stuff, I would be a lot more circumspect for several reasons: - operational people will happily ignore a MUST if they feel it suits their purpose at a specific time. - the Internet is a bunch of interconnected networks and what works for policy for one network peer might not work for another. - I don't not have the wisdom or the foresight to predict every eventuality where there might be legitimate reasons to forward a prefix with a private ASN over an ebgp peer. - I suspect most private asn leaks we see in the DFZ are accidental, and MUST won't help in this situation. - if this is specified as 2119-compatible MUST, vendors may be tempted to hardwire an AS path prefix filter for ebgp sessions into their code in a way which cannot be circumvented (in the same way that e.g. 169.254/16 is hardwired and cannot be used in a bgp NLRI). I'd see lots of value in having a vendor default of not forwarding private ASNs, but I think this could be quite harmful to have an absolute prohibition Private ASN leaks are going to happen in two main circumstances: accidental and deliberate. I don't think that putting in "MUST" will actually deal with either. What's important from an operational point of view is getting vendors to implement a default but overrideable filter so that the bar for accidental leaks is raised to a sufficiently high point that accidental leaks are only going to happen when the safety nets are removed. If we're going to make a statement on this one way or another, I think it should be along the lines of SHOULD rather than MUST, and that we should consider including a vendor hint to suggest that the default implementation behaviour would be to filter private asns. This complicates issues slightly because we get into an issue of semantics: does the prefix get dropped? Or does the private ASN component get stripped from the AS path? In term of specific situations where this might be useful, yeah, mergers and acquisitions would be one. Others might include private peering between ASN confederations. Or interconnections between the large number of private networks around the world, many of which use a mixture of private and public ASNs. Or test peerings. Anyway, these were some of the issues that cropped up during the WG discussion phase for rfc 6666. We eventually decided to go with the idea of making a recommendation that the prefix shouldn't be transferred over ebgp sessions, and specifically made the point in the security section to highlight it. This avoided the issue of defining "the Internet", while encapsulating what we wanted to say in the way that we wanted to say it. Nick From warren@kumari.net Fri Dec 21 05:34:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFEE21F86FA for ; Fri, 21 Dec 2012 05:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sPaW-EV8nVu for ; Fri, 21 Dec 2012 05:34:57 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F121F86EC for ; Fri, 21 Dec 2012 05:34:56 -0800 (PST) Received: from [192.168.1.38] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id CDCE01B4032C; Fri, 21 Dec 2012 08:34:54 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Fri, 21 Dec 2012 08:34:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8E57B034-D725-476D-A6D8-BAA87EA7F8B0@kumari.net> References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 13:34:57 -0000 On Dec 20, 2012, at 8:19 PM, Jeff Wheeler wrote: > On Thu, Dec 20, 2012 at 6:24 PM, Susan Hares wrote: >> I'd be interested in you suggesting the situations would be valid to = leak >> the AS private path AS to a peer, before we downgrade to a "SHOULD". >=20 > This is happening in the DFZ today. You don't have to take my word > for it. Log onto a router and check. You can even find 65535 in DFZ > AS_PATHs even though that is not a valid ASN! Yup, Susan is well aware of this... >=20 > I think it's called a Private ASN and by its very nature, it ought not > appear in a DFZ AS_PATH. >=20 > However, since some networks are actually doing this right now, > perhaps it is worth asking them why. 'tis called a leak, and is (in every case I've seen) unintentional=85 Someone forgot to add "remove-private" or (if they are masochists) = "remove-private-as" to a peer somewhere=85. W >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 -- I once absend-mindedly ordered Three Mile Island dressing in a = restaurant and, with great presence of mind, they brought Thousand = Island Dressing and a bottle of chili sauce. -- Terry Pratchett From jrmitche@puck.nether.net Fri Dec 21 06:05:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB621F8583 for ; Fri, 21 Dec 2012 06:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97To2Oe4YM7p for ; Fri, 21 Dec 2012 06:05:52 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id B76A721F854D for ; Fri, 21 Dec 2012 06:05:52 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBLE5pvV011906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 09:05:51 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBLE5p5Q011905; Fri, 21 Dec 2012 09:05:51 -0500 Date: Fri, 21 Dec 2012 09:05:51 -0500 From: Jon Mitchell To: Jeff Wheeler Message-ID: <20121221140551.GB8731@puck.nether.net> References: <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 21 Dec 2012 09:05:52 -0500 (EST) Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:05:53 -0000 On Thu, Dec 20, 2012 at 08:19:29PM -0500, Jeff Wheeler wrote: > On Thu, Dec 20, 2012 at 6:24 PM, Susan Hares wrote: > > I'd be interested in you suggesting the situations would be valid to leak > > the AS private path AS to a peer, before we downgrade to a "SHOULD". > > This is happening in the DFZ today. You don't have to take my word > for it. Log onto a router and check. You can even find 65535 in DFZ > AS_PATHs even though that is not a valid ASN! I think we are all aware of this. > > I think it's called a Private ASN and by its very nature, it ought not > appear in a DFZ AS_PATH. > > However, since some networks are actually doing this right now, > perhaps it is worth asking them why. > Isn't this like asking why folks leak RFC 1918 space into the global routing table, /32's into the routing table, etc... ? Mis-configuration seems obvious, but I don't think a poll is a fruitful exercise. I think because something happens today due to accidental (or poorly designed networks that make fixing the issue difficult) doesn't mean we should soften language that states operators (if they strive to be RFC compliant) MUST or MUST NOT do something. One of the reasons why it is not fixed in these cases is likely that the impact is so low to the originator (who may have a covering route) or the receiver. From jrmitche@puck.nether.net Fri Dec 21 06:34:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A716B21F8546 for ; Fri, 21 Dec 2012 06:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Ibhlosvhhf for ; Fri, 21 Dec 2012 06:34:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D3E1221F8512 for ; Fri, 21 Dec 2012 06:34:21 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBLEY8oP015484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 09:34:08 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBLEY8Sb015483; Fri, 21 Dec 2012 09:34:08 -0500 Date: Fri, 21 Dec 2012 09:34:08 -0500 From: Jon Mitchell To: Nick Hilliard Message-ID: <20121221143408.GC8731@puck.nether.net> References: <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> <50D44B5A.4080308@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50D44B5A.4080308@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 21 Dec 2012 09:34:08 -0500 (EST) Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:34:22 -0000 On Fri, Dec 21, 2012 at 11:43:22AM +0000, Nick Hilliard wrote: > On 20/12/2012 23:24, Susan Hares wrote: > > I'd be interested in you suggesting the situations would be valid to leak > > the AS private path AS to a peer, before we downgrade to a "SHOULD". > > the proposed text states: "If Private Use ASNs are used and prefixes are > originated from these ASNs which are destined to the Internet, Private Use > ASNs must be removed from the AS_PATH before being advertised to the global > Internet." > > To start off, there's the usual problem: what do we mean when we talk about > "the Internet"? Terminology seems clear as outside of the "single organization" context to which Private Use is defined? This term is the same as in RFC 1930, and I don't believe the leaks we see are due to semantic issues in that document, nor future leaks will be based on mis-reading of this text. > - operational people will happily ignore a MUST if they feel it suits their > purpose at a specific time. This is always true even for protocol specifications, implementers can choose to forgo being RFC compliant for their own reasons. At MUST it will be obvious they are not in the right, if we soften it to should, maybe the operators who ignore the SHOULD will say "the RFC didn't say I MUST remove them" if asked to fix it? > > - the Internet is a bunch of interconnected networks and what works for > policy for one network peer might not work for another. Private Use by definition should be not be seen on the Internet, we are still awaiting the case where it should be seen outside a single organization. > > - I don't not have the wisdom or the foresight to predict every eventuality > where there might be legitimate reasons to forward a prefix with a private > ASN over an ebgp peer. The draft doesn't say not to send to eBGP peers, just peers outside of your organization. > > - I suspect most private asn leaks we see in the DFZ are accidental, and > MUST won't help in this situation. > Nothing produced by IETF will help in this situation, however I think IETF should specify what is the correct behavior. > - if this is specified as 2119-compatible MUST, vendors may be tempted to > hardwire an AS path prefix filter for ebgp sessions into their code in a > way which cannot be circumvented (in the same way that e.g. 169.254/16 is > hardwired and cannot be used in a bgp NLRI). I'd see lots of value in > having a vendor default of not forwarding private ASNs, but I think this > could be quite harmful to have an absolute prohibition Since this is not a protocol specification, I think this is personally unlikely. Given there is argueably (but not verifiably) many more Private ASNs in use than Public ASNs, changing this default seems unlikely. Given the impact of leaked private ASNs versus leaked RFC 1918 space, and vendors not defaulting to not sending that, it would seem unlikely this becomes a default. But whether or not it does or not is not likely going to be due to the operational considerations section of this RFC in my opinion. > > Private ASN leaks are going to happen in two main circumstances: accidental > and deliberate. I don't think that putting in "MUST" will actually deal > with either. What's important from an operational point of view is getting > vendors to implement a default but overrideable filter so that the bar for > accidental leaks is raised to a sufficiently high point that accidental > leaks are only going to happen when the safety nets are removed. I agree that nothing in this IETF draft will likely solve the leak problem, however at least someone might point to it as an indication of what is correct or not. > > If we're going to make a statement on this one way or another, I think it > should be along the lines of SHOULD rather than MUST, and that we should > consider including a vendor hint to suggest that the default implementation > behaviour would be to filter private asns. I don't think this draft nor this section is a good place to specify vendor implementation behavior. This was meant to be guidance for operators in use of Private ASNs. > > This complicates issues slightly because we get into an issue of semantics: > does the prefix get dropped? Or does the private ASN component get > stripped from the AS path? Yes, if we take it out of operator control and into vendor implementation guidance, these would become risks. > > In term of specific situations where this might be useful, yeah, mergers > and acquisitions would be one. Others might include private peering > between ASN confederations. Or interconnections between the large number > of private networks around the world, many of which use a mixture of > private and public ASNs. Or test peerings. I think you are focusing on some possible vendor implementation that doesn't exist that prevents Private Use ASN exchange over every eBGP peering and is not configurable rather than the guidance to operators. If ANY of these cases require routes to go to the global Internet, Private Use ASNs MUST not be in the AS_PATH as the draft says. If these use cases are not for routes that go to the global Internet, the statment didn't apply in the first place. Jon From shares@ndzh.com Fri Dec 21 06:37:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226C221F863B for ; Fri, 21 Dec 2012 06:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.139 X-Spam-Level: * X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L60tuLkQlRyJ for ; Fri, 21 Dec 2012 06:37:25 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8893521F8635 for ; Fri, 21 Dec 2012 06:37:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'David Farmer'" , "'Jon Mitchell'" References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3B2B1.1030504@umn.edu> In-Reply-To: <50D3B2B1.1030504@umn.edu> Date: Fri, 21 Dec 2012 09:37:18 -0500 Message-ID: <02fd01cddf88$ae1069f0$0a313dd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9Aw2Zg3aYAU2loA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:37:26 -0000 David: On the inbound "MAY", I'm not sure I know which text in section 3 you are indicating. Rather than guess at the text you are implying, would you please just send the exact text from the latest draft. Thank you, Sue -----Original Message----- From: David Farmer [mailto:farmer@umn.edu] Sent: Thursday, December 20, 2012 7:52 PM To: Jon Mitchell Cc: Susan Hares; idr@ietf.org; David Farmer Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 On 12/20/12 16:38 , Jon Mitchell wrote: > > I'm comfortable making the change to a capital MUST for this sentence > and adding the appropriate reference to RFC 2119 as necessary. I'm > just not comfortable telling operators how to perform that action as > there are a number of options to do so, which was my point to David > (and he seemed to be ok with). I will make the changes as necessary > to the abstract where this statement exists as well. If you go to a capital MUST on the outbound to the global Internet then I fine with not say everyone else MAY disregard inbound from the global Internet. However, if that MUST was changed to SHOULD then I would would want an everyone else MAY disregard inbound from the global Internet. > As for BCP versus info, I leave that up to the chairs, but this does > not obsolete or otherwise change text in RFC 1930 outside of the IANA > considerations section (RFC 1930 is primarily about justification for > an ASN). There is no "practice" being advocated by the draft to be > best or current, outside of the practice of not sending Private Use > ASNs to the Internet. BCP is what I think it should be. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From ietfc@btconnect.com Fri Dec 21 07:08:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C781E21F85FD for ; Fri, 21 Dec 2012 07:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpvfuW0hl2un for ; Fri, 21 Dec 2012 07:08:22 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 760FF21F85ED for ; Fri, 21 Dec 2012 07:08:22 -0800 (PST) Received: from mail203-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Dec 2012 15:08:21 +0000 Received: from mail203-va3 (localhost [127.0.0.1]) by mail203-va3-R.bigfish.com (Postfix) with ESMTP id A22227C0152; Fri, 21 Dec 2012 15:08:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zzbb2dI98dI9371I542I1432I1418Izz1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h) Received: from mail203-va3 (localhost.localdomain [127.0.0.1]) by mail203-va3 (MessageSwitch) id 1356102500458378_1055; Fri, 21 Dec 2012 15:08:20 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.238]) by mail203-va3.bigfish.com (Postfix) with ESMTP id 66E7D620053; Fri, 21 Dec 2012 15:08:20 +0000 (UTC) Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Dec 2012 15:08:15 +0000 Received: from DB3PRD0210HT005.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 21 Dec 2012 15:08:14 +0000 Message-ID: <06cd01cddf8c$be231c80$4001a8c0@gateway.2wire.net> From: t.petch To: Jon Mitchell , Nick Hilliard References: <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net><50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org><020a01cddefc$dd1e5590$975b00b0$@ndzh.com><20121220223820.GA19458@puck.nether.net><50D3991B.2040809@foobar.org><027701cddf09$1d074d90$5715e8b0$@ndzh.com><50D44B5A.4080308@foobar.org> <20121221143408.GC8731@puck.nether.net> Date: Fri, 21 Dec 2012 15:06:17 +0000 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-Originating-IP: [157.56.253.69] X-OriginatorOrg: btconnect.com Cc: idr@ietf.org, Susan Hares Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:08:23 -0000 ----- Original Message ----- From: "Jon Mitchell" To: "Nick Hilliard" Cc: ; "Susan Hares" Sent: Friday, December 21, 2012 2:34 PM > On Fri, Dec 21, 2012 at 11:43:22AM +0000, Nick Hilliard wrote: > > On 20/12/2012 23:24, Susan Hares wrote: > > > I'd be interested in you suggesting the situations would be valid to leak > > > the AS private path AS to a peer, before we downgrade to a "SHOULD". > > > > the proposed text states: "If Private Use ASNs are used and prefixes are > > originated from these ASNs which are destined to the Internet, Private Use > > ASNs must be removed from the AS_PATH before being advertised to the global > > Internet." > > > > To start off, there's the usual problem: what do we mean when we talk about > > "the Internet"? > > Terminology seems clear as outside of the "single organization" context > to which Private Use is defined? This term is the same as in RFC 1930, > and I don't believe the leaks we see are due to semantic issues in that > document, nor future leaks will be based on mis-reading of this text. Since we are putting this under IANA, then I think that the relevant definition should not be RFC1930 but RFC5226 from which " Private Use - For private or local use only, with the type and purpose defined by the local site. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use)." from which I would expect removal to be implicit for most readers. I see no harm in including a MUST just to emphasize the point; and a reference to site would probably be better than to Internet. Tom Petch > > - operational people will happily ignore a MUST if they feel it suits their > > purpose at a specific time. > > This is always true even for protocol specifications, implementers can > choose to forgo being RFC compliant for their own reasons. At MUST it > will be obvious they are not in the right, if we soften it to should, > maybe the operators who ignore the SHOULD will say "the RFC didn't say I > MUST remove them" if asked to fix it? > > > - the Internet is a bunch of interconnected networks and what works for > > policy for one network peer might not work for another. > > Private Use by definition should be not be seen on the Internet, we are > still awaiting the case where it should be seen outside a single > organization. > > > - I don't not have the wisdom or the foresight to predict every eventuality > > where there might be legitimate reasons to forward a prefix with a private > > ASN over an ebgp peer. > > The draft doesn't say not to send to eBGP peers, just peers outside of > your organization. > > > - I suspect most private asn leaks we see in the DFZ are accidental, and > > MUST won't help in this situation. > > Nothing produced by IETF will help in this situation, however I think > IETF should specify what is the correct behavior. > > > - if this is specified as 2119-compatible MUST, vendors may be tempted to > > hardwire an AS path prefix filter for ebgp sessions into their code in a > > way which cannot be circumvented (in the same way that e.g. 169.254/16 is > > hardwired and cannot be used in a bgp NLRI). I'd see lots of value in > > having a vendor default of not forwarding private ASNs, but I think this > > could be quite harmful to have an absolute prohibition > > Since this is not a protocol specification, I think this is personally > unlikely. Given there is argueably (but not verifiably) many more > Private ASNs in use than Public ASNs, changing this default seems > unlikely. Given the impact of leaked private ASNs versus leaked RFC > 1918 space, and vendors not defaulting to not sending that, it would > seem unlikely this becomes a default. But whether or not it does or not > is not likely going to be due to the operational considerations section > of this RFC in my opinion. > > > Private ASN leaks are going to happen in two main circumstances: accidental > > and deliberate. I don't think that putting in "MUST" will actually deal > > with either. What's important from an operational point of view is getting > > vendors to implement a default but overrideable filter so that the bar for > > accidental leaks is raised to a sufficiently high point that accidental > > leaks are only going to happen when the safety nets are removed. > > I agree that nothing in this IETF draft will likely solve the leak > problem, however at least someone might point to it as an indication of > what is correct or not. > > > If we're going to make a statement on this one way or another, I think it > > should be along the lines of SHOULD rather than MUST, and that we should > > consider including a vendor hint to suggest that the default implementation > > behaviour would be to filter private asns. > > I don't think this draft nor this section is a good place to specify > vendor implementation behavior. This was meant to be guidance for > operators in use of Private ASNs. > > > > > This complicates issues slightly because we get into an issue of semantics: > > does the prefix get dropped? Or does the private ASN component get > > stripped from the AS path? > > Yes, if we take it out of operator control and into vendor > implementation guidance, these would become risks. > > > > > In term of specific situations where this might be useful, yeah, mergers > > and acquisitions would be one. Others might include private peering > > between ASN confederations. Or interconnections between the large number > > of private networks around the world, many of which use a mixture of > > private and public ASNs. Or test peerings. > > I think you are focusing on some possible vendor implementation that > doesn't exist that prevents Private Use ASN exchange over every eBGP > peering and is not configurable rather than the guidance to operators. > If ANY of these cases require routes to go to the global Internet, > Private Use ASNs MUST not be in the AS_PATH as the draft says. If > these use cases are not for routes that go to the global Internet, the > statment didn't apply in the first place. > > Jon > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From shares@ndzh.com Fri Dec 21 08:05:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A781B21F8711 for ; Fri, 21 Dec 2012 08:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVF4BObSih7Q for ; Fri, 21 Dec 2012 08:05:21 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED021F86A4 for ; Fri, 21 Dec 2012 08:05:21 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nick Hilliard'" References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> <50D44B5A.4080308@foobar.org> In-Reply-To: <50D44B5A.4080308@foobar.org> Date: Fri, 21 Dec 2012 11:05:03 -0500 Message-ID: <038301cddf94$f04303d0$d0c90b70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9Ai04lyEB39IjngGCNXspl+1U4NA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:05:22 -0000 Nick: Before I start, these are great questions. Before, I start, I must repeat John limited the discussion to the range comments. Please get your comments in often and early today on the range. ---------- Now, as to your questions... RFC 1930 says: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): I will address "global Internet" rather than the phrase "Internet". Many "fun" adventures in the past with BGP infrastructure have generally been found to be someone's leak or accident. Leaks/accidents if painful enough, will inspire code and operational changes. There tales of equally fun adventures within the private VPN or private DC space, but it is not the concern of RFC1930. I believe that operations people are smart. If they ignore "MUST" for private VPN or private DC, they must deal with the problems. If they wish to standardize it, they'll speak up. If operators want better knobs to handle private AS, operators will define it. If operators define knobs for private AS, it's a great topic to talk about in Grow or IDR. If they break the global Internet using private AS space, that's what RFC1930 is for and this draft modifies. Your stated cases match my understanding of our original discussions on RFC1930. Your reasons for deciding against rfc 6666 are interesting, I will re-read RFC 6666. As you've stated your reasons, I do not think the circumstances match either the original intent of RFC1930 or the intent of the "MUST" or "must" in the operational paragraph. Sue -----Original Message----- From: Nick Hilliard [mailto:nick@foobar.org] Sent: Friday, December 21, 2012 6:43 AM To: Susan Hares Cc: 'Jon Mitchell'; idr@ietf.org; stbryant@cisco.com Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 On 20/12/2012 23:24, Susan Hares wrote: > I'd be interested in you suggesting the situations would be valid to > leak the AS private path AS to a peer, before we downgrade to a "SHOULD". the proposed text states: "If Private Use ASNs are used and prefixes are originated from these ASNs which are destined to the Internet, Private Use ASNs must be removed from the AS_PATH before being advertised to the global Internet." To start off, there's the usual problem: what do we mean when we talk about "the Internet"? In fact there's more to the situation. We're dealing with operational stuff here rather than protocol specification, i.e. human behaviour rather than computer specifications. I'd have no problem with throwing "MUST" around when dealing with protocol handling, but when it gets to operational stuff, I would be a lot more circumspect for several reasons: - operational people will happily ignore a MUST if they feel it suits their purpose at a specific time. - the Internet is a bunch of interconnected networks and what works for policy for one network peer might not work for another. - I don't not have the wisdom or the foresight to predict every eventuality where there might be legitimate reasons to forward a prefix with a private ASN over an ebgp peer. - I suspect most private asn leaks we see in the DFZ are accidental, and MUST won't help in this situation. - if this is specified as 2119-compatible MUST, vendors may be tempted to hardwire an AS path prefix filter for ebgp sessions into their code in a way which cannot be circumvented (in the same way that e.g. 169.254/16 is hardwired and cannot be used in a bgp NLRI). I'd see lots of value in having a vendor default of not forwarding private ASNs, but I think this could be quite harmful to have an absolute prohibition Private ASN leaks are going to happen in two main circumstances: accidental and deliberate. I don't think that putting in "MUST" will actually deal with either. What's important from an operational point of view is getting vendors to implement a default but overrideable filter so that the bar for accidental leaks is raised to a sufficiently high point that accidental leaks are only going to happen when the safety nets are removed. If we're going to make a statement on this one way or another, I think it should be along the lines of SHOULD rather than MUST, and that we should consider including a vendor hint to suggest that the default implementation behaviour would be to filter private asns. This complicates issues slightly because we get into an issue of semantics: does the prefix get dropped? Or does the private ASN component get stripped from the AS path? In term of specific situations where this might be useful, yeah, mergers and acquisitions would be one. Others might include private peering between ASN confederations. Or interconnections between the large number of private networks around the world, many of which use a mixture of private and public ASNs. Or test peerings. Anyway, these were some of the issues that cropped up during the WG discussion phase for rfc 6666. We eventually decided to go with the idea of making a recommendation that the prefix shouldn't be transferred over ebgp sessions, and specifically made the point in the security section to highlight it. This avoided the issue of defining "the Internet", while encapsulating what we wanted to say in the way that we wanted to say it. Nick From jsw@inconcepts.biz Fri Dec 21 09:22:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E806921F8AB8 for ; Fri, 21 Dec 2012 09:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO-41m-NgkDk for ; Fri, 21 Dec 2012 09:22:21 -0800 (PST) Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6E21F8AA3 for ; Fri, 21 Dec 2012 09:22:21 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id k25so4198346iah.9 for ; Fri, 21 Dec 2012 09:22:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CBxqXGYUXIOk8N99IE44x5gTI++AUWMmAoRku/bf31c=; b=U7P3PbIZjoKrya3Srv3GgRvp6DPGSIMqf9t+UN43QB8RO9JRVtvjkZMPiwDxOuJuk7 z5LqzoBhz311c7yAHoXMQ2tL66lCrFWx4IhhUn7iLr5KatrVbd9LzY9snLpoeGibDlSu NZnQ1vncdqJzQSIimPv02arZWkjyM8YKoQSixMfGLUjHknEpz4Fa24vgl2k5vMG+qIkW SBnpme/EChoreLlimTPj4h4FMZ0bRTuo4ObdPTrDbtCyV+plF5y5B3p69fkA+oMEROkc Ub9s2ZOlwQBYSMek64RxaMiQq79rTBuzBenGF/93MqJ+HzFG0Hk7YB6Ue0S0FTTqwDNM /hfQ== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr14153841igb.45.1356110540715; Fri, 21 Dec 2012 09:22:20 -0800 (PST) Received: by 10.64.132.33 with HTTP; Fri, 21 Dec 2012 09:22:20 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20121221140551.GB8731@puck.nether.net> References: <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> <20121221140551.GB8731@puck.nether.net> Date: Fri, 21 Dec 2012 12:22:20 -0500 Message-ID: From: Jeff Wheeler To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnaIeHmlFwROyZfsq9ZJr0cieMVmXWpfmjuZg33G+vFBpJnb81t9IDpcMGL24dTUgAQtIKI Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:22:22 -0000 On Fri, Dec 21, 2012 at 9:05 AM, Jon Mitchell wrote: > Isn't this like asking why folks leak RFC 1918 space into the global > routing table, /32's into the routing table, etc... ? Mis-configuration > seems obvious, but I don't think a poll is a fruitful exercise. Haven't we asked if there is ever likely to be a reason for intentionally leaking private ASNs to the "Internet?" If it's useful to know that information, it seems illogical not to ask if anyone is doing it intentionally today, and if they are, why? nLayer is doing this. If you want to know if it's a mistake or intentional, I'm sure they will answer. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From internet-drafts@ietf.org Fri Dec 21 12:43:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F15021F88B0; Fri, 21 Dec 2012 12:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoag5VMdbSYm; Fri, 21 Dec 2012 12:43:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909FE21F87DF; Fri, 21 Dec 2012 12:43:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121221204308.22088.98183.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2012 12:43:08 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-private-reservation-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 20:43:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Autonomous System (AS) Reservation for Private Use Author(s) : Jon Mitchell Filename : draft-ietf-idr-as-private-reservation-02.txt Pages : 5 Date : 2012-12-21 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as-private-reservation-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jgs@juniper.net Fri Dec 21 13:36:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760821F87C6 for ; Fri, 21 Dec 2012 13:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a247BNrjl1ac for ; Fri, 21 Dec 2012 13:36:19 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1921F85AB for ; Fri, 21 Dec 2012 13:36:19 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUNTWU5E0uG4hsGIHFEnofh6HQkHEerEJ@postini.com; Fri, 21 Dec 2012 13:36:19 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Dec 2012 13:34:48 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Dec 2012 13:34:48 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Dec 2012 13:37:38 -0800 Received: from mail80-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE021.bigfish.com (10.3.207.143) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Dec 2012 21:34:45 +0000 Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id B5B8B46014C for ; Fri, 21 Dec 2012 21:34:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz98dI9371Ic85fh1432I4015Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275chz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 1356125683694387_4070; Fri, 21 Dec 2012 21:34:43 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.251]) by mail80-am1.bigfish.com (Postfix) with ESMTP id A70A9E0048; Fri, 21 Dec 2012 21:34:43 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Dec 2012 21:34:42 +0000 Received: from alexg-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.243.34) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 21 Dec 2012 21:34:34 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_6603C625-4CB5-4FA2-9CA3-803DFB63EA84" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "John G. Scudder" In-Reply-To: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> Date: Fri, 21 Dec 2012 16:34:31 -0500 Message-ID: References: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.53] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: draft-svshah-interdomain-sla-exchange@tools.ietf.org Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:36:20 -0000 --Apple-Mail=_6603C625-4CB5-4FA2-9CA3-803DFB63EA84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" The document is adopted as an IDR WG draft. Authors, please resubmit as = draft-ietf-idr-interdomain-sla-exchange-00. --John On Dec 6, 2012, at 5:39 PM, John Scudder wrote: > Folks, >=20 > The authors have requested IDR adopt = draft-svshah-interdomain-sla-exchange-03 as a working group document. >=20 > Please send any comments to the list by the Winter Solstice (December = 21). >=20 > Thanks, >=20 > --John --Apple-Mail=_6603C625-4CB5-4FA2-9CA3-803DFB63EA84 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" The document is adopted as an IDR WG draft. Authors, please resubmit as draft-ietf-idr-interdomain-sla-exchange-00.

--John

On Dec 6, 2012, at 5:39 PM, John Scudder <jgs@juniper.net> wrote:

Folks,

The authors have requested IDR adopt draft-svshah-interdomain-sla-exchange-03 as a working group document.

Please send any comments to the list by the Winter Solstice (December 21).

Thanks,

--John

--Apple-Mail=_6603C625-4CB5-4FA2-9CA3-803DFB63EA84-- From jgs@juniper.net Fri Dec 21 14:37:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A267621F87DF for ; Fri, 21 Dec 2012 14:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1h0RjzbyQ-o for ; Fri, 21 Dec 2012 14:37:59 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9CF21F8583 for ; Fri, 21 Dec 2012 14:37:59 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUNTkxqwLTMTbqq56P8qNK3wuvkTt6Wv1@postini.com; Fri, 21 Dec 2012 14:37:59 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Dec 2012 14:36:13 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Dec 2012 14:36:13 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Dec 2012 14:39:03 -0800 Received: from mail90-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Dec 2012 22:36:12 +0000 Received: from mail90-va3 (localhost [127.0.0.1]) by mail90-va3-R.bigfish.com (Postfix) with ESMTP id D2A3C36010B for ; Fri, 21 Dec 2012 22:36:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zz4015Izz1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1155h) Received: from mail90-va3 (localhost.localdomain [127.0.0.1]) by mail90-va3 (MessageSwitch) id 1356129370441475_26345; Fri, 21 Dec 2012 22:36:10 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.243]) by mail90-va3.bigfish.com (Postfix) with ESMTP id 6786F3400A3 for ; Fri, 21 Dec 2012 22:36:10 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Dec 2012 22:36:10 +0000 Received: from alexg-sslvpn-nc.jnpr.net (66.129.224.54) by pod51010.outlook.com (10.255.243.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 21 Dec 2012 22:36:08 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 21 Dec 2012 17:36:05 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "idr@ietf. org" X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.54] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 22:37:59 -0000 Folks, The extended (and epic) IDR WGLC period is completed. On the question of = the range to use, there was consensus that, although various other = personal favorites were discussed, 4200000000+ is good enough. However, before we send it to the IESG we've asked GROW and SIDR to take = a look too. In hindsight, we should've done those concurrently, but = that's how it goes. (And actually, this does allow us to send them a = document that's had the benefit of review and revision.) I do note that a few other editorial suggestions were made during this = last week. These seem to Sue and me to be things that can be handled in = the editing process. Thanks, --John and Sue= From ras@gerbil.cluepon.net Sat Dec 22 00:53:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BC621F8B11 for ; Sat, 22 Dec 2012 00:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDB1QRWZW3-u for ; Sat, 22 Dec 2012 00:53:15 -0800 (PST) Received: from gerbil.cluepon.net (cluepon.net [204.93.176.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA1021F8B0A for ; Sat, 22 Dec 2012 00:53:15 -0800 (PST) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.4/8.14.4) with ESMTP id qBM8rEDZ073569; Sat, 22 Dec 2012 02:53:14 -0600 (CST) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.5/8.14.4/Submit) id qBM8rEwx073568; Sat, 22 Dec 2012 02:53:14 -0600 (CST) (envelope-from ras) Date: Sat, 22 Dec 2012 02:53:14 -0600 From: Richard A Steenbergen To: Jeff Wheeler Message-ID: <20121222085314.GA65604@gerbil.cluepon.net> References: <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <027701cddf09$1d074d90$5715e8b0$@ndzh.com> <20121221140551.GB8731@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 08:53:16 -0000 On Fri, Dec 21, 2012 at 12:22:20PM -0500, Jeff Wheeler wrote: > On Fri, Dec 21, 2012 at 9:05 AM, Jon Mitchell wrote: > > Isn't this like asking why folks leak RFC 1918 space into the global > > routing table, /32's into the routing table, etc... ? Mis-configuration > > seems obvious, but I don't think a poll is a fruitful exercise. > > Haven't we asked if there is ever likely to be a reason for > intentionally leaking private ASNs to the "Internet?" If it's useful > to know that information, it seems illogical not to ask if anyone is > doing it intentionally today, and if they are, why? > > nLayer is doing this. If you want to know if it's a mistake or > intentional, I'm sure they will answer. I think you're confused, nLayer has never intentionally leaked private ASNs to the Internet. If this ever happens, it is because of the very limited toolset available to manipulate AS-PATHs on routers (i.e. there are plenty of ways that "remove-private" will fail to strip every private ASN). Of course, the negative impact of leaking private ASNs to the Internet is pretty darn minimal, so this issue doesn't really make my list of things I care about. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From russw@riw.us Mon Dec 24 05:03:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7ED21F8673 for ; Mon, 24 Dec 2012 05:03:37 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fm5fqUNs0O9 for ; Mon, 24 Dec 2012 05:03:37 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06621F84FB for ; Mon, 24 Dec 2012 05:03:37 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tn7gu-0001ij-7A for idr@ietf.org; Mon, 24 Dec 2012 05:03:36 -0800 Message-ID: <50D852A3.8070206@riw.us> Date: Mon, 24 Dec 2012 08:03:31 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr@ietf.org References: <50CF64A3.8060208@cisco.com> In-Reply-To: <50CF64A3.8060208@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [Idr] draft-ietf-karp-routing-tcp-analysis review requested X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 13:03:37 -0000 > I would appreciate feedback from anyone in the WG, but it would be > helpful if the WG Chairs could nominate at least one person to review > the draft on behalf of the WG. Some thoughts below: == Those that use TCP as a transport protocol use access lists to accept packets only from known sources. These access lists also help protect edge routers from attacks originating outside the protected domain. In addition, for edge routers running eBGP, TCP LISTEN is run only on interfaces on which its peers have been discovered or via which routing sessions are expected (as specified in router configuration databases). Not all routers actually do run access lists –but they may run access lists for protection. This wording might need a little clarification, perhaps: “Those that use TCP as a transport protocol may use access lists to protect…” The second part here, about TCP LISTEN, I didn’t really understand. Why should TCP LISTEN be run on eBGP speakers where peers have already been discovered? There is no discovery process in BGP, so I’m not certain what this section is supposed to mean. == Generalized TTL Security Mechanism (GTSM) [RFC5082] describes a generalized Time to Live (TTL) security mechanism to protect a… I think this needs to be preceded with a “The.” == Even when BGP, LDP, PCEP and MSDP sessions use access lists, they are vulnerable to spoofing and man in the middle attacks. There’s something of a flow problem here… You begin talking about access lists, then provide some short sentences on GTSM and TCP robustness, then you continue here discussing cryptographic methods as if the intervening paragraph didn’t exist. It’s a bit confusing –I would suggest either generalizing the initial sentence here, or moving things around so the two references to access list are in one place. == TCP MD5 does not provide a generic mechanism to support key roll-over. The Message Authentication Codes (MACs) used by TCP MD5 option, is considered too weak both because of the use of the hash function and because of the way the secret key used by TCP MD5 is managed. This section seems a little rough… There is the mention of the lack of support for key rollover –which I take to be related to the management of the secret key, but the two don’t appear to be connected in the text. The second problem, the weakness of the hash function, isn’t well explained, nor supported by outside references. Some beefing up here might be useful. == It is well known that the longer the same key is used, the greater the chance that it can be guessed or exposed e.g. when an administrator with knowledge of the keys leaves the company. Another threat that could be mentioned here is the longer a key is used, the more material and time an attacker has to break that key through computational means. == HTH Russ -- <>< riwhite@verisign.com russw@riw.us From internet-drafts@ietf.org Mon Dec 24 06:20:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A2321F8927; Mon, 24 Dec 2012 06:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIbx8EhCfpMZ; Mon, 24 Dec 2012 06:20:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED4821F862A; Mon, 24 Dec 2012 06:20:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121224142044.30993.16364.idtracker@ietfa.amsl.com> Date: Mon, 24 Dec 2012 06:20:44 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 14:20:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-04.txt Pages : 5 Date : 2012-12-24 Abstract: The BGP specificatanyion mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-extended-messages-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Dec 24 13:38:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C425521F873C; Mon, 24 Dec 2012 13:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2KvMK+25fnE; Mon, 24 Dec 2012 13:38:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AFC21F8456; Mon, 24 Dec 2012 13:38:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121224213847.18871.95792.idtracker@ietfa.amsl.com> Date: Mon, 24 Dec 2012 13:38:47 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 21:38:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-05.txt Pages : 5 Date : 2012-12-24 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-extended-messages-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rjs@rob.sh Thu Dec 27 10:44:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3975921F863F for ; Thu, 27 Dec 2012 10:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9rZdEVP2WS3 for ; Thu, 27 Dec 2012 10:44:30 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 835E321F8609 for ; Thu, 27 Dec 2012 10:44:30 -0800 (PST) Received: from [46.65.174.227] (helo=latte.munster) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1ToIOO-0001dT-Im for idr@ietf.org; Thu, 27 Dec 2012 18:41:20 +0000 From: Rob Shakir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Dec 2012 18:44:28 +0000 References: To: idr@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 18:44:31 -0000 Hi IDR! FYI -- please find an updated relating to a new version of = draft-ietf-grow-ops-reqs-for-bgp-error-handling. Any comments very welcome (to me or grow@). Seasons greetings! r. Begin forwarded message: > From: > Subject: Re: [GROW] I-D Action: = draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt > Date: 27 December 2012 18:41:50 GMT > To: , > Cc: grow@ietf.org >=20 > On 27/12/2012 18:35, "internet-drafts@ietf.org" = > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Global Routing Operations Working = Group >> of the IETF. >>=20 >> Title : Operational Requirements for Enhanced Error = Handling >> Behaviour in BGP-4 >> Author(s) : Rob Shakir >> Filename : = draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt >> Pages : 19 >> Date : 2012-12-27 >=20 > Hi GROW! >=20 > This update is a fairly major re-spin of the BGP Error Handling > requirements draft. The technical content should be as per the = previous > revisions however, following the ietf/RtgDir last call comments, I = have > made the following changes: >=20 > * Made the amendments that were discussed and there was no = disagreement > with from our meeting in Atlanta -- this is essentially renaming the > Critical/Semantic error types to Critical/Non-Critical. >=20 > * Significant de-duplication within the text including merging the > operational monitoring/toolset discussions into the error handling > sections. >=20 > * Adoption of rfc2119 language throughout to clarify the requirements. >=20 > * Removal of some of the discussion around more detailed = justifications > for why particular decisions were made. I think this was useful = through > the discussion phase of this draft, but it seems like GROW/IDR have > converged on a relatively stable set of requirements, so I have = trimmed > back some of this discussion. >=20 > I'd really welcome any further comments on this before we re-submit = for > publication. To eke these out - Peter/Chris - can you kick off a WGLC = for > this draft please? :-) >=20 > Seasons greetings! > r. >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From rjs@rob.sh Fri Dec 28 05:10:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206AF21F8609; Fri, 28 Dec 2012 05:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=-2.476, BAYES_00=-2.599, GB_SUMOF=5, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGiQ4Myuwey2; Fri, 28 Dec 2012 05:10:07 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 4110121F88F1; Fri, 28 Dec 2012 05:10:06 -0800 (PST) Received: from [46.65.174.227] (helo=latte.munster) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1ToZeK-00072O-BL; Fri, 28 Dec 2012 13:06:56 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <025801cde4f6$d7783700$8668a500$@highwayman.com> Date: Fri, 28 Dec 2012 13:10:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> To: "Chris Hall" X-Mailer: Apple Mail (2.1283) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 13:10:08 -0000 Hi Chris, (re: CCing IDR & GROW) On 28 Dec 2012, at 12:28, Chris Hall wrote: > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44): >>=20 >> Any comments very welcome (to me or grow@). >=20 > I'm afraid I still don't get it :-( What am I missing ? >=20 > UPDATE Message Length errors are Critical because they (1) "result in > cases whereby the NLRI attribute cannot be correctly extracted". >=20 > The implication is that a failure to extract all NLRI is Critical. Is > that a requirement ? If the NLRI cannot be determined, then this is a Critical error, yes. I = left the wording relatively open on whether this is *all* NLRI, as I am = not sure that in the requirements draft we should specify direct = solutions to specific issues, to e.g., say how to handle cases where = MP_REACH_NLRI and MP_UNREACH_NLRI are in the same message [this is a = case that I do not believe is forbidden by rfc2858 - if the working = group could clarify whether this is something that we feel the draft = needs to handle or can explicitly be omitted, then that would be = appreciated]. >=20 > Later:=20 >=20 > (2) "All errors whereby the contained NLRI can be > extracted are referred to as Non-Critical".=20 >=20 > And that includes: >=20 > (3) "where the length of all path attributes contained > within the UPDATE does not correspond to the > total path attribute length." >=20 > That is, at least, more explicit than > draft-ietf-idr-error-handling-03, which glosses over (3). >=20 > But if (3) is non-critical then there is some chance that some NLRI > will not be extracted, which appears to violate (1) and (2). Disclaimer: As I am sure that my comments previously have made clear, I = do not maintain a code base for a BGP daemon/implementation - so please = feel free to correct my logic below. I do not believe that (3) implies that the NLRI cannot be correctly = found. If the sum of total length is incorrect, then we can still = extract the individual attributes - we just find that there is not = enough data to fill the overall length we were told and/or we have too = much attribute data compared to the total attribute length. In the case = where the NLRI attribute itself has a length error, then this is a = critical error (based on the "Errors parsing the NLRI attribute of an = UPDATE message" definition of Critical error), and a similar Critical = error occurs in the latter case, where the Total Path Attributes + = Withdrawn Routes are not equal to total UPDATE message length. Either way -- again, I would say that this is something that we need to = put text together for draft-ietf-idr-error-handling rather than the = requirements document (this sounds like a solution, and the requirement = does not have a SHOULD or MUST here, it is an "it is expected that=85" = comment). > Then (4) "In order to maximise the number of cases whereby the NLRI > attributes [plural, now, BTW] can be reliably extracted from a > received message...". Ah. So it is not a Critical Error if "the NLRI > attribute cannot be correctly extracted". No - it is a Critical error if we cannot extract the NLRI. This = recommendation is to give an increased chance that the NLRI can be = extracted as per the IDR error handling draft. This then (by virtue of = resulting in the NLRI being extracted) minimises the number of cases = that result in a Critical error. The plural here is to reflect that the = existence of >1 type of NLRI attribute. > For me the requirement remains "conflicted". On the one hand it seems > to say that it is a Critical Error if the NLRI cannot be extracted and > parsed. On the other it seems to say it's OK if you cannot extract > some NLRI. If you'll forgive me for removing a significant proportion of your = message, I think that we need to take another step back here. It seems = to me that the key question that you are highlighting is "What level of = confidence do we need to have before we declare that the NLRI cannot be = extracted?" -- do you agree? =46rom an operator perspective, I would like to compromise *certainty* = for *robustness*. You are right, we are compromising correctness here, = we might end up withdrawing an incorrect NLRI and impacting service = operation for that prefix - however, it is somewhat preferable to me to = withdraw a a subset of the NLRI incorrectly, rather than impact all NLRI = in one single action. We clearly need to provide some bounds on how much = we compromise the certainty (and live within the realms of possibility, = such that we are not just taking a shot in the dark). This is what the = definitions of Critical and Non-Critical within the document are = intended to provide. Once again I will refer to the requirement that = there is a balance between correctness and robustness - rather than a = locally risk averse approach that results in harmful wider behaviour. Is it acceptable that we leave this as guidance within the requirements? = If not, please could you suggest how the definitions of = Critical/Non-Critical could be altered to address your concerns? I would = also appreciate further input from IDR as to whether this is sufficient = requirement from GROW to allow a solution document to be written? Many thanks, r. From chris.hall@highwayman.com Fri Dec 28 10:04:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD221F8BC9; Fri, 28 Dec 2012 10:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.874 X-Spam-Level: ** X-Spam-Status: No, score=2.874 tagged_above=-999 required=5 tests=[AWL=-2.414, BAYES_00=-2.599, GB_SUMOF=5, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_23=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsCChMzzEC3Q; Fri, 28 Dec 2012 10:04:22 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta010.mxout.tch.inty.net [91.221.169.51]) by ietfa.amsl.com (Postfix) with ESMTP id F27F121F8923; Fri, 28 Dec 2012 10:04:17 -0800 (PST) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id 5EFB9400594; Fri, 28 Dec 2012 18:04:16 +0000 (GMT) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id 29CE8400590; Fri, 28 Dec 2012 18:04:16 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tch.inty.net (Postfix) with ESMTP; Fri, 28 Dec 2012 18:04:15 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ToeI2-0000vV-S7; Fri, 28 Dec 2012 18:04:14 +0000 From: "Chris Hall" To: "'Rob Shakir'" References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> In-Reply-To: <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> Date: Fri, 28 Dec 2012 18:04:09 -0000 Organization: Highwayman Message-ID: <028701cde525$bf262070$3d726150$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFuOjybZ81Jyr3vkBQVN4QFzf3TcAHhILBDmN6LQYA= Content-Language: en-gb X-MDF-HostID: 19 Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 18:04:23 -0000 Rob Shakir wrote (on Fri 28-Dec-2012 at 13:10 +0000): > > (re: CCing IDR & GROW) > > On 28 Dec 2012, at 12:28, Chris Hall wrote: > > > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44): > >> > >> Any comments very welcome (to me or grow@). > > I'm afraid I still don't get it :-( What am I missing ? > > > > UPDATE Message Length errors are Critical because they: > > > > (1) "result in cases whereby the NLRI attribute cannot > > be correctly extracted". > > > > The implication is that a failure to extract all NLRI is Critical. > > Is that a requirement ? > If the NLRI cannot be determined, then this is a Critical error, > yes. I left the wording relatively open on whether this is *all* > NLRI, ... OK. So, if the message is broken (in any way): * if no NLRI can be found, that's a Critical Error. That would include the case where some broken attribute upstream of any MP_XXX obscures that MP_XXX. * if some NLRI can be found, that's a Non-Critical error. Such NLRI as can be found are treated-as-withdraw. AND any NLRI that may or may not have been lost, are ignored. AND whatever dangers lost NLRI may pose are covered by the caveats in 4.1. Yes ? > ... as I am not sure that in the requirements draft we should > specify direct solutions to specific issues, to e.g., say how to > handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > message [this is a case that I do not believe is forbidden by > rfc2858 - if the working group could clarify whether this is > something that we feel the draft needs to handle or can explicitly > be omitted, then that would be appreciated]. The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in the body of the message, with or without MP_REACH_NLRI and/or MP_UNREACH_NLRI. If we call each of these a "collection of NLRI", then there may be between 1 and 4 collections of NLRI in a message (ignoring the End-of-RIB pseudo-UPDATE). It is an error to have more than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI attribute. It is not clear to me whether those should be Critical Errors -- but while we are relaxing all error checking, I don't see why they should be. It is possible that most implementations actually only send one collection per message... so, as you suggest, on a you-know-and-I-know basis, we'all could ignore the "theoretical" issues of more than one collection in a message. But, this does not matter if the requirements allow lost NLRI to simply be ignored. If the sender sends any MP_XXX first, then there is little chance that NLRI will be lost, and things work better. If the sender follows the old rules, and particularly if it sends more than one collection at a time, then there is more chance that NLRI will be lost. > > Later: > > > > (2) "All errors whereby the contained NLRI can be > > extracted are referred to as Non-Critical". > > > > And that includes: > > > > (3) "where the length of all path attributes contained > > within the UPDATE does not correspond to the > > total path attribute length." > > > > That is, at least, more explicit than > > draft-ietf-idr-error-handling-03, which glosses over (3). > > > > But if (3) is non-critical then there is some chance that > > some NLRI will not be extracted, which appears to violate > > (1) and (2). > Disclaimer: As I am sure that my comments previously have made > clear, I do not maintain a code base for a BGP daemon/implementation > - so please feel free to correct my logic below. > > I do not believe that (3) implies that the NLRI cannot be correctly > found. What (3) implies to me is that somewhere amongst the attributes something is broken. As Jakob Heitz succinctly puts it: "Once you have a malformed update, NOTHING is certain." In particular, you cannot be certain that all NLRI referred to by the sender can be found by the receiver. > If the sum of total length is incorrect, then we can still > extract the individual attributes - we just find that there is not > enough data to fill the overall length we were told and/or we have > too much attribute data compared to the total attribute length. This is precisely where I think the requirements come unstuck. There is almost no redundancy in the attribute encoding. And almost all the redundancy there is is discarded by the new-form-error-handling. So, if the sum of the attribute lengths is incorrect, then (inter alia) the receiver CANNOT know whether the attributes it has extracted are the attributes the sender intended to send. In particular, the receiver cannot know it has extracted all NLRI (except in the, probably obscure, case of having extracted both MP_REACH_NLRI and MP_UNREACH_NLRI). "Once you have a malformed update, NOTHING is certain." Conversely, if the sum of attribute lengths is correct, then there is a fighting chance that the attributes received are the attributes sent. But, if one of those attributes is (say) nominally an ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a worry. ... > > Then (4) "In order to maximise the number of cases whereby the > > NLRI attributes [plural, now, BTW] can be reliably extracted > > from a received message...". Ah. So it is not a Critical > > Error if "the NLRI attribute cannot be correctly extracted". > No - it is a Critical error if we cannot extract the NLRI. This > recommendation is to give an increased chance that the NLRI can be > extracted as per the IDR error handling draft. This then (by virtue > of resulting in the NLRI being extracted) minimises the number of > cases that result in a Critical error. By this do you mean "all" NLRI or only "some" NLRI ? As above. > The plural here is to reflect > that the existence of >1 type of NLRI attribute. That would imply that it should be "NLRI attributes" throughout ? Though in most places where the draft speaks of "NLRI attribute" I think it means one, some, any or all of the "collections of NLRI" (as defined above). > > For me the requirement remains "conflicted". On the one hand it > > seems to say that it is a Critical Error if the NLRI cannot be > > extracted and parsed. On the other it seems to say it's OK if > > you cannot extract some NLRI. > If you'll forgive me for removing a significant proportion of your > message, I think that we need to take another step back here. It > seems to me that the key question that you are highlighting is "What > level of confidence do we need to have before we declare that the > NLRI cannot be extracted?" -- do you agree? Absolutely. > From an operator perspective, I would like to compromise *certainty* > for *robustness*. You are right, we are compromising correctness > here, we might end up withdrawing an incorrect NLRI and impacting > service operation for that prefix - however, it is somewhat > preferable to me to withdraw a a subset of the NLRI incorrectly, > rather than impact all NLRI in one single action. We clearly need to > provide some bounds on how much we compromise the certainty (and > live within the realms of possibility, such that we are not just > taking a shot in the dark). This is what the definitions of Critical > and Non-Critical within the document are intended to provide. Once > again I will refer to the requirement that there is a balance > between correctness and robustness - rather than a locally risk > averse approach that results in harmful wider behaviour. Where one can extract the NLRI from a broken message, then treat-as-withdraw is AFAICS no worse for the NLRI in question than session-reset, and hugely better for all the other NLRI received from the peer. Where not *all* the NLRI in a message have been extracted, then we take a step beyond withdrawing something which should not have been withdrawn. For each of those NLRI the receiver will (unknowingly) do one of: (a) continue using a route which the sender has withdrawn; (b) continue to use an out of date version of a route which the sender has changed in some way, possibly materially; (c) to fail to use a new route the sender has now made available. Of these (a) looks serious and (b) could be, but certainly the effect is different from session-reset; while (c) is, essentially, treat-as-withdraw. If some risk "lost routes" is taken, then the impact of that clearly must be weighed against the impact of session-reset. I have not found a discussion of the impact of "lost routes" in the draft, so I have no idea what the trade-off is, here. For completeness, if all forms and degrees of attribute broken-ness are required to be acceptable, then there are cases where the receiver cannot know whether *all* NLRI have been extracted, or not. > Is it acceptable that we leave this as guidance within the > requirements? If not, please could you suggest how the definitions > of Critical/Non-Critical could be altered to address your concerns? Without a change at the sender end, the problem is that: "Once you have a malformed update, NOTHING is certain." So, as I said earlier, the fundamental question is: (F) is it OK to continue with a session after processing a message which may have contained some NLRI which could not be extracted ? As you say, the question hinges on the "which may have contained". As above, it seems to me that the draft skates over the issue of "lost routes". It also hinges on the operational impact of such "lost routes", on which I am unqualified to pronounce. It seems to me there is a range of possibilities: 1) at one end of the spectrum, if "lost routes" are to be avoided at all costs, then the rules for parsing attributes need to be tight and without a change at the sender end, what is achievable is constrained. 2) if "lost routes" are acceptable in the "theoretical" cases, but you-know-and-I-know that most of the time the case will not arise... ...or "lost routes" are acceptable provided some defined steps are taken to identify as much NLRI as is reasonably possible... ...then the requirements need to (a) make the case and (b) describe the trade-off (so that designs made to follow the requirements can be judged in those terms). 3) at the other end of the spectrum, if "lost routes" are always preferable to session-reset, then this opens up an even looser approach to UPDATE message handling, in which practically nothing need cause a session-reset -- ie, practically nothing is a Critical Error. And, as I have suggested in previous discussions, it is possible to consider case (2) in two parts: a) where the sender is unchanged. In which case the issue is the degree of attribute broken-ness vs the likelihood of "lost routes". If this is viewed as an intermediate step, then perhaps the requirements could err on the side of safety ? Perhaps this can be addressed by a "knob" allowing more or less strictness in the parsing of attributes ? b) where the sender is changed. In which case the issue ought to be moot, because the receiver will then be able to know that there are no "lost routes". > I would also appreciate further input from IDR as to whether this is > sufficient requirement from GROW to allow a solution document to be > written? The new requirements specify only Critical (session-reset) and Non-Critical (treat-as-withdraw) Errors. This appears to rule out the "attribute discard" option in draft-ietf-idr-error-handling-03. Is that intended ? Chris From brian.peter.dickson@gmail.com Fri Dec 28 11:02:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97D321F8E08; Fri, 28 Dec 2012 11:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=-2.675, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdzDJeWDE6Oy; Fri, 28 Dec 2012 11:02:25 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 609D321F8E07; Fri, 28 Dec 2012 11:02:24 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id d49so5251499eek.18 for ; Fri, 28 Dec 2012 11:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QO66L9RP0qeN8is3o5XU+MOtDvQRZzGqO7F5d6q24Co=; b=m+fJvs3K2/I/63jqKXNsPYs5syHvDLu1j6Vry74TPeX2yCov5OdY781ApN9YOPaVW1 zg4e/Tvboj6DLRWFI756XDYg+nOyPrD448Y0f+K1OogzAlyvTg1Dbpy1Dv5rHfwte+h5 6/yyw5ctb14slwPH9Q55/1LQ85ZPcP/o5bYXiyHZlh0ulEZb02cojVIZQMjxNy51ClIw Rpkdnyindt4cJSaiqVfnkzNkRaeZpaFyL9NaB/ImFEgqDWuu67tIxCF5876n2dINTi3m QHS3nFgO0JECcxVvSFJCjBnQbITJqHnSRUlTnHs/x2KIQqXp0Pe5RypeYbYQruD7k4BT o9Qw== MIME-Version: 1.0 Received: by 10.14.225.194 with SMTP id z42mr88628745eep.22.1356721343446; Fri, 28 Dec 2012 11:02:23 -0800 (PST) Received: by 10.223.173.199 with HTTP; Fri, 28 Dec 2012 11:02:23 -0800 (PST) In-Reply-To: <028701cde525$bf262070$3d726150$@highwayman.com> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> Date: Fri, 28 Dec 2012 14:02:23 -0500 Message-ID: From: Brian Dickson To: Chris Hall Content-Type: multipart/alternative; boundary=047d7b66f24bbc3cc104d1ee4d5f Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 19:02:27 -0000 --047d7b66f24bbc3cc104d1ee4d5f Content-Type: text/plain; charset=ISO-8859-1 Here's a quick question, about possible mechanisms for determining whether or not we need to tear down a session. If there is a chance that some NLRI weren't properly decoded: - What about requesting (presuming the option was negotiated) a route-refresh, or a "confirm per-AFI-SAFI prefix list"? It's an expensive "parity check" but is one way of ensuring that we haven't missed a withdrawn prefix. If it isn't in the subsequently received list of prefixes, we missed it and should withdraw it. Everything else is a no-op - maybe we missed a new prefix (with new attribute?), but that is what "treat as withdraw" gets you. Just trying to make sure the cure isn't worse than the disease, in all situations. (Where "cure" is fail to withdraw because we "lost" the withdrawal because of malformed update, or "cure" is tear down the session.) Brian On Fri, Dec 28, 2012 at 1:04 PM, Chris Hall wrote: > Rob Shakir wrote (on Fri 28-Dec-2012 at 13:10 +0000): > > > > (re: CCing IDR & GROW) > > > > On 28 Dec 2012, at 12:28, Chris Hall wrote: > > > > > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44): > > >> > > >> Any comments very welcome (to me or grow@). > > > > I'm afraid I still don't get it :-( What am I missing ? > > > > > > UPDATE Message Length errors are Critical because they: > > > > > > (1) "result in cases whereby the NLRI attribute cannot > > > be correctly extracted". > > > > > > The implication is that a failure to extract all NLRI is Critical. > > > Is that a requirement ? > > > If the NLRI cannot be determined, then this is a Critical error, > > yes. I left the wording relatively open on whether this is *all* > > NLRI, ... > > OK. So, if the message is broken (in any way): > > * if no NLRI can be found, that's a Critical Error. > > That would include the case where some broken > attribute upstream of any MP_XXX obscures that > MP_XXX. > > * if some NLRI can be found, that's a Non-Critical error. > > Such NLRI as can be found are treated-as-withdraw. > > AND any NLRI that may or may not have been lost, are > ignored. > > AND whatever dangers lost NLRI may pose are covered > by the caveats in 4.1. > > Yes ? > > > ... as I am not sure that in the requirements draft we should > > specify direct solutions to specific issues, to e.g., say how to > > handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > > message [this is a case that I do not believe is forbidden by > > rfc2858 - if the working group could clarify whether this is > > something that we feel the draft needs to handle or can explicitly > > be omitted, then that would be appreciated]. > > The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in > the body of the message, with or without MP_REACH_NLRI and/or > MP_UNREACH_NLRI. If we call each of these a "collection of NLRI", > then there may be between 1 and 4 collections of NLRI in a message > (ignoring the End-of-RIB pseudo-UPDATE). It is an error to have more > than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI > attribute. It is not clear to me whether those should be Critical > Errors -- but while we are relaxing all error checking, I don't see > why they should be. > > It is possible that most implementations actually only send one > collection per message... so, as you suggest, on a you-know-and-I-know > basis, we'all could ignore the "theoretical" issues of more than one > collection in a message. > > But, this does not matter if the requirements allow lost NLRI to > simply be ignored. If the sender sends any MP_XXX first, then there > is little chance that NLRI will be lost, and things work better. If > the sender follows the old rules, and particularly if it sends more > than one collection at a time, then there is more chance that NLRI > will be lost. > > > > Later: > > > > > > (2) "All errors whereby the contained NLRI can be > > > extracted are referred to as Non-Critical". > > > > > > And that includes: > > > > > > (3) "where the length of all path attributes contained > > > within the UPDATE does not correspond to the > > > total path attribute length." > > > > > > That is, at least, more explicit than > > > draft-ietf-idr-error-handling-03, which glosses over (3). > > > > > > But if (3) is non-critical then there is some chance that > > > some NLRI will not be extracted, which appears to violate > > > (1) and (2). > > > Disclaimer: As I am sure that my comments previously have made > > clear, I do not maintain a code base for a BGP daemon/implementation > > - so please feel free to correct my logic below. > > > > I do not believe that (3) implies that the NLRI cannot be correctly > > found. > > What (3) implies to me is that somewhere amongst the attributes > something is broken. As Jakob Heitz succinctly puts it: "Once you > have a malformed update, NOTHING is certain." In particular, you > cannot be certain that all NLRI referred to by the sender can be found > by the receiver. > > > If the sum of total length is incorrect, then we can still > > extract the individual attributes - we just find that there is not > > enough data to fill the overall length we were told and/or we have > > too much attribute data compared to the total attribute length. > > This is precisely where I think the requirements come unstuck. There > is almost no redundancy in the attribute encoding. And almost all the > redundancy there is is discarded by the new-form-error-handling. So, > if the sum of the attribute lengths is incorrect, then (inter alia) > the receiver CANNOT know whether the attributes it has extracted are > the attributes the sender intended to send. In particular, the > receiver cannot know it has extracted all NLRI (except in the, > probably obscure, case of having extracted both MP_REACH_NLRI and > MP_UNREACH_NLRI). "Once you have a malformed update, NOTHING is > certain." > > Conversely, if the sum of attribute lengths is correct, then there is > a fighting chance that the attributes received are the attributes > sent. But, if one of those attributes is (say) nominally an > ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a > worry. > > ... > > > Then (4) "In order to maximise the number of cases whereby the > > > NLRI attributes [plural, now, BTW] can be reliably extracted > > > from a received message...". Ah. So it is not a Critical > > > Error if "the NLRI attribute cannot be correctly extracted". > > > No - it is a Critical error if we cannot extract the NLRI. This > > recommendation is to give an increased chance that the NLRI can be > > extracted as per the IDR error handling draft. This then (by virtue > > of resulting in the NLRI being extracted) minimises the number of > > cases that result in a Critical error. > > By this do you mean "all" NLRI or only "some" NLRI ? As above. > > > The plural here is to reflect > > that the existence of >1 type of NLRI attribute. > > That would imply that it should be "NLRI attributes" throughout ? > Though in most places where the draft speaks of "NLRI attribute" I > think it means one, some, any or all of the "collections of NLRI" (as > defined above). > > > > For me the requirement remains "conflicted". On the one hand it > > > seems to say that it is a Critical Error if the NLRI cannot be > > > extracted and parsed. On the other it seems to say it's OK if > > > you cannot extract some NLRI. > > > If you'll forgive me for removing a significant proportion of your > > message, I think that we need to take another step back here. It > > seems to me that the key question that you are highlighting is "What > > level of confidence do we need to have before we declare that the > > NLRI cannot be extracted?" -- do you agree? > > Absolutely. > > > From an operator perspective, I would like to compromise *certainty* > > for *robustness*. You are right, we are compromising correctness > > here, we might end up withdrawing an incorrect NLRI and impacting > > service operation for that prefix - however, it is somewhat > > preferable to me to withdraw a a subset of the NLRI incorrectly, > > rather than impact all NLRI in one single action. We clearly need to > > provide some bounds on how much we compromise the certainty (and > > live within the realms of possibility, such that we are not just > > taking a shot in the dark). This is what the definitions of Critical > > and Non-Critical within the document are intended to provide. Once > > again I will refer to the requirement that there is a balance > > between correctness and robustness - rather than a locally risk > > averse approach that results in harmful wider behaviour. > > Where one can extract the NLRI from a broken message, then > treat-as-withdraw is AFAICS no worse for the NLRI in question than > session-reset, and hugely better for all the other NLRI received from > the peer. > > Where not *all* the NLRI in a message have been extracted, then we > take a step beyond withdrawing something which should not have been > withdrawn. For each of those NLRI the receiver will (unknowingly) do > one of: > > (a) continue using a route which the sender has > withdrawn; > > (b) continue to use an out of date version of a route > which the sender has changed in some way, possibly > materially; > > (c) to fail to use a new route the sender has now made > available. > > Of these (a) looks serious and (b) could be, but certainly the effect > is different from session-reset; while (c) is, essentially, > treat-as-withdraw. If some risk "lost routes" is taken, then the > impact of that clearly must be weighed against the impact of > session-reset. I have not found a discussion of the impact of "lost > routes" in the draft, so I have no idea what the trade-off is, here. > > For completeness, if all forms and degrees of attribute broken-ness > are required to be acceptable, then there are cases where the receiver > cannot know whether *all* NLRI have been extracted, or not. > > > Is it acceptable that we leave this as guidance within the > > requirements? If not, please could you suggest how the definitions > > of Critical/Non-Critical could be altered to address your concerns? > > Without a change at the sender end, the problem is that: "Once you > have a malformed update, NOTHING is certain." > > So, as I said earlier, the fundamental question is: > > (F) is it OK to continue with a session after processing > a message which may have contained some NLRI which > could not be extracted ? > > As you say, the question hinges on the "which may have contained". As > above, it seems to me that the draft skates over the issue of "lost > routes". > > It also hinges on the operational impact of such "lost routes", on > which I am unqualified to pronounce. > > It seems to me there is a range of possibilities: > > 1) at one end of the spectrum, if "lost routes" are to > be avoided at all costs, then the rules for parsing > attributes need to be tight and without a change at > the sender end, what is achievable is constrained. > > 2) if "lost routes" are acceptable in the "theoretical" > cases, but you-know-and-I-know that most of the > time the case will not arise... > > ...or "lost routes" are acceptable provided some > defined steps are taken to identify as much NLRI > as is reasonably possible... > > ...then the requirements need to (a) make the case > and (b) describe the trade-off (so that designs > made to follow the requirements can be judged in > those terms). > > 3) at the other end of the spectrum, if "lost routes" > are always preferable to session-reset, then this > opens up an even looser approach to UPDATE message > handling, in which practically nothing need cause > a session-reset -- ie, practically nothing is a > Critical Error. > > And, as I have suggested in previous discussions, it is possible to > consider case (2) in two parts: > > a) where the sender is unchanged. > > In which case the issue is the degree of attribute > broken-ness vs the likelihood of "lost routes". > > If this is viewed as an intermediate step, then > perhaps the requirements could err on the side of > safety ? > > Perhaps this can be addressed by a "knob" allowing > more or less strictness in the parsing of > attributes ? > > b) where the sender is changed. > > In which case the issue ought to be moot, because > the receiver will then be able to know that there > are no "lost routes". > > > I would also appreciate further input from IDR as to whether this is > > sufficient requirement from GROW to allow a solution document to be > > written? > > The new requirements specify only Critical (session-reset) and > Non-Critical (treat-as-withdraw) Errors. This appears to rule out the > "attribute discard" option in draft-ietf-idr-error-handling-03. Is > that intended ? > > Chris > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b66f24bbc3cc104d1ee4d5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's a quick question, about possible mechanisms for determining whet= her or not we need to tear down a session.

If there is a= chance that some NLRI weren't properly decoded:

- What about requesting (presuming the option was negotiated) a route-= refresh, or a "confirm per-AFI-SAFI prefix list"?

<= /div>
It's an expensive "parity check" but is one way of = ensuring that we haven't missed a withdrawn prefix.
If it isn't in the subsequently received list of prefixes, we miss= ed it and should withdraw it.
Everything else is a no-op - maybe = we missed a new prefix (with new attribute?), but that is what "treat = as withdraw" gets you.

Just trying to make sure the cure isn't worse than = the disease, in all situations.
(Where "cure" is fail t= o withdraw because we "lost" the withdrawal because of malformed = update, or "cure" is tear down the session.)

Brian

On Fri, Dec 28,= 2012 at 1:04 PM, Chris Hall <chris.hall@highwayman.com> wrote:
Rob Shakir wrote (on Fri 28-Dec-2012 at 13:1= 0 +0000):
>
> (re: CCing IDR & GROW)
>
> On 28 Dec 2012, at 12:28, Chris Hall wrote:
>
> > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44):
> >>
> >> Any comments very welcome (to me or grow@).

> > I'm afraid I still don't get it :-( =A0What am I missing = ?
> >
> > UPDATE Message Length errors are Critical because they:
> >
> > (1) "result in cases whereby the NLRI attribute cannot
> > =A0 =A0 =A0be correctly extracted".
> >
> > The implication is that a failure to extract all NLRI is Critical= .
> > Is that a requirement ?

> If the NLRI cannot be determined, then this is a Critical error,
> yes. I left the wording relatively open on whether this is *all*
> NLRI, ...

OK. =A0So, if the message is broken (in any way):

=A0 * if no NLRI can be found, that's a Critical Error.

=A0 =A0 That would include the case where some broken
=A0 =A0 attribute upstream of any MP_XXX obscures that
=A0 =A0 MP_XXX.

=A0 * if some NLRI can be found, that's a Non-Critical error.

=A0 =A0 Such NLRI as can be found are treated-as-withdraw.

=A0 =A0 AND any NLRI that may or may not have been lost, are
=A0 =A0 ignored.

=A0 =A0 AND whatever dangers lost NLRI may pose are covered
=A0 =A0 by the caveats in 4.1.

Yes ?

> ... as I am not sure that in the requirements draft we should
> specify direct solutions to specific issues, to e.g.= , say how to
> handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > message [this is a case that I do not believe is forbidden by
> rfc2858 - if the working group could clarify whether this is
> something that we feel the draft needs to handle or can explicitly
> be omitted, then that would be appreciated].

The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in<= br> the body of the message, with or without MP_REACH_NLRI and/or
MP_UNREACH_NLRI. =A0If we call each of these a "collection of NLRI&quo= t;,
then there may be between 1 and 4 collections of NLRI in a message
(ignoring the End-of-RIB pseudo-UPDATE). =A0It is an error to have more
than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI
attribute. =A0It is not clear to me whether those should be Critical
Errors -- but while we are relaxing all error checking, I don't see
why they should be.

It is possible that most implementations actually only send one
collection per message... so, as you suggest, on a you-know-and-I-know
basis, we'all could ignore the "theoretical" issues of more t= han one
collection in a message.

But, this does not matter if the requirements allow lost NLRI to
simply be ignored. =A0If the sender sends any MP_XXX first, then there
is little chance that NLRI will be lost, and things work better. =A0If
the sender follows the old rules, and particularly if it sends more
than one collection at a time, then there is more chance that NLRI
will be lost.

> > Later:
> >
> > =A0(2) "All errors whereby the contained NLRI can be
> > =A0 =A0 =A0 extracted are referred to as Non-Critical".
> >
> > And that includes:
> >
> > =A0(3) "where the length of all path attributes contained > > =A0 =A0 =A0 within the UPDATE does not correspond to the
> > =A0 =A0 =A0 total path attribute length."
> >
> > That is, at least, more explicit than
> > draft-ietf-idr-error-handling-03, which glosses over (3).
> >
> > But if (3) is non-critical then there is some chance that
> > some NLRI will not be extracted, which appears to violate
> > (1) and (2).

> Disclaimer: As I am sure that my comments previously have made
> clear, I do not maintain a code base for a BGP daemon/implementation > - so please feel free to correct my logic below.
>
> I do not believe that (3) implies that the NLRI cannot be correctly > found.

What (3) implies to me is that somewhere amongst the attributes
something is broken. =A0As Jakob Heitz succinctly puts it: "Once you have a malformed update, NOTHING is certain." =A0In particular, you cannot be certain that all NLRI referred to by the sender can be found
by the receiver.

> If the sum of total length is incorrect, then we can still
> extract the individual attributes - we just find that there is not
> enough data to fill the overall length we were told and/or we have
> too much attribute data compared to the total attribute length.

This is precisely where I think the requirements come unstuck. =A0The= re
is almost no redundancy in the attribute encoding. =A0And almost all the redundancy there is is discarded by the new-form-error-handling. =A0So,
if the sum of the attribute lengths is incorrect, then (inter alia)
the receiver CANNOT know whether the attributes it has extracted are
the attributes the sender intended to send. =A0In particular, the
receiver cannot know it has extracted all NLRI (except in the,
probably obscure, case of having extracted both MP_REACH_NLRI and
MP_UNREACH_NLRI). =A0"Once you have a malformed update, NOTHING is
certain."

Conversely, if the sum of attribute lengths is correct, then there is
a fighting chance that the attributes received are the attributes
sent. =A0But, if one of those attributes is (say) nominally an
ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a
worry.

...
> > Then (4) "In order to maximise the number = of cases whereby the
> > NLRI attributes [plural, now, BTW] can be reliably extracted
> > from a received message...". =A0Ah. =A0So it is not a Critic= al
> > Error if "the NLRI attribute cannot be correctly extracted&q= uot;.

> No - it is a Critical error if we cannot extract the NLRI. This
> recommendation is to give an increased chance that the NLRI can be
> extracted as per the IDR error handling draft. This then (by virtue > of resulting in the NLRI being extracted) minimises the number of
> cases that result in a Critical error.

By this do you mean "all" NLRI or only "some" NLR= I ? =A0As above.

> The plural here is to reflect
> that the existence of >1 type of NLRI attribute.

That would imply that it should be "NLRI attributes" throug= hout ?
Though in most places where the draft speaks of "NLRI attribute" = I
think it means one, some, any or all of the "collections of NLRI"= (as
defined above).

> > For me the requirement remains "conflicted". =A0On the = one hand it
> > seems to say that it is a Critical Error if the NLRI cannot be > > extracted and parsed. =A0On the other it seems to say it's OK= if
> > you cannot extract some NLRI.

> If you'll forgive me for removing a significant proportion of your=
> message, I think that we need to take another step back here. It
> seems to me that the key question that you are highlighting is "W= hat
> level of confidence do we need to have before we declare that the
> NLRI cannot be extracted?" -- do you agree?

Absolutely.

> From an operator perspective, I would like to compromise *certainty* > for *robustness*. You are right, we are compromising correctness
> here, we might end up withdrawing an incorrect NLRI and impacting
> service operation for that prefix - however, it is somewhat
> preferable to me to withdraw a a subset of the NLRI incorrectly,
> rather than impact all NLRI in one single action. We clearly need to > provide some bounds on how much we compromise the certainty (and
> live within the realms of possibility, such that we are not just
> taking a shot in the dark). This is what the definitions of Critical > and Non-Critical within the document are intended to provide. Once
> again I will refer to the requirement that there is a balance
> between correctness and robustness - rather than a locally risk
> averse approach that results in harmful wider behaviour.

Where one can extract the NLRI from a broken message, then
treat-as-withdraw is AFAICS no worse for the NLRI in question than
session-reset, and hugely better for all the other NLRI received from
the peer.

Where not *all* the NLRI in a message have been extracted, then we
take a step beyond withdrawing something which should not have been
withdrawn. =A0For each of those NLRI the receiver will (unknowingly) do
one of:

=A0 (a) continue using a route which the sender has
=A0 =A0 =A0 withdrawn;

=A0 (b) continue to use an out of date version of a route
=A0 =A0 =A0 which the sender has changed in some way, possibly
=A0 =A0 =A0 materially;

=A0 (c) to fail to use a new route the sender has now made
=A0 =A0 =A0 available.

Of these (a) looks serious and (b) could be, but certainly the effect
is different from session-reset; while (c) is, essentially,
treat-as-withdraw. =A0If some risk "lost routes" is taken, then t= he
impact of that clearly must be weighed against the impact of
session-reset. =A0I have not found a discussion of the impact of "lost=
routes" in the draft, so I have no idea what the trade-off is, here.
For completeness, if all forms and degrees of attribute broken-ness
are required to be acceptable, then there are cases where the receiver
cannot know whether *all* NLRI have been extracted, or not.

> Is it acceptable that we leave this as guidance within the
> requirements? If not, please could you suggest how the definitions
> of Critical/Non-Critical could be altered to address your concerns?
Without a change at the sender end, the problem is that: "Once y= ou
have a malformed update, NOTHING is certain."

So, as I said earlier, the fundamental question is:

=A0 (F) is it OK to continue with a session after processing
=A0 =A0 =A0 a message which may have contained some NLRI which
=A0 =A0 =A0 could not be extracted ?

As you say, the question hinges on the "which may have contained"= . =A0As
above, it seems to me that the draft skates over the issue of "lost routes".

It also hinges on the operational impact of such "lost routes", o= n
which I am unqualified to pronounce.

It seems to me there is a range of possibilities:

=A0 1) at one end of the spectrum, if "lost routes" are to
=A0 =A0 =A0be avoided at all costs, then the rules for parsing
=A0 =A0 =A0attributes need to be tight and without a change at
=A0 =A0 =A0the sender end, what is achievable is constrained.

=A0 2) if "lost routes" are acceptable in the "theoretical&q= uot;
=A0 =A0 =A0cases, but you-know-and-I-know that most of the
=A0 =A0 =A0time the case will not arise...

=A0 =A0 =A0...or "lost routes" are acceptable provided some
=A0 =A0 =A0defined steps are taken to identify as much NLRI
=A0 =A0 =A0as is reasonably possible...

=A0 =A0 =A0...then the requirements need to (a) make the case
=A0 =A0 =A0and (b) describe the trade-off (so that designs
=A0 =A0 =A0made to follow the requirements can be judged in
=A0 =A0 =A0those terms).

=A0 3) at the other end of the spectrum, if "lost routes"
=A0 =A0 =A0are always preferable to session-reset, then this
=A0 =A0 =A0opens up an even looser approach to UPDATE message
=A0 =A0 =A0handling, in which practically nothing need cause
=A0 =A0 =A0a session-reset -- ie, practically nothing is a
=A0 =A0 =A0Critical Error.

And, as I have suggested in previous discussions, it is possible to
consider case (2) in two parts:

=A0 a) where the sender is unchanged.

=A0 =A0 =A0In which case the issue is the degree of attribute
=A0 =A0 =A0broken-ness vs the likelihood of "lost routes".

=A0 =A0 =A0If this is viewed as an intermediate step, then
=A0 =A0 =A0perhaps the requirements could err on the side of
=A0 =A0 =A0safety ?

=A0 =A0 =A0Perhaps this can be addressed by a "knob" allowing
=A0 =A0 =A0more or less strictness in the parsing of
=A0 =A0 =A0attributes ?

=A0 b) where the sender is changed.

=A0 =A0 =A0In which case the issue ought to be moot, because
=A0 =A0 =A0the receiver will then be able to know that there
=A0 =A0 =A0are no "lost routes".

> I would also appreciate further input from IDR as to whether this is > sufficient requirement from GROW to allow a solution document to be > written?

The new requirements specify only Critical (session-reset) and
Non-Critical (treat-as-withdraw) Errors. =A0This appears to rule out the "attribute discard" option in draft-ietf-idr-error-handling-03. = =A0Is
that intended ?

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b66f24bbc3cc104d1ee4d5f-- From jakob.heitz@ericsson.com Fri Dec 28 13:35:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB721F8E00; Fri, 28 Dec 2012 13:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=-3.013, BAYES_00=-2.599, BODY_ENHANCEMENT=0.309, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhDZ8q4Pf65N; Fri, 28 Dec 2012 13:35:11 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7080B21F8D67; Fri, 28 Dec 2012 13:35:11 -0800 (PST) Received: from EUSAAHC006.ericsson.se ([147.117.188.90]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBSLZ4QQ031744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Dec 2012 15:35:05 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Fri, 28 Dec 2012 16:35:04 -0500 From: Jakob Heitz To: Brian Dickson , Chris Hall Thread-Topic: [GROW] [Idr] Fwd: I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN5S3xsGJpUADsWEuoY0HJqT8HEpguuk7g Date: Fri, 28 Dec 2012 21:35:03 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14368F@eusaamb109.ericsson.se> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E14368Feusaamb109ericsso_" MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] Fwd: I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 21:35:13 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E14368Feusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Treat-as-withdraw is not a cure. Tear down the session is not a cure. All we can hope for after a malformed update is a temporary mitigation until human intervention can fix the problem. IMO, the goal of error handling is to limit the damage, not to cure the problem. -- Jakob Heitz. ________________________________ From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Bri= an Dickson Sent: Friday, December 28, 2012 11:02 AM To: Chris Hall Cc: idr@ietf.org; grow@ietf.org Subject: Re: [GROW] [Idr] Fwd: I-D Action: draft-ietf-grow-ops-reqs-for-bgp= -error-handling-06.txt Here's a quick question, about possible mechanisms for determining whether = or not we need to tear down a session. If there is a chance that some NLRI weren't properly decoded: - What about requesting (presuming the option was negotiated) a route-refre= sh, or a "confirm per-AFI-SAFI prefix list"? It's an expensive "parity check" but is one way of ensuring that we haven't= missed a withdrawn prefix. If it isn't in the subsequently received list of prefixes, we missed it and= should withdraw it. Everything else is a no-op - maybe we missed a new prefix (with new attribu= te?), but that is what "treat as withdraw" gets you. Just trying to make sure the cure isn't worse than the disease, in all situ= ations. (Where "cure" is fail to withdraw because we "lost" the withdrawal because = of malformed update, or "cure" is tear down the session.) Brian On Fri, Dec 28, 2012 at 1:04 PM, Chris Hall > wrote: Rob Shakir wrote (on Fri 28-Dec-2012 at 13:10 +0000): > > (re: CCing IDR & GROW) > > On 28 Dec 2012, at 12:28, Chris Hall wrote: > > > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44): > >> > >> Any comments very welcome (to me or grow@). > > I'm afraid I still don't get it :-( What am I missing ? > > > > UPDATE Message Length errors are Critical because they: > > > > (1) "result in cases whereby the NLRI attribute cannot > > be correctly extracted". > > > > The implication is that a failure to extract all NLRI is Critical. > > Is that a requirement ? > If the NLRI cannot be determined, then this is a Critical error, > yes. I left the wording relatively open on whether this is *all* > NLRI, ... OK. So, if the message is broken (in any way): * if no NLRI can be found, that's a Critical Error. That would include the case where some broken attribute upstream of any MP_XXX obscures that MP_XXX. * if some NLRI can be found, that's a Non-Critical error. Such NLRI as can be found are treated-as-withdraw. AND any NLRI that may or may not have been lost, are ignored. AND whatever dangers lost NLRI may pose are covered by the caveats in 4.1. Yes ? > ... as I am not sure that in the requirements draft we should > specify direct solutions to specific issues, to e.g., say how to > handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > message [this is a case that I do not believe is forbidden by > rfc2858 - if the working group could clarify whether this is > something that we feel the draft needs to handle or can explicitly > be omitted, then that would be appreciated]. The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in the body of the message, with or without MP_REACH_NLRI and/or MP_UNREACH_NLRI. If we call each of these a "collection of NLRI", then there may be between 1 and 4 collections of NLRI in a message (ignoring the End-of-RIB pseudo-UPDATE). It is an error to have more than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI attribute. It is not clear to me whether those should be Critical Errors -- but while we are relaxing all error checking, I don't see why they should be. It is possible that most implementations actually only send one collection per message... so, as you suggest, on a you-know-and-I-know basis, we'all could ignore the "theoretical" issues of more than one collection in a message. But, this does not matter if the requirements allow lost NLRI to simply be ignored. If the sender sends any MP_XXX first, then there is little chance that NLRI will be lost, and things work better. If the sender follows the old rules, and particularly if it sends more than one collection at a time, then there is more chance that NLRI will be lost. > > Later: > > > > (2) "All errors whereby the contained NLRI can be > > extracted are referred to as Non-Critical". > > > > And that includes: > > > > (3) "where the length of all path attributes contained > > within the UPDATE does not correspond to the > > total path attribute length." > > > > That is, at least, more explicit than > > draft-ietf-idr-error-handling-03, which glosses over (3). > > > > But if (3) is non-critical then there is some chance that > > some NLRI will not be extracted, which appears to violate > > (1) and (2). > Disclaimer: As I am sure that my comments previously have made > clear, I do not maintain a code base for a BGP daemon/implementation > - so please feel free to correct my logic below. > > I do not believe that (3) implies that the NLRI cannot be correctly > found. What (3) implies to me is that somewhere amongst the attributes something is broken. As Jakob Heitz succinctly puts it: "Once you have a malformed update, NOTHING is certain." In particular, you cannot be certain that all NLRI referred to by the sender can be found by the receiver. > If the sum of total length is incorrect, then we can still > extract the individual attributes - we just find that there is not > enough data to fill the overall length we were told and/or we have > too much attribute data compared to the total attribute length. This is precisely where I think the requirements come unstuck. There is almost no redundancy in the attribute encoding. And almost all the redundancy there is is discarded by the new-form-error-handling. So, if the sum of the attribute lengths is incorrect, then (inter alia) the receiver CANNOT know whether the attributes it has extracted are the attributes the sender intended to send. In particular, the receiver cannot know it has extracted all NLRI (except in the, probably obscure, case of having extracted both MP_REACH_NLRI and MP_UNREACH_NLRI). "Once you have a malformed update, NOTHING is certain." Conversely, if the sum of attribute lengths is correct, then there is a fighting chance that the attributes received are the attributes sent. But, if one of those attributes is (say) nominally an ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a worry. ... > > Then (4) "In order to maximise the number of cases whereby the > > NLRI attributes [plural, now, BTW] can be reliably extracted > > from a received message...". Ah. So it is not a Critical > > Error if "the NLRI attribute cannot be correctly extracted". > No - it is a Critical error if we cannot extract the NLRI. This > recommendation is to give an increased chance that the NLRI can be > extracted as per the IDR error handling draft. This then (by virtue > of resulting in the NLRI being extracted) minimises the number of > cases that result in a Critical error. By this do you mean "all" NLRI or only "some" NLRI ? As above. > The plural here is to reflect > that the existence of >1 type of NLRI attribute. That would imply that it should be "NLRI attributes" throughout ? Though in most places where the draft speaks of "NLRI attribute" I think it means one, some, any or all of the "collections of NLRI" (as defined above). > > For me the requirement remains "conflicted". On the one hand it > > seems to say that it is a Critical Error if the NLRI cannot be > > extracted and parsed. On the other it seems to say it's OK if > > you cannot extract some NLRI. > If you'll forgive me for removing a significant proportion of your > message, I think that we need to take another step back here. It > seems to me that the key question that you are highlighting is "What > level of confidence do we need to have before we declare that the > NLRI cannot be extracted?" -- do you agree? Absolutely. > From an operator perspective, I would like to compromise *certainty* > for *robustness*. You are right, we are compromising correctness > here, we might end up withdrawing an incorrect NLRI and impacting > service operation for that prefix - however, it is somewhat > preferable to me to withdraw a a subset of the NLRI incorrectly, > rather than impact all NLRI in one single action. We clearly need to > provide some bounds on how much we compromise the certainty (and > live within the realms of possibility, such that we are not just > taking a shot in the dark). This is what the definitions of Critical > and Non-Critical within the document are intended to provide. Once > again I will refer to the requirement that there is a balance > between correctness and robustness - rather than a locally risk > averse approach that results in harmful wider behaviour. Where one can extract the NLRI from a broken message, then treat-as-withdraw is AFAICS no worse for the NLRI in question than session-reset, and hugely better for all the other NLRI received from the peer. Where not *all* the NLRI in a message have been extracted, then we take a step beyond withdrawing something which should not have been withdrawn. For each of those NLRI the receiver will (unknowingly) do one of: (a) continue using a route which the sender has withdrawn; (b) continue to use an out of date version of a route which the sender has changed in some way, possibly materially; (c) to fail to use a new route the sender has now made available. Of these (a) looks serious and (b) could be, but certainly the effect is different from session-reset; while (c) is, essentially, treat-as-withdraw. If some risk "lost routes" is taken, then the impact of that clearly must be weighed against the impact of session-reset. I have not found a discussion of the impact of "lost routes" in the draft, so I have no idea what the trade-off is, here. For completeness, if all forms and degrees of attribute broken-ness are required to be acceptable, then there are cases where the receiver cannot know whether *all* NLRI have been extracted, or not. > Is it acceptable that we leave this as guidance within the > requirements? If not, please could you suggest how the definitions > of Critical/Non-Critical could be altered to address your concerns? Without a change at the sender end, the problem is that: "Once you have a malformed update, NOTHING is certain." So, as I said earlier, the fundamental question is: (F) is it OK to continue with a session after processing a message which may have contained some NLRI which could not be extracted ? As you say, the question hinges on the "which may have contained". As above, it seems to me that the draft skates over the issue of "lost routes". It also hinges on the operational impact of such "lost routes", on which I am unqualified to pronounce. It seems to me there is a range of possibilities: 1) at one end of the spectrum, if "lost routes" are to be avoided at all costs, then the rules for parsing attributes need to be tight and without a change at the sender end, what is achievable is constrained. 2) if "lost routes" are acceptable in the "theoretical" cases, but you-know-and-I-know that most of the time the case will not arise... ...or "lost routes" are acceptable provided some defined steps are taken to identify as much NLRI as is reasonably possible... ...then the requirements need to (a) make the case and (b) describe the trade-off (so that designs made to follow the requirements can be judged in those terms). 3) at the other end of the spectrum, if "lost routes" are always preferable to session-reset, then this opens up an even looser approach to UPDATE message handling, in which practically nothing need cause a session-reset -- ie, practically nothing is a Critical Error. And, as I have suggested in previous discussions, it is possible to consider case (2) in two parts: a) where the sender is unchanged. In which case the issue is the degree of attribute broken-ness vs the likelihood of "lost routes". If this is viewed as an intermediate step, then perhaps the requirements could err on the side of safety ? Perhaps this can be addressed by a "knob" allowing more or less strictness in the parsing of attributes ? b) where the sender is changed. In which case the issue ought to be moot, because the receiver will then be able to know that there are no "lost routes". > I would also appreciate further input from IDR as to whether this is > sufficient requirement from GROW to allow a solution document to be > written? The new requirements specify only Critical (session-reset) and Non-Critical (treat-as-withdraw) Errors. This appears to rule out the "attribute discard" option in draft-ietf-idr-error-handling-03. Is that intended ? Chris _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E14368Feusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Treat-as-withdraw is not= a cure.
Tear down the session is= not a cure.
 
All we can hope for afte= r a malformed update is a
temporary mitigation unt= il human intervention can
fix the problem.<= /font>
 
IMO, the goal of error h= andling is to limit the
damage, not to cure the = problem.

-- Jakob Heitz.

 

From: grow-bounces@ietf.org [mailto= :grow-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Friday, December 28, 2012 11:02 AM
To: Chris Hall
Cc: idr@ietf.org; grow@ietf.org
Subject: Re: [GROW] [Idr] Fwd: I-D Action: draft-ietf-grow-ops-reqs-= for-bgp-error-handling-06.txt

Here's a quick question, about possible mechanisms for determining whether = or not we need to tear down a session.

If there is a chance that some NLRI weren't properly decoded:

- What about requesting (presuming the option was negotiated) a route-= refresh, or a "confirm per-AFI-SAFI prefix list"?

It's an expensive "parity check" but is one way of ensuring = that we haven't missed a withdrawn prefix.
If it isn't in the subsequently received list of prefixes, we missed i= t and should withdraw it.
Everything else is a no-op - maybe we missed a new prefix (with new at= tribute?), but that is what "treat as withdraw" gets you.

Just trying to make sure the cure isn't worse than the disease, in all= situations.
(Where "cure" is fail to withdraw because we "lost"= ; the withdrawal because of malformed update, or "cure" is tear d= own the session.)

Brian

On Fri, Dec 28, 2012 at 1:04 PM, Chris Hall <chris.ha= ll@highwayman.com> wrote:
Rob Shakir wrote (on Fri 28-Dec-2012 at 13:10 +0000):
>
> (re: CCing IDR & GROW)
>
> On 28 Dec 2012, at 12:28, Chris Hall wrote:
>
> > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44):
> >>
> >> Any comments very welcome (to me or grow@).

> > I'm afraid I still don't get it :-(  What am I missing ?
> >
> > UPDATE Message Length errors are Critical because they:
> >
> > (1) "result in cases whereby the NLRI attribute cannot
> >      be correctly extracted".
> >
> > The implication is that a failure to extract all NLRI is Critical= .
> > Is that a requirement ?

> If the NLRI cannot be determined, then this is a Critical error,
> yes. I left the wording relatively open on whether this is *all*
> NLRI, ...

OK.  So, if the message is broken (in any way):

  * if no NLRI can be found, that's a Critical Error.

    That would include the case where some broken
    attribute upstream of any MP_XXX obscures that
    MP_XXX.

  * if some NLRI can be found, that's a Non-Critical error.

    Such NLRI as can be found are treated-as-withdraw.

    AND any NLRI that may or may not have been lost, are
    ignored.

    AND whatever dangers lost NLRI may pose are covered
    by the caveats in 4.1.

Yes ?

> ... as I am not sure that in the requirements draft we should
> specify direct solutions to specific issues, to e.g.= , say how to
> handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > message [this is a case that I do not believe is forbidden by
> rfc2858 - if the working group could clarify whether this is
> something that we feel the draft needs to handle or can explicitly
> be omitted, then that would be appreciated].

The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in
the body of the message, with or without MP_REACH_NLRI and/or
MP_UNREACH_NLRI.  If we call each of these a "collection of NLRI&= quot;,
then there may be between 1 and 4 collections of NLRI in a message
(ignoring the End-of-RIB pseudo-UPDATE).  It is an error to have more<= br> than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI
attribute.  It is not clear to me whether those should be Critical
Errors -- but while we are relaxing all error checking, I don't see
why they should be.

It is possible that most implementations actually only send one
collection per message... so, as you suggest, on a you-know-and-I-know
basis, we'all could ignore the "theoretical" issues of more than = one
collection in a message.

But, this does not matter if the requirements allow lost NLRI to
simply be ignored.  If the sender sends any MP_XXX first, then there is little chance that NLRI will be lost, and things work better.  If the sender follows the old rules, and particularly if it sends more
than one collection at a time, then there is more chance that NLRI
will be lost.

> > Later:
> >
> >  (2) "All errors whereby the contained NLRI can be
> >       extracted are referred to as Non-Critical&qu= ot;.
> >
> > And that includes:
> >
> >  (3) "where the length of all path attributes contained=
> >       within the UPDATE does not correspond to the=
> >       total path attribute length."
> >
> > That is, at least, more explicit than
> > draft-ietf-idr-error-handling-03, which glosses over (3).
> >
> > But if (3) is non-critical then there is some chance that
> > some NLRI will not be extracted, which appears to violate
> > (1) and (2).

> Disclaimer: As I am sure that my comments previously have made
> clear, I do not maintain a code base for a BGP daemon/implementation > - so please feel free to correct my logic below.
>
> I do not believe that (3) implies that the NLRI cannot be correctly > found.

What (3) implies to me is that somewhere amongst the attributes
something is broken.  As Jakob Heitz succinctly puts it: "Once yo= u
have a malformed update, NOTHING is certain."  In particular, you=
cannot be certain that all NLRI referred to by the sender can be found
by the receiver.

> If the sum of total length is incorrect, then we can still
> extract the individual attributes - we just find that there is not
> enough data to fill the overall length we were told and/or we have
> too much attribute data compared to the total attribute length.

This is precisely where I think the requirements come unstuck.  There<= br> is almost no redundancy in the attribute encoding.  And almost all the=
redundancy there is is discarded by the new-form-error-handling.  So,<= br> if the sum of the attribute lengths is incorrect, then (inter alia)
the receiver CANNOT know whether the attributes it has extracted are
the attributes the sender intended to send.  In particular, the
receiver cannot know it has extracted all NLRI (except in the,
probably obscure, case of having extracted both MP_REACH_NLRI and
MP_UNREACH_NLRI).  "Once you have a malformed update, NOTHING is<= br> certain."

Conversely, if the sum of attribute lengths is correct, then there is
a fighting chance that the attributes received are the attributes
sent.  But, if one of those attributes is (say) nominally an
ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a
worry.

...
> > Then (4) "In order to maximise the number = of cases whereby the
> > NLRI attributes [plural, now, BTW] can be reliably extracted
> > from a received message...".  Ah.  So it is not a = Critical
> > Error if "the NLRI attribute cannot be correctly extracted&q= uot;.

> No - it is a Critical error if we cannot extract the NLRI. This
> recommendation is to give an increased chance that the NLRI can be
> extracted as per the IDR error handling draft. This then (by virtue > of resulting in the NLRI being extracted) minimises the number of
> cases that result in a Critical error.

By this do you mean "all" NLRI or only "some" NLRI ? &n= bsp;As above.

> The plural here is to reflect
> that the existence of >1 type of NLRI attribute.

That would imply that it should be "NLRI attributes" throughout ?=
Though in most places where the draft speaks of "NLRI attribute" = I
think it means one, some, any or all of the "collections of NLRI"= (as
defined above).

> > For me the requirement remains "conflicted".  On t= he one hand it
> > seems to say that it is a Critical Error if the NLRI cannot be > > extracted and parsed.  On the other it seems to say it's OK = if
> > you cannot extract some NLRI.

> If you'll forgive me for removing a significant proportion of your
> message, I think that we need to take another step back here. It
> seems to me that the key question that you are highlighting is "W= hat
> level of confidence do we need to have before we declare that the
> NLRI cannot be extracted?" -- do you agree?

Absolutely.

> From an operator perspective, I would like to compromise *certainty* > for *robustness*. You are right, we are compromising correctness
> here, we might end up withdrawing an incorrect NLRI and impacting
> service operation for that prefix - however, it is somewhat
> preferable to me to withdraw a a subset of the NLRI incorrectly,
> rather than impact all NLRI in one single action. We clearly need to > provide some bounds on how much we compromise the certainty (and
> live within the realms of possibility, such that we are not just
> taking a shot in the dark). This is what the definitions of Critical > and Non-Critical within the document are intended to provide. Once
> again I will refer to the requirement that there is a balance
> between correctness and robustness - rather than a locally risk
> averse approach that results in harmful wider behaviour.

Where one can extract the NLRI from a broken message, then
treat-as-withdraw is AFAICS no worse for the NLRI in question than
session-reset, and hugely better for all the other NLRI received from
the peer.

Where not *all* the NLRI in a message have been extracted, then we
take a step beyond withdrawing something which should not have been
withdrawn.  For each of those NLRI the receiver will (unknowingly) do<= br> one of:

  (a) continue using a route which the sender has
      withdrawn;

  (b) continue to use an out of date version of a route
      which the sender has changed in some way, possibly
      materially;

  (c) to fail to use a new route the sender has now made
      available.

Of these (a) looks serious and (b) could be, but certainly the effect
is different from session-reset; while (c) is, essentially,
treat-as-withdraw.  If some risk "lost routes" is taken, the= n the
impact of that clearly must be weighed against the impact of
session-reset.  I have not found a discussion of the impact of "l= ost
routes" in the draft, so I have no idea what the trade-off is, here.
For completeness, if all forms and degrees of attribute broken-ness
are required to be acceptable, then there are cases where the receiver
cannot know whether *all* NLRI have been extracted, or not.

> Is it acceptable that we leave this as guidance within the
> requirements? If not, please could you suggest how the definitions
> of Critical/Non-Critical could be altered to address your concerns?
Without a change at the sender end, the problem is that: "Once you
have a malformed update, NOTHING is certain."

So, as I said earlier, the fundamental question is:

  (F) is it OK to continue with a session after processing
      a message which may have contained some NLRI which
      could not be extracted ?

As you say, the question hinges on the "which may have contained"= .  As
above, it seems to me that the draft skates over the issue of "lost routes".

It also hinges on the operational impact of such "lost routes", o= n
which I am unqualified to pronounce.

It seems to me there is a range of possibilities:

  1) at one end of the spectrum, if "lost routes" are to
     be avoided at all costs, then the rules for parsing
     attributes need to be tight and without a change at
     the sender end, what is achievable is constrained.

  2) if "lost routes" are acceptable in the "theoretica= l"
     cases, but you-know-and-I-know that most of the
     time the case will not arise...

     ...or "lost routes" are acceptable provided s= ome
     defined steps are taken to identify as much NLRI
     as is reasonably possible...

     ...then the requirements need to (a) make the case
     and (b) describe the trade-off (so that designs
     made to follow the requirements can be judged in
     those terms).

  3) at the other end of the spectrum, if "lost routes"
     are always preferable to session-reset, then this
     opens up an even looser approach to UPDATE message
     handling, in which practically nothing need cause
     a session-reset -- ie, practically nothing is a
     Critical Error.

And, as I have suggested in previous discussions, it is possible to
consider case (2) in two parts:

  a) where the sender is unchanged.

     In which case the issue is the degree of attribute
     broken-ness vs the likelihood of "lost routes"= ;.

     If this is viewed as an intermediate step, then
     perhaps the requirements could err on the side of
     safety ?

     Perhaps this can be addressed by a "knob" all= owing
     more or less strictness in the parsing of
     attributes ?

  b) where the sender is changed.

     In which case the issue ought to be moot, because
     the receiver will then be able to know that there
     are no "lost routes".

> I would also appreciate further input from IDR as to whether this is > sufficient requirement from GROW to allow a solution document to be > written?

The new requirements specify only Critical (session-reset) and
Non-Critical (treat-as-withdraw) Errors.  This appears to rule out the=
"attribute discard" option in draft-ietf-idr-error-handling-03. &= nbsp;Is
that intended ?

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E14368Feusaamb109ericsso_-- From chris.hall@highwayman.com Sat Dec 29 03:09:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3067021F85AB; Sat, 29 Dec 2012 03:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfMF5psNPb4n; Sat, 29 Dec 2012 03:09:11 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id 67FED21F85A7; Sat, 29 Dec 2012 03:09:11 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id B087BA64315; Sat, 29 Dec 2012 11:09:09 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 8B655A642CC; Sat, 29 Dec 2012 11:09:09 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP; Sat, 29 Dec 2012 11:09:09 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TouHs-0000wE-NR; Sat, 29 Dec 2012 11:09:08 +0000 From: "Chris Hall" To: , Date: Sat, 29 Dec 2012 11:09:03 -0000 Organization: Highwayman Message-ID: <02bd01cde5b4$ec6c58d0$c5450a70$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ltOeobOE5p/5+RsmrJ6jcHRxD7Q== Content-Language: en-gb X-MDF-HostID: 8 Subject: Re: [Idr] [GROW] Fwd: I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 11:09:12 -0000 Jakob Heitz wrote (on Fri 28-Dec-2012 at 21:35 +0000): .... > All we can hope for after a malformed update is a > temporary mitigation until human intervention can > fix the problem. > > IMO, the goal of error handling is to limit the > damage, not to cure the problem. >From previous discussions it appears that to "limit the damage" you would avoid session-reset at all costs. Yes ? Seems to me the goal of "Enhanced Error Handling" is, simply, to be "not as bad as session-reset". Where all NLRI in a message can be identified, treat-as-withdraw seems to me to be not as bad as session-reset. But: "Once you have a malformed update, NOTHING is certain." So, there is some risk of "lost NLRI" when tolerating (not resetting the session) malformed updates. I don't know if "lost NLRI" can cause problems which are worse than session-reset. I cannot find anything in draft-ietf-grow-ops-reqs-for-bgp-error-handling-06 or draft-ietf-idr-error-handling-03 which addresses the issue. (Though draft-ietf-idr-error-handling-03 waxes lyrical on "Why not discard UPDATE messages ?") If the strategy is to treat-as-withdraw where you can, and continue with whatever "lost NLRI" there may be, then that's simple enough. But if that is the strategy, why do the drafts not say so ? The "ops-reqs" draft sets out to define Critical and Non-Critical errors in terms of the inability/ability to extract NLRI, which is not obviously consistent with this strategy. It may be that "lost NLRI" are, indeed, potentially (in theory) worse than session-reset, but that the risk is (in practice) reduced to a tolerable level if a certain amount of care is taken to extract NLRI -- falling back to session-reset if that process fails. This seems to me to be quite a sophisticated position -- too sophisticated to be simply implied by what the drafts do not specify. On the other hand, if "lost NLRI" are not as bad as session-reset, then: a) when parsing the NLRI themselves, why not treat-as- withdraw everything up to the point where a prefix length overruns the NLRI collection ? b) when parsing MP_XXX attributes, why worry about duplicates ? Why not treat-as-withdraw everything in sight ? c) when parsing the message layer, why worry about consistency of message length and withdrawn routes and attributes length ? Since "lost NLRI" are tolerable, why worry about losing some IPv4 Unicast NLRI ? d) the presence of 16 x 0xFF is surely sufficient to signal the start of a BGP Message. So, when starting to read a message (after having read message length octets for the previous one), why not scan forwards looking for 16 x 0xFF ? I suspect the drafts do not go this far because there are unspoken assumptions about what is worse than session-reset; either that, or because the issue of "lost NLRI" has been glossed over. Neither of which, I suggest, are very satisfactory. Chris From chris.hall@highwayman.com Sat Dec 29 06:21:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BF721F85DF; Sat, 29 Dec 2012 06:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6pLlAJG8tRX; Sat, 29 Dec 2012 06:21:09 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta010.mxout.tch.inty.net [91.221.169.51]) by ietfa.amsl.com (Postfix) with ESMTP id 52F2621F8505; Sat, 29 Dec 2012 06:21:09 -0800 (PST) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id C382B400516; Sat, 29 Dec 2012 14:21:07 +0000 (GMT) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id A2E16400514; Sat, 29 Dec 2012 14:21:07 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tch.inty.net (Postfix) with ESMTP; Sat, 29 Dec 2012 14:21:07 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ToxHe-0000wS-Nh; Sat, 29 Dec 2012 14:21:06 +0000 From: "Chris Hall" To: , References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> In-Reply-To: Date: Sat, 29 Dec 2012 14:21:01 -0000 Organization: Highwayman Message-ID: <02c101cde5cf$bd94d0d0$38be7270$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFuOjybZ81Jyr3vkBQVN4QFzf3TcAHhILBDAeLn4UsCePM9v5i9DclQ Content-Language: en-gb X-MDF-HostID: 19 Subject: Re: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 14:21:10 -0000 Brian Dickson wrote (on Fri 28-Dec-2012 at 19:02 +0000): > > If there is a chance that some NLRI weren't properly decoded: > > - What about requesting (presuming the option was negotiated) > a route-refresh, or a "confirm per-AFI-SAFI prefix list"? If the sender is sending broken updates, then a route-refresh might repeat the error. But that doesn't make things any worse. In fact, since one would only keep those routes which the route-refresh sent correctly, that would improve things :-) The draft (section 5) talks about Graceful Restart and extensions thereof, but if those are not available, Route-Refresh might be. Is Route-Refresh a sufficiently common option that one can stop trying to square the "Once you have a malformed update, NOTHING is certain" circle ? It might be nice to only refresh/confirm the affected AFI/SAFI... but if MP_XXX attributes have gone walkabout, it may not be clear which AFI/SAFI those are :-( Chris From rjs@rob.sh Sat Dec 29 16:05:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32E121F8496; Sat, 29 Dec 2012 16:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.229 X-Spam-Level: *** X-Spam-Status: No, score=3.229 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXtgLkHQ2ltr; Sat, 29 Dec 2012 16:05:14 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 0280221F845F; Sat, 29 Dec 2012 16:05:14 -0800 (PST) Received: from [86.0.24.33] (helo=[192.168.0.19]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1Tp6Lo-0007uX-CB; Sun, 30 Dec 2012 00:02:00 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_81DB352D-E036-47D8-9A50-6E15BB53EFB2" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rob Shakir In-Reply-To: Date: Sun, 30 Dec 2012 00:05:08 +0000 Message-Id: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> To: Brian Dickson X-Mailer: Apple Mail (2.1499) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 00:05:17 -0000 --Apple-Mail=_81DB352D-E036-47D8-9A50-6E15BB53EFB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Brian, We discussed this at some length previously (the -00 of the requirements = draft discussed automatically triggering some form of means to recover = from the error). I think that there is some merit in doing so, but there = are clearly also scaling considerations around this (in terms of = requiring both BGP speakers to re-generate/re-process UPDATEs).=20 The consensus that was reached in the previous discussion was that this = is not necessarily going to be of advantage in terms of causing a = different UPDATE message to be generated. Particularly, since a ROUTE = REFRESH would result in the same UPDATE packing (generally). To that = end, what the requirements draft currently says is that: - ROUTE-REFRESH is a reasonable way to re-run a consistency check = between two peers (especially with start-of-refresh and end-of-refresh = markers, since this means that we can purge any NLRI that we missed = being withdrawn). - If there is anything automatically triggered, it would be prudent to = try and ensure that we can make as specific a request to the other = speaker as possible - this is where mechanisms such as One-Time ORF were = suggested, and is a similar space to that which would be solved through = having the UPDATE-VERSION message described in = draft-ietf-idr-enhanced-gr if one were to be able to have a REFRESH = following a "last known good" position. Making a more specific request = may result in a different UPDATE being generated, which may mean the = error is fixed, but this is not guaranteed. - If the selected best path changes on the remote speaker, then it will = be re-advertised anyway - resulting in another chance to re-parse these = NLRI. So, certainly, if we relax the "correctness" requirement, then it would = seem a good idea to have some means to be able to consistency check -- = it's just a matter of ensuring that this is done in an effective and = scalable manner, that does not affect normal BGP operation. Cheers, r. On 28 Dec 2012, at 19:02, Brian Dickson = wrote: > Here's a quick question, about possible mechanisms for determining = whether or not we need to tear down a session. >=20 > If there is a chance that some NLRI weren't properly decoded: >=20 > - What about requesting (presuming the option was negotiated) a = route-refresh, or a "confirm per-AFI-SAFI prefix list"? >=20 > It's an expensive "parity check" but is one way of ensuring that we = haven't missed a withdrawn prefix. > If it isn't in the subsequently received list of prefixes, we missed = it and should withdraw it. > Everything else is a no-op - maybe we missed a new prefix (with new = attribute?), but that is what "treat as withdraw" gets you. >=20 > Just trying to make sure the cure isn't worse than the disease, in all = situations. > (Where "cure" is fail to withdraw because we "lost" the withdrawal = because of malformed update, or "cure" is tear down the session.) >=20 > Brian >=20 > On Fri, Dec 28, 2012 at 1:04 PM, Chris Hall = wrote: > Rob Shakir wrote (on Fri 28-Dec-2012 at 13:10 +0000): > > > > (re: CCing IDR & GROW) > > > > On 28 Dec 2012, at 12:28, Chris Hall wrote: > > > > > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44): > > >> > > >> Any comments very welcome (to me or grow@). >=20 > > > I'm afraid I still don't get it :-( What am I missing ? > > > > > > UPDATE Message Length errors are Critical because they: > > > > > > (1) "result in cases whereby the NLRI attribute cannot > > > be correctly extracted". > > > > > > The implication is that a failure to extract all NLRI is Critical. > > > Is that a requirement ? >=20 > > If the NLRI cannot be determined, then this is a Critical error, > > yes. I left the wording relatively open on whether this is *all* > > NLRI, ... >=20 > OK. So, if the message is broken (in any way): >=20 > * if no NLRI can be found, that's a Critical Error. >=20 > That would include the case where some broken > attribute upstream of any MP_XXX obscures that > MP_XXX. >=20 > * if some NLRI can be found, that's a Non-Critical error. >=20 > Such NLRI as can be found are treated-as-withdraw. >=20 > AND any NLRI that may or may not have been lost, are > ignored. >=20 > AND whatever dangers lost NLRI may pose are covered > by the caveats in 4.1. >=20 > Yes ? >=20 > > ... as I am not sure that in the requirements draft we should > > specify direct solutions to specific issues, to e.g., say how to > > handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > > message [this is a case that I do not believe is forbidden by > > rfc2858 - if the working group could clarify whether this is > > something that we feel the draft needs to handle or can explicitly > > be omitted, then that would be appreciated]. >=20 > The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in > the body of the message, with or without MP_REACH_NLRI and/or > MP_UNREACH_NLRI. If we call each of these a "collection of NLRI", > then there may be between 1 and 4 collections of NLRI in a message > (ignoring the End-of-RIB pseudo-UPDATE). It is an error to have more > than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI > attribute. It is not clear to me whether those should be Critical > Errors -- but while we are relaxing all error checking, I don't see > why they should be. >=20 > It is possible that most implementations actually only send one > collection per message... so, as you suggest, on a you-know-and-I-know > basis, we'all could ignore the "theoretical" issues of more than one > collection in a message. >=20 > But, this does not matter if the requirements allow lost NLRI to > simply be ignored. If the sender sends any MP_XXX first, then there > is little chance that NLRI will be lost, and things work better. If > the sender follows the old rules, and particularly if it sends more > than one collection at a time, then there is more chance that NLRI > will be lost. >=20 > > > Later: > > > > > > (2) "All errors whereby the contained NLRI can be > > > extracted are referred to as Non-Critical". > > > > > > And that includes: > > > > > > (3) "where the length of all path attributes contained > > > within the UPDATE does not correspond to the > > > total path attribute length." > > > > > > That is, at least, more explicit than > > > draft-ietf-idr-error-handling-03, which glosses over (3). > > > > > > But if (3) is non-critical then there is some chance that > > > some NLRI will not be extracted, which appears to violate > > > (1) and (2). >=20 > > Disclaimer: As I am sure that my comments previously have made > > clear, I do not maintain a code base for a BGP daemon/implementation > > - so please feel free to correct my logic below. > > > > I do not believe that (3) implies that the NLRI cannot be correctly > > found. >=20 > What (3) implies to me is that somewhere amongst the attributes > something is broken. As Jakob Heitz succinctly puts it: "Once you > have a malformed update, NOTHING is certain." In particular, you > cannot be certain that all NLRI referred to by the sender can be found > by the receiver. >=20 > > If the sum of total length is incorrect, then we can still > > extract the individual attributes - we just find that there is not > > enough data to fill the overall length we were told and/or we have > > too much attribute data compared to the total attribute length. >=20 > This is precisely where I think the requirements come unstuck. There > is almost no redundancy in the attribute encoding. And almost all the > redundancy there is is discarded by the new-form-error-handling. So, > if the sum of the attribute lengths is incorrect, then (inter alia) > the receiver CANNOT know whether the attributes it has extracted are > the attributes the sender intended to send. In particular, the > receiver cannot know it has extracted all NLRI (except in the, > probably obscure, case of having extracted both MP_REACH_NLRI and > MP_UNREACH_NLRI). "Once you have a malformed update, NOTHING is > certain." >=20 > Conversely, if the sum of attribute lengths is correct, then there is > a fighting chance that the attributes received are the attributes > sent. But, if one of those attributes is (say) nominally an > ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a > worry. >=20 > ... > > > Then (4) "In order to maximise the number of cases whereby the > > > NLRI attributes [plural, now, BTW] can be reliably extracted > > > from a received message...". Ah. So it is not a Critical > > > Error if "the NLRI attribute cannot be correctly extracted". >=20 > > No - it is a Critical error if we cannot extract the NLRI. This > > recommendation is to give an increased chance that the NLRI can be > > extracted as per the IDR error handling draft. This then (by virtue > > of resulting in the NLRI being extracted) minimises the number of > > cases that result in a Critical error. >=20 > By this do you mean "all" NLRI or only "some" NLRI ? As above. >=20 > > The plural here is to reflect > > that the existence of >1 type of NLRI attribute. >=20 > That would imply that it should be "NLRI attributes" throughout ? > Though in most places where the draft speaks of "NLRI attribute" I > think it means one, some, any or all of the "collections of NLRI" (as > defined above). >=20 > > > For me the requirement remains "conflicted". On the one hand it > > > seems to say that it is a Critical Error if the NLRI cannot be > > > extracted and parsed. On the other it seems to say it's OK if > > > you cannot extract some NLRI. >=20 > > If you'll forgive me for removing a significant proportion of your > > message, I think that we need to take another step back here. It > > seems to me that the key question that you are highlighting is "What > > level of confidence do we need to have before we declare that the > > NLRI cannot be extracted?" -- do you agree? >=20 > Absolutely. >=20 > > =46rom an operator perspective, I would like to compromise = *certainty* > > for *robustness*. You are right, we are compromising correctness > > here, we might end up withdrawing an incorrect NLRI and impacting > > service operation for that prefix - however, it is somewhat > > preferable to me to withdraw a a subset of the NLRI incorrectly, > > rather than impact all NLRI in one single action. We clearly need to > > provide some bounds on how much we compromise the certainty (and > > live within the realms of possibility, such that we are not just > > taking a shot in the dark). This is what the definitions of Critical > > and Non-Critical within the document are intended to provide. Once > > again I will refer to the requirement that there is a balance > > between correctness and robustness - rather than a locally risk > > averse approach that results in harmful wider behaviour. >=20 > Where one can extract the NLRI from a broken message, then > treat-as-withdraw is AFAICS no worse for the NLRI in question than > session-reset, and hugely better for all the other NLRI received from > the peer. >=20 > Where not *all* the NLRI in a message have been extracted, then we > take a step beyond withdrawing something which should not have been > withdrawn. For each of those NLRI the receiver will (unknowingly) do > one of: >=20 > (a) continue using a route which the sender has > withdrawn; >=20 > (b) continue to use an out of date version of a route > which the sender has changed in some way, possibly > materially; >=20 > (c) to fail to use a new route the sender has now made > available. >=20 > Of these (a) looks serious and (b) could be, but certainly the effect > is different from session-reset; while (c) is, essentially, > treat-as-withdraw. If some risk "lost routes" is taken, then the > impact of that clearly must be weighed against the impact of > session-reset. I have not found a discussion of the impact of "lost > routes" in the draft, so I have no idea what the trade-off is, here. >=20 > For completeness, if all forms and degrees of attribute broken-ness > are required to be acceptable, then there are cases where the receiver > cannot know whether *all* NLRI have been extracted, or not. >=20 > > Is it acceptable that we leave this as guidance within the > > requirements? If not, please could you suggest how the definitions > > of Critical/Non-Critical could be altered to address your concerns? >=20 > Without a change at the sender end, the problem is that: "Once you > have a malformed update, NOTHING is certain." >=20 > So, as I said earlier, the fundamental question is: >=20 > (F) is it OK to continue with a session after processing > a message which may have contained some NLRI which > could not be extracted ? >=20 > As you say, the question hinges on the "which may have contained". As > above, it seems to me that the draft skates over the issue of "lost > routes". >=20 > It also hinges on the operational impact of such "lost routes", on > which I am unqualified to pronounce. >=20 > It seems to me there is a range of possibilities: >=20 > 1) at one end of the spectrum, if "lost routes" are to > be avoided at all costs, then the rules for parsing > attributes need to be tight and without a change at > the sender end, what is achievable is constrained. >=20 > 2) if "lost routes" are acceptable in the "theoretical" > cases, but you-know-and-I-know that most of the > time the case will not arise... >=20 > ...or "lost routes" are acceptable provided some > defined steps are taken to identify as much NLRI > as is reasonably possible... >=20 > ...then the requirements need to (a) make the case > and (b) describe the trade-off (so that designs > made to follow the requirements can be judged in > those terms). >=20 > 3) at the other end of the spectrum, if "lost routes" > are always preferable to session-reset, then this > opens up an even looser approach to UPDATE message > handling, in which practically nothing need cause > a session-reset -- ie, practically nothing is a > Critical Error. >=20 > And, as I have suggested in previous discussions, it is possible to > consider case (2) in two parts: >=20 > a) where the sender is unchanged. >=20 > In which case the issue is the degree of attribute > broken-ness vs the likelihood of "lost routes". >=20 > If this is viewed as an intermediate step, then > perhaps the requirements could err on the side of > safety ? >=20 > Perhaps this can be addressed by a "knob" allowing > more or less strictness in the parsing of > attributes ? >=20 > b) where the sender is changed. >=20 > In which case the issue ought to be moot, because > the receiver will then be able to know that there > are no "lost routes". >=20 > > I would also appreciate further input from IDR as to whether this is > > sufficient requirement from GROW to allow a solution document to be > > written? >=20 > The new requirements specify only Critical (session-reset) and > Non-Critical (treat-as-withdraw) Errors. This appears to rule out the > "attribute discard" option in draft-ietf-idr-error-handling-03. Is > that intended ? >=20 > Chris >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --Apple-Mail=_81DB352D-E036-47D8-9A50-6E15BB53EFB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Brian,

We discussed this at some length previously = (the -00 of the requirements draft discussed automatically triggering = some form of means to recover from the error). I think that there is = some merit in doing so, but there are clearly also scaling = considerations around this (in terms of requiring both BGP speakers to = re-generate/re-process UPDATEs). 

The = consensus that was reached in the previous discussion was that this is = not necessarily going to be of advantage in terms of causing a different = UPDATE message to be generated. Particularly, since a ROUTE REFRESH = would result in the same UPDATE packing (generally). To that end, what = the requirements draft currently says is = that:

- ROUTE-REFRESH is a reasonable way to = re-run a consistency check between two peers (especially with = start-of-refresh and end-of-refresh markers, since this means that we = can purge any NLRI that we missed being withdrawn).
- If there = is anything automatically triggered, it would be prudent to try and = ensure that we can make as specific a request to the other speaker as = possible - this is where mechanisms such as One-Time ORF were suggested, = and is a similar space to that which would be solved through having the = UPDATE-VERSION message described in draft-ietf-idr-enhanced-gr if one = were to be able to have a REFRESH following a "last known good" = position. Making a more specific request may result in a different = UPDATE being generated, which may mean the error is fixed, but this is = not guaranteed.
- If the selected best path changes on the = remote speaker, then it will be re-advertised anyway - resulting in = another chance to re-parse these NLRI.

So, = certainly, if we relax the "correctness" requirement, then it would seem = a good idea to have some means to be able to consistency check -- it's = just a matter of ensuring that this is done in an effective and scalable = manner, that does not affect normal BGP = operation.

Cheers,
r.


On 28 Dec 2012, at 19:02, Brian Dickson <brian.peter.dickson@gmail.co= m> wrote:

Here's a quick question, about possible mechanisms for = determining whether or not we need to tear down a = session.

If there is a chance that some NLRI weren't = properly decoded:

- What about requesting (presuming the option was negotiated) a = route-refresh, or a "confirm per-AFI-SAFI prefix = list"?

It's an expensive "parity check" but is = one way of ensuring that we haven't missed a withdrawn prefix.
If it isn't in the subsequently received list of prefixes, we = missed it and should withdraw it.
Everything else is a no-op - = maybe we missed a new prefix (with new attribute?), but that is what = "treat as withdraw" gets you.

Just trying to make sure the cure isn't worse than = the disease, in all situations.
(Where "cure" is fail to = withdraw because we "lost" the withdrawal because of malformed update, = or "cure" is tear down the session.)

Brian

On Fri, Dec = 28, 2012 at 1:04 PM, Chris Hall <chris.hall@highwayman.com> wrote:
Rob Shakir wrote (on = Fri 28-Dec-2012 at 13:10 +0000):
>
> (re: CCing IDR & GROW)
>
> On 28 Dec 2012, at 12:28, Chris Hall wrote:
>
> > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44):
> >>
> >> Any comments very welcome (to me or grow@).

> > I'm afraid I still don't get it :-(  What am I missing = ?
> >
> > UPDATE Message Length errors are Critical because they:
> >
> > (1) "result in cases whereby the NLRI attribute cannot
> >      be correctly extracted".
> >
> > The implication is that a failure to extract all NLRI is = Critical.
> > Is that a requirement ?

> If the NLRI cannot be determined, then this is a Critical = error,
> yes. I left the wording relatively open on whether this is = *all*
> NLRI, ...

OK.  So, if the message is broken (in any way):

  * if no NLRI can be found, that's a Critical Error.

    That would include the case where some broken
    attribute upstream of any MP_XXX obscures that
    MP_XXX.

  * if some NLRI can be found, that's a Non-Critical error.

    Such NLRI as can be found are treated-as-withdraw.

    AND any NLRI that may or may not have been lost, are
    ignored.

    AND whatever dangers lost NLRI may pose are covered
    by the caveats in 4.1.

Yes ?

> ... as I am not sure that in the requirements draft we should
> specify direct solutions to specific issues, to = e.g., say how to
> handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the = same
> message [this is a case that I do not believe is forbidden by
> rfc2858 - if the working group could clarify whether this is
> something that we feel the draft needs to handle or can = explicitly
> be omitted, then that would be appreciated].

The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable = in
the body of the message, with or without MP_REACH_NLRI and/or
MP_UNREACH_NLRI.  If we call each of these a "collection of = NLRI",
then there may be between 1 and 4 collections of NLRI in a message
(ignoring the End-of-RIB pseudo-UPDATE).  It is an error to have = more
than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI
attribute.  It is not clear to me whether those should be = Critical
Errors -- but while we are relaxing all error checking, I don't see
why they should be.

It is possible that most implementations actually only send one
collection per message... so, as you suggest, on a = you-know-and-I-know
basis, we'all could ignore the "theoretical" issues of more than one
collection in a message.

But, this does not matter if the requirements allow lost NLRI to
simply be ignored.  If the sender sends any MP_XXX first, then = there
is little chance that NLRI will be lost, and things work better. =  If
the sender follows the old rules, and particularly if it sends more
than one collection at a time, then there is more chance that NLRI
will be lost.

> > Later:
> >
> >  (2) "All errors whereby the contained NLRI can be
> >       extracted are referred to as = Non-Critical".
> >
> > And that includes:
> >
> >  (3) "where the length of all path attributes = contained
> >       within the UPDATE does not correspond to = the
> >       total path attribute length."
> >
> > That is, at least, more explicit than
> > draft-ietf-idr-error-handling-03, which glosses over (3).
> >
> > But if (3) is non-critical then there is some chance that
> > some NLRI will not be extracted, which appears to violate
> > (1) and (2).

> Disclaimer: As I am sure that my comments previously have made
> clear, I do not maintain a code base for a BGP = daemon/implementation
> - so please feel free to correct my logic below.
>
> I do not believe that (3) implies that the NLRI cannot be = correctly
> found.

What (3) implies to me is that somewhere amongst the = attributes
something is broken.  As Jakob Heitz succinctly puts it: "Once = you
have a malformed update, NOTHING is certain."  In particular, = you
cannot be certain that all NLRI referred to by the sender can be = found
by the receiver.

> If the sum of total length is incorrect, then we can still
> extract the individual attributes - we just find that there is = not
> enough data to fill the overall length we were told and/or we = have
> too much attribute data compared to the total attribute length.

This is precisely where I think the requirements come unstuck. =  There
is almost no redundancy in the attribute encoding.  And almost all = the
redundancy there is is discarded by the new-form-error-handling. =  So,
if the sum of the attribute lengths is incorrect, then (inter alia)
the receiver CANNOT know whether the attributes it has extracted are
the attributes the sender intended to send.  In particular, the
receiver cannot know it has extracted all NLRI (except in the,
probably obscure, case of having extracted both MP_REACH_NLRI and
MP_UNREACH_NLRI).  "Once you have a malformed update, NOTHING = is
certain."

Conversely, if the sum of attribute lengths is correct, then there = is
a fighting chance that the attributes received are the attributes
sent.  But, if one of those attributes is (say) nominally an
ATOMIC_AGGREGATE which is apparently 200 octets long, that might be = a
worry.

...
> > Then (4) "In order to maximise the number of = cases whereby the
> > NLRI attributes [plural, now, BTW] can be reliably = extracted
> > from a received message...".  Ah.  So it is not a = Critical
> > Error if "the NLRI attribute cannot be correctly = extracted".

> No - it is a Critical error if we cannot extract the NLRI. This
> recommendation is to give an increased chance that the NLRI can = be
> extracted as per the IDR error handling draft. This then (by = virtue
> of resulting in the NLRI being extracted) minimises the number = of
> cases that result in a Critical error.

By this do you mean "all" NLRI or only "some" NLRI ?  As = above.

> The plural here is to reflect
> that the existence of >1 type of NLRI attribute.

That would imply that it should be "NLRI attributes" throughout = ?
Though in most places where the draft speaks of "NLRI attribute" I
think it means one, some, any or all of the "collections of NLRI" = (as
defined above).

> > For me the requirement remains "conflicted".  On the one = hand it
> > seems to say that it is a Critical Error if the NLRI cannot = be
> > extracted and parsed.  On the other it seems to say it's = OK if
> > you cannot extract some NLRI.

> If you'll forgive me for removing a significant proportion of = your
> message, I think that we need to take another step back here. = It
> seems to me that the key question that you are highlighting is = "What
> level of confidence do we need to have before we declare that = the
> NLRI cannot be extracted?" -- do you agree?

Absolutely.

> =46rom an operator perspective, I would like to compromise = *certainty*
> for *robustness*. You are right, we are compromising = correctness
> here, we might end up withdrawing an incorrect NLRI and = impacting
> service operation for that prefix - however, it is somewhat
> preferable to me to withdraw a a subset of the NLRI = incorrectly,
> rather than impact all NLRI in one single action. We clearly need = to
> provide some bounds on how much we compromise the certainty = (and
> live within the realms of possibility, such that we are not = just
> taking a shot in the dark). This is what the definitions of = Critical
> and Non-Critical within the document are intended to provide. = Once
> again I will refer to the requirement that there is a balance
> between correctness and robustness - rather than a locally risk
> averse approach that results in harmful wider behaviour.

Where one can extract the NLRI from a broken message, then
treat-as-withdraw is AFAICS no worse for the NLRI in question than
session-reset, and hugely better for all the other NLRI received = from
the peer.

Where not *all* the NLRI in a message have been extracted, then we
take a step beyond withdrawing something which should not have been
withdrawn.  For each of those NLRI the receiver will (unknowingly) = do
one of:

  (a) continue using a route which the sender has
      withdrawn;

  (b) continue to use an out of date version of a route
      which the sender has changed in some way, = possibly
      materially;

  (c) to fail to use a new route the sender has now made
      available.

Of these (a) looks serious and (b) could be, but certainly the = effect
is different from session-reset; while (c) is, essentially,
treat-as-withdraw.  If some risk "lost routes" is taken, then = the
impact of that clearly must be weighed against the impact of
session-reset.  I have not found a discussion of the impact of = "lost
routes" in the draft, so I have no idea what the trade-off is, here.

For completeness, if all forms and degrees of attribute broken-ness
are required to be acceptable, then there are cases where the = receiver
cannot know whether *all* NLRI have been extracted, or not.

> Is it acceptable that we leave this as guidance within the
> requirements? If not, please could you suggest how the = definitions
> of Critical/Non-Critical could be altered to address your = concerns?

Without a change at the sender end, the problem is that: "Once = you
have a malformed update, NOTHING is certain."

So, as I said earlier, the fundamental question is:

  (F) is it OK to continue with a session after processing
      a message which may have contained some NLRI = which
      could not be extracted ?

As you say, the question hinges on the "which may have contained". =  As
above, it seems to me that the draft skates over the issue of "lost
routes".

It also hinges on the operational impact of such "lost routes", on
which I am unqualified to pronounce.

It seems to me there is a range of possibilities:

  1) at one end of the spectrum, if "lost routes" are to
     be avoided at all costs, then the rules for = parsing
     attributes need to be tight and without a change = at
     the sender end, what is achievable is = constrained.

  2) if "lost routes" are acceptable in the "theoretical"
     cases, but you-know-and-I-know that most of the
     time the case will not arise...

     ...or "lost routes" are acceptable provided some
     defined steps are taken to identify as much NLRI
     as is reasonably possible...

     ...then the requirements need to (a) make the = case
     and (b) describe the trade-off (so that designs
     made to follow the requirements can be judged in
     those terms).

  3) at the other end of the spectrum, if "lost routes"
     are always preferable to session-reset, then = this
     opens up an even looser approach to UPDATE = message
     handling, in which practically nothing need = cause
     a session-reset -- ie, practically nothing is a
     Critical Error.

And, as I have suggested in previous discussions, it is possible to
consider case (2) in two parts:

  a) where the sender is unchanged.

     In which case the issue is the degree of = attribute
     broken-ness vs the likelihood of "lost routes".

     If this is viewed as an intermediate step, then
     perhaps the requirements could err on the side = of
     safety ?

     Perhaps this can be addressed by a "knob" = allowing
     more or less strictness in the parsing of
     attributes ?

  b) where the sender is changed.

     In which case the issue ought to be moot, = because
     the receiver will then be able to know that = there
     are no "lost routes".

> I would also appreciate further input from IDR as to whether this = is
> sufficient requirement from GROW to allow a solution document to = be
> written?

The new requirements specify only Critical (session-reset) and
Non-Critical (treat-as-withdraw) Errors.  This appears to rule out = the
"attribute discard" option in draft-ietf-idr-error-handling-03. =  Is
that intended ?

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


= --Apple-Mail=_81DB352D-E036-47D8-9A50-6E15BB53EFB2-- From brian.peter.dickson@gmail.com Sun Dec 30 13:34:41 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04221F8A90; Sun, 30 Dec 2012 13:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-2.913, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28XwVK2c+11e; Sun, 30 Dec 2012 13:34:39 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id B14AE21F8A8F; Sun, 30 Dec 2012 13:34:38 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i13so4898737eaa.18 for ; Sun, 30 Dec 2012 13:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aZNEA/DXolsdywbVDMA7T/CsQDdpVPBkZaej74CivQA=; b=gUEPjeQF730gH6BBtZmV4+J/1/1YE5tOH0VidE/ggNc5ogp0so+kkSfwXTc5FwB4qo CsH6a7zqHBkHtUeRO8m0xr2lYdeIrVLmFz6vYroDuv0WMJ4r5OakBv0dORBdMPNi2cgY 6m2S8NS9gqhxO7bKCskFD0HD+SHgGovAsliSjvwWK42rtGcXo9llAx3RXBkA9ShvrSan ZxcDTrpH39i2ihNQ2Vt3C8decUQOw/NTToRkSZ0HY38SRNsRU/kOZd82gwd5CIr9AkX4 elDNakWL8ogkFkJD6FZmcFAf4ap9+NTePwFNVqWew1sZB0m2R5yYZrHQZ9p9unld0etc 1m8Q== MIME-Version: 1.0 Received: by 10.14.223.200 with SMTP id v48mr105497810eep.24.1356903277757; Sun, 30 Dec 2012 13:34:37 -0800 (PST) Received: by 10.223.173.199 with HTTP; Sun, 30 Dec 2012 13:34:37 -0800 (PST) In-Reply-To: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> Date: Sun, 30 Dec 2012 16:34:37 -0500 Message-ID: From: Brian Dickson To: Rob Shakir Content-Type: multipart/alternative; boundary=047d7b622820dd839904d218a9ee Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 21:34:41 -0000 --047d7b622820dd839904d218a9ee Content-Type: text/plain; charset=ISO-8859-1 Here's the basic problem in a nutshell: If a WITHDRAW is missed (either standard or MP), there are two possibilities concerning withdrawn NLRIs: - the WITHDRAW was sent because the sender no longer HAS a route to the destination, or - the WITHDRAW was sent because the sender now prefers the route via the recipient In the former case, losing the WITHDRAW means that the recipient, if it selects that route as BEST, will now BLACKHOLE the traffic. In the latter case, it might be possible for a routing loop to be caused (although, I think most of the time this won't be possible unless there was already a missed WITHDRAW in the other direction). But, the basic problem is this: missing an UPDATE won't trigger either condition, it will at worst cause sub-optimal routing. Missing a WITHDRAW _CAN_ cause Bad Things (TM) to happen. So, it is important to accommodate this in the requirements, possibly requiring a very slight change in required message packing, in order to guarantee that these Bad Things do not happen. Today, those Bad Things can't happen when a session tear-down occurs. There are a couple of easy ways to ensure the WITHDRAW is not missed: - Pack all the WITHDRAW stuff at the start - Require that no UPDATE be sent in the same MESSAGE as a WITHDRAW, and preferably limit WITHDRAW to one AFI/SAFI per MESSAGE It's clean, has relatively modest requirements, and ensures that a broken WITHDRAW can trigger the correct result (tear-down), and any other broken UPDATE can be handled with Treat-As-Withdraw. IMNSHO, routing loops and/or black holes (for even a single prefix) are not an acceptable situation. There are other approaches that can be take to avoid this as well, but I think KISS is the best approach. Brian On Sat, Dec 29, 2012 at 7:05 PM, Rob Shakir wrote: > Hi Brian, > > We discussed this at some length previously (the -00 of the requirements > draft discussed automatically triggering some form of means to recover from > the error). I think that there is some merit in doing so, but there are > clearly also scaling considerations around this (in terms of requiring both > BGP speakers to re-generate/re-process UPDATEs). > > The consensus that was reached in the previous discussion was that this is > not necessarily going to be of advantage in terms of causing a different > UPDATE message to be generated. Particularly, since a ROUTE REFRESH would > result in the same UPDATE packing (generally). To that end, what the > requirements draft currently says is that: > > - ROUTE-REFRESH is a reasonable way to re-run a consistency check between > two peers (especially with start-of-refresh and end-of-refresh markers, > since this means that we can purge any NLRI that we missed being withdrawn). > - If there is anything automatically triggered, it would be prudent to try > and ensure that we can make as specific a request to the other speaker as > possible - this is where mechanisms such as One-Time ORF were suggested, > and is a similar space to that which would be solved through having the > UPDATE-VERSION message described in draft-ietf-idr-enhanced-gr if one were > to be able to have a REFRESH following a "last known good" position. Making > a more specific request may result in a different UPDATE being generated, > which may mean the error is fixed, but this is not guaranteed. > - If the selected best path changes on the remote speaker, then it will be > re-advertised anyway - resulting in another chance to re-parse these NLRI. > > So, certainly, if we relax the "correctness" requirement, then it would > seem a good idea to have some means to be able to consistency check -- it's > just a matter of ensuring that this is done in an effective and scalable > manner, that does not affect normal BGP operation. > > Cheers, > r. > > > On 28 Dec 2012, at 19:02, Brian Dickson > wrote: > > Here's a quick question, about possible mechanisms for determining whether > or not we need to tear down a session. > > If there is a chance that some NLRI weren't properly decoded: > > - What about requesting (presuming the option was negotiated) a > route-refresh, or a "confirm per-AFI-SAFI prefix list"? > > It's an expensive "parity check" but is one way of ensuring that we > haven't missed a withdrawn prefix. > If it isn't in the subsequently received list of prefixes, we missed it > and should withdraw it. > Everything else is a no-op - maybe we missed a new prefix (with new > attribute?), but that is what "treat as withdraw" gets you. > > Just trying to make sure the cure isn't worse than the disease, in all > situations. > (Where "cure" is fail to withdraw because we "lost" the withdrawal because > of malformed update, or "cure" is tear down the session.) > > Brian > > On Fri, Dec 28, 2012 at 1:04 PM, Chris Hall wrote: > >> Rob Shakir wrote (on Fri 28-Dec-2012 at 13:10 +0000): >> > >> > (re: CCing IDR & GROW) >> > >> > On 28 Dec 2012, at 12:28, Chris Hall wrote: >> > >> > > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44): >> > >> >> > >> Any comments very welcome (to me or grow@). >> >> > > I'm afraid I still don't get it :-( What am I missing ? >> > > >> > > UPDATE Message Length errors are Critical because they: >> > > >> > > (1) "result in cases whereby the NLRI attribute cannot >> > > be correctly extracted". >> > > >> > > The implication is that a failure to extract all NLRI is Critical. >> > > Is that a requirement ? >> >> > If the NLRI cannot be determined, then this is a Critical error, >> > yes. I left the wording relatively open on whether this is *all* >> > NLRI, ... >> >> OK. So, if the message is broken (in any way): >> >> * if no NLRI can be found, that's a Critical Error. >> >> That would include the case where some broken >> attribute upstream of any MP_XXX obscures that >> MP_XXX. >> >> * if some NLRI can be found, that's a Non-Critical error. >> >> Such NLRI as can be found are treated-as-withdraw. >> >> AND any NLRI that may or may not have been lost, are >> ignored. >> >> AND whatever dangers lost NLRI may pose are covered >> by the caveats in 4.1. >> >> Yes ? >> >> > ... as I am not sure that in the requirements draft we should >> > specify direct solutions to specific issues, to e.g., say how to >> > handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same >> > message [this is a case that I do not believe is forbidden by >> > rfc2858 - if the working group could clarify whether this is >> > something that we feel the draft needs to handle or can explicitly >> > be omitted, then that would be appreciated]. >> >> The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in >> the body of the message, with or without MP_REACH_NLRI and/or >> MP_UNREACH_NLRI. If we call each of these a "collection of NLRI", >> then there may be between 1 and 4 collections of NLRI in a message >> (ignoring the End-of-RIB pseudo-UPDATE). It is an error to have more >> than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI >> attribute. It is not clear to me whether those should be Critical >> Errors -- but while we are relaxing all error checking, I don't see >> why they should be. >> >> It is possible that most implementations actually only send one >> collection per message... so, as you suggest, on a you-know-and-I-know >> basis, we'all could ignore the "theoretical" issues of more than one >> collection in a message. >> >> But, this does not matter if the requirements allow lost NLRI to >> simply be ignored. If the sender sends any MP_XXX first, then there >> is little chance that NLRI will be lost, and things work better. If >> the sender follows the old rules, and particularly if it sends more >> than one collection at a time, then there is more chance that NLRI >> will be lost. >> >> > > Later: >> > > >> > > (2) "All errors whereby the contained NLRI can be >> > > extracted are referred to as Non-Critical". >> > > >> > > And that includes: >> > > >> > > (3) "where the length of all path attributes contained >> > > within the UPDATE does not correspond to the >> > > total path attribute length." >> > > >> > > That is, at least, more explicit than >> > > draft-ietf-idr-error-handling-03, which glosses over (3). >> > > >> > > But if (3) is non-critical then there is some chance that >> > > some NLRI will not be extracted, which appears to violate >> > > (1) and (2). >> >> > Disclaimer: As I am sure that my comments previously have made >> > clear, I do not maintain a code base for a BGP daemon/implementation >> > - so please feel free to correct my logic below. >> > >> > I do not believe that (3) implies that the NLRI cannot be correctly >> > found. >> >> What (3) implies to me is that somewhere amongst the attributes >> something is broken. As Jakob Heitz succinctly puts it: "Once you >> have a malformed update, NOTHING is certain." In particular, you >> cannot be certain that all NLRI referred to by the sender can be found >> by the receiver. >> >> > If the sum of total length is incorrect, then we can still >> > extract the individual attributes - we just find that there is not >> > enough data to fill the overall length we were told and/or we have >> > too much attribute data compared to the total attribute length. >> >> This is precisely where I think the requirements come unstuck. There >> is almost no redundancy in the attribute encoding. And almost all the >> redundancy there is is discarded by the new-form-error-handling. So, >> if the sum of the attribute lengths is incorrect, then (inter alia) >> the receiver CANNOT know whether the attributes it has extracted are >> the attributes the sender intended to send. In particular, the >> receiver cannot know it has extracted all NLRI (except in the, >> probably obscure, case of having extracted both MP_REACH_NLRI and >> MP_UNREACH_NLRI). "Once you have a malformed update, NOTHING is >> certain." >> >> Conversely, if the sum of attribute lengths is correct, then there is >> a fighting chance that the attributes received are the attributes >> sent. But, if one of those attributes is (say) nominally an >> ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a >> worry. >> >> ... >> > > Then (4) "In order to maximise the number of cases whereby the >> > > NLRI attributes [plural, now, BTW] can be reliably extracted >> > > from a received message...". Ah. So it is not a Critical >> > > Error if "the NLRI attribute cannot be correctly extracted". >> >> > No - it is a Critical error if we cannot extract the NLRI. This >> > recommendation is to give an increased chance that the NLRI can be >> > extracted as per the IDR error handling draft. This then (by virtue >> > of resulting in the NLRI being extracted) minimises the number of >> > cases that result in a Critical error. >> >> By this do you mean "all" NLRI or only "some" NLRI ? As above. >> >> > The plural here is to reflect >> > that the existence of >1 type of NLRI attribute. >> >> That would imply that it should be "NLRI attributes" throughout ? >> Though in most places where the draft speaks of "NLRI attribute" I >> think it means one, some, any or all of the "collections of NLRI" (as >> defined above). >> >> > > For me the requirement remains "conflicted". On the one hand it >> > > seems to say that it is a Critical Error if the NLRI cannot be >> > > extracted and parsed. On the other it seems to say it's OK if >> > > you cannot extract some NLRI. >> >> > If you'll forgive me for removing a significant proportion of your >> > message, I think that we need to take another step back here. It >> > seems to me that the key question that you are highlighting is "What >> > level of confidence do we need to have before we declare that the >> > NLRI cannot be extracted?" -- do you agree? >> >> Absolutely. >> >> > From an operator perspective, I would like to compromise *certainty* >> > for *robustness*. You are right, we are compromising correctness >> > here, we might end up withdrawing an incorrect NLRI and impacting >> > service operation for that prefix - however, it is somewhat >> > preferable to me to withdraw a a subset of the NLRI incorrectly, >> > rather than impact all NLRI in one single action. We clearly need to >> > provide some bounds on how much we compromise the certainty (and >> > live within the realms of possibility, such that we are not just >> > taking a shot in the dark). This is what the definitions of Critical >> > and Non-Critical within the document are intended to provide. Once >> > again I will refer to the requirement that there is a balance >> > between correctness and robustness - rather than a locally risk >> > averse approach that results in harmful wider behaviour. >> >> Where one can extract the NLRI from a broken message, then >> treat-as-withdraw is AFAICS no worse for the NLRI in question than >> session-reset, and hugely better for all the other NLRI received from >> the peer. >> >> Where not *all* the NLRI in a message have been extracted, then we >> take a step beyond withdrawing something which should not have been >> withdrawn. For each of those NLRI the receiver will (unknowingly) do >> one of: >> >> (a) continue using a route which the sender has >> withdrawn; >> >> (b) continue to use an out of date version of a route >> which the sender has changed in some way, possibly >> materially; >> >> (c) to fail to use a new route the sender has now made >> available. >> >> Of these (a) looks serious and (b) could be, but certainly the effect >> is different from session-reset; while (c) is, essentially, >> treat-as-withdraw. If some risk "lost routes" is taken, then the >> impact of that clearly must be weighed against the impact of >> session-reset. I have not found a discussion of the impact of "lost >> routes" in the draft, so I have no idea what the trade-off is, here. >> >> For completeness, if all forms and degrees of attribute broken-ness >> are required to be acceptable, then there are cases where the receiver >> cannot know whether *all* NLRI have been extracted, or not. >> >> > Is it acceptable that we leave this as guidance within the >> > requirements? If not, please could you suggest how the definitions >> > of Critical/Non-Critical could be altered to address your concerns? >> >> Without a change at the sender end, the problem is that: "Once you >> have a malformed update, NOTHING is certain." >> >> So, as I said earlier, the fundamental question is: >> >> (F) is it OK to continue with a session after processing >> a message which may have contained some NLRI which >> could not be extracted ? >> >> As you say, the question hinges on the "which may have contained". As >> above, it seems to me that the draft skates over the issue of "lost >> routes". >> >> It also hinges on the operational impact of such "lost routes", on >> which I am unqualified to pronounce. >> >> It seems to me there is a range of possibilities: >> >> 1) at one end of the spectrum, if "lost routes" are to >> be avoided at all costs, then the rules for parsing >> attributes need to be tight and without a change at >> the sender end, what is achievable is constrained. >> >> 2) if "lost routes" are acceptable in the "theoretical" >> cases, but you-know-and-I-know that most of the >> time the case will not arise... >> >> ...or "lost routes" are acceptable provided some >> defined steps are taken to identify as much NLRI >> as is reasonably possible... >> >> ...then the requirements need to (a) make the case >> and (b) describe the trade-off (so that designs >> made to follow the requirements can be judged in >> those terms). >> >> 3) at the other end of the spectrum, if "lost routes" >> are always preferable to session-reset, then this >> opens up an even looser approach to UPDATE message >> handling, in which practically nothing need cause >> a session-reset -- ie, practically nothing is a >> Critical Error. >> >> And, as I have suggested in previous discussions, it is possible to >> consider case (2) in two parts: >> >> a) where the sender is unchanged. >> >> In which case the issue is the degree of attribute >> broken-ness vs the likelihood of "lost routes". >> >> If this is viewed as an intermediate step, then >> perhaps the requirements could err on the side of >> safety ? >> >> Perhaps this can be addressed by a "knob" allowing >> more or less strictness in the parsing of >> attributes ? >> >> b) where the sender is changed. >> >> In which case the issue ought to be moot, because >> the receiver will then be able to know that there >> are no "lost routes". >> >> > I would also appreciate further input from IDR as to whether this is >> > sufficient requirement from GROW to allow a solution document to be >> > written? >> >> The new requirements specify only Critical (session-reset) and >> Non-Critical (treat-as-withdraw) Errors. This appears to rule out the >> "attribute discard" option in draft-ietf-idr-error-handling-03. Is >> that intended ? >> >> Chris >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > > --047d7b622820dd839904d218a9ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's the basic problem in a nutshell:

If a WITHDRA= W is missed (either standard or MP), there are two possibilities concerning= withdrawn NLRIs:
- the WITHDRAW was sent because the sender no l= onger HAS a route to the destination, or
- the WITHDRAW was sent because the sender now prefers the route via t= he recipient

In the former case, losing the WITHDR= AW means that the recipient, if it selects that route as BEST, will now BLA= CKHOLE the traffic.
In the latter case, it might be possible for a routing loop to be caus= ed (although, I think most of the time this won't be possible unless th= ere was already a missed WITHDRAW in the other direction).

But, the basic problem is this: missing an UPDATE won't trig= ger either condition, it will at worst cause sub-optimal routing. Missing a= WITHDRAW _CAN_ cause Bad Things (TM) to happen.

So, it is important to accommodate this in the requirements, possibly requi= ring a very slight change in required message packing, in order to guarante= e that these Bad Things do not happen.

Today, thos= e Bad Things can't happen when a session tear-down occurs.

There are a couple of easy ways to ensure the WITHDRAW = is not missed:
- Pack all the WITHDRAW stuff at the start
- Require that no UPDATE be sent in the same MESSAGE as a WITHDRAW, and = preferably limit WITHDRAW to one AFI/SAFI per MESSAGE

It's clean, has relatively modest requirements, and= ensures that a broken WITHDRAW can trigger the correct result (tear-down),= and any other broken UPDATE can be handled with Treat-As-Withdraw.

IMNSHO, routing loops and/or black holes (for even a si= ngle prefix) are not an acceptable situation.

Ther= e are other approaches that can be take to avoid this as well, but I think = KISS is the best approach.

Brian

On Sat, = Dec 29, 2012 at 7:05 PM, Rob Shakir <rjs@rob.sh> wrote:
Hi Brian,

We discuss= ed this at some length previously (the -00 of the requirements draft discus= sed automatically triggering some form of means to recover from the error).= I think that there is some merit in doing so, but there are clearly also s= caling considerations around this (in terms of requiring both BGP speakers = to re-generate/re-process UPDATEs).=A0

The consensus that was reached in the previous discussi= on was that this is not necessarily going to be of advantage in terms of ca= using a different UPDATE message to be generated. Particularly, since a ROU= TE REFRESH would result in the same UPDATE packing (generally). To that end= , what the requirements draft currently says is that:

- ROUTE-REFRESH is a reasonable way to re-run a consist= ency check between two peers (especially with start-of-refresh and end-of-r= efresh markers, since this means that we can purge any NLRI that we missed = being withdrawn).
- If there is anything automatically triggered, it would be prudent to= try and ensure that we can make as specific a request to the other speaker= as possible - this is where mechanisms such as One-Time ORF were suggested= , and is a similar space to that which would be solved through having the U= PDATE-VERSION message described in draft-ietf-idr-enhanced-gr if one were t= o be able to have a REFRESH following a "last known good" positio= n. Making a more specific request may result in a different UPDATE being ge= nerated, which may mean the error is fixed, but this is not guaranteed.
- If the selected best path changes on the remote speaker, then it wil= l be re-advertised anyway - resulting in another chance to re-parse these N= LRI.

So, certainly, if we relax the "correctn= ess" requirement, then it would seem a good idea to have some means to= be able to consistency check -- it's just a matter of ensuring that th= is is done in an effective and scalable manner, that does not affect normal= BGP operation.

Cheers,
r.
<= br>

On 28 Dec 2012, at 19:02, Brian Dickson <brian.peter= .dickson@gmail.com> wrote:

Here's a quick question, about possible m= echanisms for determining whether or not we need to tear down a session.
If there is a chance that some NLRI weren't properly d= ecoded:

- What about requesting (presuming the option was negotiated) a route-= refresh, or a "confirm per-AFI-SAFI prefix list"?

<= /div>
It's an expensive "parity check" but is one way of = ensuring that we haven't missed a withdrawn prefix.
If it isn't in the subsequently received list of prefixes, we miss= ed it and should withdraw it.
Everything else is a no-op - maybe = we missed a new prefix (with new attribute?), but that is what "treat = as withdraw" gets you.

Just trying to make sure the cure isn't worse than = the disease, in all situations.
(Where "cure" is fail t= o withdraw because we "lost" the withdrawal because of malformed = update, or "cure" is tear down the session.)

Brian

On Fri, Dec 28,= 2012 at 1:04 PM, Chris Hall <chris.hall@highwayman.com> wrote:
Rob Shakir wrote (on Fri 28-Dec-2012 at 13:1= 0 +0000):
>
> (re: CCing IDR & GROW)
>
> On 28 Dec 2012, at 12:28, Chris Hall wrote:
>
> > Rob Shakir wrote (on Thu 27-Dec-2012 at 18:44):
> >>
> >> Any comments very welcome (to me or grow@).

> > I'm afraid I still don't get it :-( =A0What am I missing = ?
> >
> > UPDATE Message Length errors are Critical because they:
> >
> > (1) "result in cases whereby the NLRI attribute cannot
> > =A0 =A0 =A0be correctly extracted".
> >
> > The implication is that a failure to extract all NLRI is Critical= .
> > Is that a requirement ?

> If the NLRI cannot be determined, then this is a Critical error,
> yes. I left the wording relatively open on whether this is *all*
> NLRI, ...

OK. =A0So, if the message is broken (in any way):

=A0 * if no NLRI can be found, that's a Critical Error.

=A0 =A0 That would include the case where some broken
=A0 =A0 attribute upstream of any MP_XXX obscures that
=A0 =A0 MP_XXX.

=A0 * if some NLRI can be found, that's a Non-Critical error.

=A0 =A0 Such NLRI as can be found are treated-as-withdraw.

=A0 =A0 AND any NLRI that may or may not have been lost, are
=A0 =A0 ignored.

=A0 =A0 AND whatever dangers lost NLRI may pose are covered
=A0 =A0 by the caveats in 4.1.

Yes ?

> ... as I am not sure that in the requirements draft we should
> specify direct solutions to specific issues, to e.g., say how to<= br> > handle cases where MP_REACH_NLRI and MP_UNREACH_NLRI are in the same > message [this is a case that I do not believe is forbidden by
> rfc2858 - if the working group could clarify whether this is
> something that we feel the draft needs to handle or can explicitly
> be omitted, then that would be appreciated].

The RFCs also allow any mix of IPv4 Unicast Reachable/Unreachable in<= br> the body of the message, with or without MP_REACH_NLRI and/or
MP_UNREACH_NLRI. =A0If we call each of these a "collection of NLRI&quo= t;,
then there may be between 1 and 4 collections of NLRI in a message
(ignoring the End-of-RIB pseudo-UPDATE). =A0It is an error to have more
than one MP_REACH_NLRI attribute or more than one MP_UNREACH_NLRI
attribute. =A0It is not clear to me whether those should be Critical
Errors -- but while we are relaxing all error checking, I don't see
why they should be.

It is possible that most implementations actually only send one
collection per message... so, as you suggest, on a you-know-and-I-know
basis, we'all could ignore the "theoretical" issues of more t= han one
collection in a message.

But, this does not matter if the requirements allow lost NLRI to
simply be ignored. =A0If the sender sends any MP_XXX first, then there
is little chance that NLRI will be lost, and things work better. =A0If
the sender follows the old rules, and particularly if it sends more
than one collection at a time, then there is more chance that NLRI
will be lost.

> > Later:
> >
> > =A0(2) "All errors whereby the contained NLRI can be
> > =A0 =A0 =A0 extracted are referred to as Non-Critical".
> >
> > And that includes:
> >
> > =A0(3) "where the length of all path attributes contained > > =A0 =A0 =A0 within the UPDATE does not correspond to the
> > =A0 =A0 =A0 total path attribute length."
> >
> > That is, at least, more explicit than
> > draft-ietf-idr-error-handling-03, which glosses over (3).
> >
> > But if (3) is non-critical then there is some chance that
> > some NLRI will not be extracted, which appears to violate
> > (1) and (2).

> Disclaimer: As I am sure that my comments previously have made
> clear, I do not maintain a code base for a BGP daemon/implementation > - so please feel free to correct my logic below.
>
> I do not believe that (3) implies that the NLRI cannot be correctly > found.

What (3) implies to me is that somewhere amongst the attributes
something is broken. =A0As Jakob Heitz succinctly puts it: "Once you have a malformed update, NOTHING is certain." =A0In particular, you cannot be certain that all NLRI referred to by the sender can be found
by the receiver.

> If the sum of total length is incorrect, then we can still
> extract the individual attributes - we just find that there is not
> enough data to fill the overall length we were told and/or we have
> too much attribute data compared to the total attribute length.

This is precisely where I think the requirements come unstuck. =A0The= re
is almost no redundancy in the attribute encoding. =A0And almost all the redundancy there is is discarded by the new-form-error-handling. =A0So,
if the sum of the attribute lengths is incorrect, then (inter alia)
the receiver CANNOT know whether the attributes it has extracted are
the attributes the sender intended to send. =A0In particular, the
receiver cannot know it has extracted all NLRI (except in the,
probably obscure, case of having extracted both MP_REACH_NLRI and
MP_UNREACH_NLRI). =A0"Once you have a malformed update, NOTHING is
certain."

Conversely, if the sum of attribute lengths is correct, then there is
a fighting chance that the attributes received are the attributes
sent. =A0But, if one of those attributes is (say) nominally an
ATOMIC_AGGREGATE which is apparently 200 octets long, that might be a
worry.

...
> > Then (4) "In order to maximise the number of cases wher= eby the
> > NLRI attributes [plural, now, BTW] can be reliably extracted
> > from a received message...". =A0Ah. =A0So it is not a Critic= al
> > Error if "the NLRI attribute cannot be correctly extracted&q= uot;.

> No - it is a Critical error if we cannot extract the NLRI. This
> recommendation is to give an increased chance that the NLRI can be
> extracted as per the IDR error handling draft. This then (by virtue > of resulting in the NLRI being extracted) minimises the number of
> cases that result in a Critical error.

By this do you mean "all" NLRI or only "some" NLR= I ? =A0As above.

> The plural here is to reflect
> that the existence of >1 type of NLRI attribute.

That would imply that it should be "NLRI attributes" throug= hout ?
Though in most places where the draft speaks of "NLRI attribute" = I
think it means one, some, any or all of the "collections of NLRI"= (as
defined above).

> > For me the requirement remains "conflicted". =A0On the = one hand it
> > seems to say that it is a Critical Error if the NLRI cannot be > > extracted and parsed. =A0On the other it seems to say it's OK= if
> > you cannot extract some NLRI.

> If you'll forgive me for removing a significant proportion of your=
> message, I think that we need to take another step back here. It
> seems to me that the key question that you are highlighting is "W= hat
> level of confidence do we need to have before we declare that the
> NLRI cannot be extracted?" -- do you agree?

Absolutely.

> From an operator perspective, I would like to compromise *certainty* > for *robustness*. You are right, we are compromising correctness
> here, we might end up withdrawing an incorrect NLRI and impacting
> service operation for that prefix - however, it is somewhat
> preferable to me to withdraw a a subset of the NLRI incorrectly,
> rather than impact all NLRI in one single action. We clearly need to > provide some bounds on how much we compromise the certainty (and
> live within the realms of possibility, such that we are not just
> taking a shot in the dark). This is what the definitions of Critical > and Non-Critical within the document are intended to provide. Once
> again I will refer to the requirement that there is a balance
> between correctness and robustness - rather than a locally risk
> averse approach that results in harmful wider behaviour.

Where one can extract the NLRI from a broken message, then
treat-as-withdraw is AFAICS no worse for the NLRI in question than
session-reset, and hugely better for all the other NLRI received from
the peer.

Where not *all* the NLRI in a message have been extracted, then we
take a step beyond withdrawing something which should not have been
withdrawn. =A0For each of those NLRI the receiver will (unknowingly) do
one of:

=A0 (a) continue using a route which the sender has
=A0 =A0 =A0 withdrawn;

=A0 (b) continue to use an out of date version of a route
=A0 =A0 =A0 which the sender has changed in some way, possibly
=A0 =A0 =A0 materially;

=A0 (c) to fail to use a new route the sender has now made
=A0 =A0 =A0 available.

Of these (a) looks serious and (b) could be, but certainly the effect
is different from session-reset; while (c) is, essentially,
treat-as-withdraw. =A0If some risk "lost routes" is taken, then t= he
impact of that clearly must be weighed against the impact of
session-reset. =A0I have not found a discussion of the impact of "lost=
routes" in the draft, so I have no idea what the trade-off is, here.
For completeness, if all forms and degrees of attribute broken-ness
are required to be acceptable, then there are cases where the receiver
cannot know whether *all* NLRI have been extracted, or not.

> Is it acceptable that we leave this as guidance within the
> requirements? If not, please could you suggest how the definitions
> of Critical/Non-Critical could be altered to address your concerns?
Without a change at the sender end, the problem is that: "Once y= ou
have a malformed update, NOTHING is certain."

So, as I said earlier, the fundamental question is:

=A0 (F) is it OK to continue with a session after processing
=A0 =A0 =A0 a message which may have contained some NLRI which
=A0 =A0 =A0 could not be extracted ?

As you say, the question hinges on the "which may have contained"= . =A0As
above, it seems to me that the draft skates over the issue of "lost routes".

It also hinges on the operational impact of such "lost routes", o= n
which I am unqualified to pronounce.

It seems to me there is a range of possibilities:

=A0 1) at one end of the spectrum, if "lost routes" are to
=A0 =A0 =A0be avoided at all costs, then the rules for parsing
=A0 =A0 =A0attributes need to be tight and without a change at
=A0 =A0 =A0the sender end, what is achievable is constrained.

=A0 2) if "lost routes" are acceptable in the "theoretical&q= uot;
=A0 =A0 =A0cases, but you-know-and-I-know that most of the
=A0 =A0 =A0time the case will not arise...

=A0 =A0 =A0...or "lost routes" are acceptable provided some
=A0 =A0 =A0defined steps are taken to identify as much NLRI
=A0 =A0 =A0as is reasonably possible...

=A0 =A0 =A0...then the requirements need to (a) make the case
=A0 =A0 =A0and (b) describe the trade-off (so that designs
=A0 =A0 =A0made to follow the requirements can be judged in
=A0 =A0 =A0those terms).

=A0 3) at the other end of the spectrum, if "lost routes"
=A0 =A0 =A0are always preferable to session-reset, then this
=A0 =A0 =A0opens up an even looser approach to UPDATE message
=A0 =A0 =A0handling, in which practically nothing need cause
=A0 =A0 =A0a session-reset -- ie, practically nothing is a
=A0 =A0 =A0Critical Error.

And, as I have suggested in previous discussions, it is possible to
consider case (2) in two parts:

=A0 a) where the sender is unchanged.

=A0 =A0 =A0In which case the issue is the degree of attribute
=A0 =A0 =A0broken-ness vs the likelihood of "lost routes".

=A0 =A0 =A0If this is viewed as an intermediate step, then
=A0 =A0 =A0perhaps the requirements could err on the side of
=A0 =A0 =A0safety ?

=A0 =A0 =A0Perhaps this can be addressed by a "knob" allowing
=A0 =A0 =A0more or less strictness in the parsing of
=A0 =A0 =A0attributes ?

=A0 b) where the sender is changed.

=A0 =A0 =A0In which case the issue ought to be moot, because
=A0 =A0 =A0the receiver will then be able to know that there
=A0 =A0 =A0are no "lost routes".

> I would also appreciate further input from IDR as to whether this is > sufficient requirement from GROW to allow a solution document to be > written?

The new requirements specify only Critical (session-reset) and
Non-Critical (treat-as-withdraw) Errors. =A0This appears to rule out the "attribute discard" option in draft-ietf-idr-error-handling-03. = =A0Is
that intended ?

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr



--047d7b622820dd839904d218a9ee-- From john@jlc.net Sun Dec 30 19:09:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B018421F8BD5; Sun, 30 Dec 2012 19:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCdnkv5E6csm; Sun, 30 Dec 2012 19:09:25 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1592821F8BD1; Sun, 30 Dec 2012 19:09:25 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6CDFB33C26; Sun, 30 Dec 2012 22:09:25 -0500 (EST) Date: Sun, 30 Dec 2012 22:09:25 -0500 From: John Leslie To: Brian Dickson Message-ID: <20121231030925.GB62942@verdi> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 03:09:25 -0000 Brian Dickson wrote: > > But, the basic problem is this: missing an UPDATE won't trigger either > condition, it will at worst cause sub-optimal routing. Missing a WITHDRAW > _CAN_ cause Bad Things (TM) to happen. +1 -- John Leslie From jsw@inconcepts.biz Sun Dec 30 20:02:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE06C21F8A69 for ; Sun, 30 Dec 2012 20:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uWSpmH7SQcm for ; Sun, 30 Dec 2012 20:02:42 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id F1A9921F8B64 for ; Sun, 30 Dec 2012 20:02:41 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so10358078iad.27 for ; Sun, 30 Dec 2012 20:02:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=aPWyOGwBBa94G9A5Q7xPczFbDPqWmBNbXU2ctf0GXNE=; b=jNVwoqNDWgj63UMlBMFo6I7zqq74VsF/B0luPCPqgL9J0nxN3PTf+cAGpx3CHvtrDw WbkjcWahbYN6hnt9YohOjzpcQsR20We4TK1HioZ9EIl8QJoYWb6rd5aLGNVAGJfFEJpe QyUTDpUReEE6/i1S1x1bTLu4efsTxdKkqHys4cX/yGAJBgSc19LoV2VyiCj6R1+oI4tj 4tIBr/bgqbdvobPjoDxE9lK7BAoDmfcoh1kaQPoJ5T0/bvOqLStzkztQYwue/siWt5Tg jGrCKPb2sE7zz/TxJZ1VdmOMR3xhSIRE84JNATDoomaZPUiMel/ZWd649PVXrRrstZoh hQrg== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr34420278igb.45.1356926561449; Sun, 30 Dec 2012 20:02:41 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sun, 30 Dec 2012 20:02:41 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> Date: Sun, 30 Dec 2012 23:02:41 -0500 Message-ID: From: Jeff Wheeler To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm44AqSfpwKiIOBVUodtEydwgWUdprvRTNCxZ8Kb0/Kplp1GuNnQJBdy4/lF+x8+HgPWeSy Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 04:02:42 -0000 On Sun, Dec 30, 2012 at 4:34 PM, Brian Dickson wrote: > There are a couple of easy ways to ensure the WITHDRAW is not missed: > - Pack all the WITHDRAW stuff at the start > - Require that no UPDATE be sent in the same MESSAGE as a WITHDRAW, and > preferably limit WITHDRAW to one AFI/SAFI per MESSAGE The change you are proposing is sensible and has minimal cost to the control-plane CPU. BGP already can only have one, two, or three AFI/SAFI per Message. The reason it's "one, two, or three" is there can be native NLRI and MP-NLRI in one Message. You are not allowed to send more than one Attribute of the same Type Code in a BGP Message. There can't be two MP_REACH_NLRI or two MP_UNREACH_NLRI. The rule about one attribute per type code is kind of buried in RFC4271 section 6.3 paragraph 14. I imagine not everyone is aware of this because it really is not written into the spec in a way that it jumps out at you! Here is how this plus MP-BGP combine to allow up to three NLRI in the same Message: 1) native NLRI which are either reachable or withdrawn 2) NLRI inside an MP_REACH_NLRI Attribute 3) NLRI inside an MP_UNREACH_NLRI Attribute All three of those could possibly have distinct AFI/SAFI today. But it's not like it is possible to have NLRIs for 10 different AFIs in one Message today. I'm sure this discussion is related to draft-ietf-idr-error-handling. This draft does not call for a BGP Capability Code. It needs one if it expects the neighbor to behave in a certain way which differs from existing BGP requirements. I have posted some discussion about this on the IDR list recently but I do not read GROW. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rraszuk@gmail.com Mon Dec 31 01:21:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6144021F893E; Mon, 31 Dec 2012 01:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjuKeK-92tC9; Mon, 31 Dec 2012 01:21:01 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id CE67321F8925; Mon, 31 Dec 2012 01:21:00 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id 16so14698976iea.26 for ; Mon, 31 Dec 2012 01:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RmD2W5z6CoMaWL+QwRXx9YKoRYRjgtls3NRES6QB1oM=; b=jZKZLwLXINKxhdaI0mFWDZF9AWS8b0+3TmCAR/4Oyc839FyusUHmzljHTxmfvt7ZkM kdDtRIVnQKL7GQiIsC761ObeX9959+o5WwgaUfrGGMS1Cth+Trh+tSA0v3v/eVB+jpvV K5zhN6CNkfICSGfvNHKTzzTzFQLMBYa3fjB1+HNFCSV2RRb2OGjEWXzkzAOlbb3zxZ09 DjQH/qxnhGCMyV5jVrGMUt+gHapu/lSzt9AyyCqIxEsUJnbWhHGHT0PRgLwGgXBcXVGc SRfcFqVUUwOW7mFoSkCpc8fjVSKj+QDL45IkAlClpwccIfaSCFwvGul98Z0XIYi+aZ7a MS0g== MIME-Version: 1.0 Received: by 10.50.108.145 with SMTP id hk17mr35426541igb.51.1356945660446; Mon, 31 Dec 2012 01:21:00 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Mon, 31 Dec 2012 01:21:00 -0800 (PST) In-Reply-To: <20121231030925.GB62942@verdi> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <20121231030925.GB62942@verdi> Date: Mon, 31 Dec 2012 10:21:00 +0100 X-Google-Sender-Auth: Zt1RVNCfd_vE5MUKIO9VyblbZOY Message-ID: From: Robert Raszuk To: John Leslie , Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 09:21:02 -0000 How about if we would mandate Enhance Route Refresh request to be send to such peer who's bad updates triggered treat-as-withdraw action ? If we resync databases OK the likehood of "bad things" should be minimal. If we fail to sync (get another malformed update(s)) then IMHO resetting the session should be granted. Yes that means that "treat-as-withdraw" should be applied only to those peers which support Enhanced Route Refresh. Happy New Year, R. > On Mon, Dec 31, 2012 at 4:09 AM, John Leslie wrote: > > Brian Dickson wrote: >> >> But, the basic problem is this: missing an UPDATE won't trigger either >> condition, it will at worst cause sub-optimal routing. Missing a WITHDRAW >> _CAN_ cause Bad Things (TM) to happen. > > +1 > > -- > John Leslie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rjs@rob.sh Mon Dec 31 02:52:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBA821F85E6; Mon, 31 Dec 2012 02:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxbr5SBXvMYf; Mon, 31 Dec 2012 02:52:10 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 9752821F85DC; Mon, 31 Dec 2012 02:52:10 -0800 (PST) Received: from [46.65.174.227] (helo=latte.munster) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TpcvP-0008VP-HY; Mon, 31 Dec 2012 10:48:55 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Mon, 31 Dec 2012 10:52:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> To: Brian Dickson , Chris Hall , grow@ietf.org X-Mailer: Apple Mail (2.1283) Cc: idr@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 10:52:11 -0000 On 30 Dec 2012, at 21:34, Brian Dickson wrote: > But, the basic problem is this: missing an UPDATE won't trigger either = condition, it will at worst cause sub-optimal routing. Missing a = WITHDRAW _CAN_ cause Bad Things (TM) to happen. If we tear down the session based on a single bad UPDATE, then Bad = Things=99 happen. Worse still, these bad things happen to NLRI that are = not associated with the UPDATE that was erroneous and were supporting = live customer services. With modern deployments of BGP, the sessions = that are torn down can be relatively fundamental to network operation, = carry multiple (unrelated) customer topologies, and have significant = recovery times. Based on this, the tear-down behaviour has been shown to = have harmful effects to the operation of real networks based on real = world errors [0], and as per the draft that this thread is discussing. = There are a number of deployments in which this is not acceptable. We're spinning round the same loop here that was discussed a number of = times. Let me try and summarise this as accurately as I can: =20 As soon as we accept any kind of mechanism that targets error handling = to particular NLRI, we KNOW that we will compromise correctness. (As per = Section 4.1 of the draft) We also KNOW that this has a cost - which is = that we cannot be sure that the routing system is entirely consistent = any more, and we might end up with stale NLRI, routing loops, or = blackholing. The operational requirement described in this draft = highlight that this _IS_ the cost of robustness, and highlight the need = for operational monitoring and recovery mechanisms to support this = relaxation. Further to this, they highlight ways that the current = session-reset behaviour can be improved, particularly relevant in cases = where we CANNOT apply more targeted error handling. We are discussing whether we can wholly address the "when there has been = an error in an UPDATE, NOTHING is certain" - I would assert that we do = not need to. The fundamental premise here is that we are compromising = protocol correctness, which has a cost in terms consistency. = Operationally, paying this cost in order to keep numerous other services = up and running is acceptable. If this cost is not acceptable to an = operator, then such mechanisms SHOULD NOT be deployed. There is an argument that says that we could use a modified = session-reset based on NOTIFICATION after erroneous UPDATE approach for = all errors, however, since we also have a concern around longer-lived = errors (that are sourced by a remote speaker, and hence just repeated on = session reset), and the scalability of BGP routers, optimising such that = where it is possible to do so, we make minimal compromises to = correctness (i.e.., we compromise the correctness of a limited subset of = NLRI, where we can identify them) and maintain sessions is a key = requirement. If there are ways that we can improve the message packing in BGP such = that we minimise the risk of compromising correctness with NLRI-targeted = error handling, absolutely we should try and pursue these in = draft-ietf-idr-error-handling - however, I think that there is consensus = that error handling as a problem space is something we need to address, = since there are work items for this in both IDR and GROW. Would the GROW working group be happy if we address Chris' concern = related to "lost NLRI" (which AFAICS is really the case where we have >1 = type of NLRI attribute within a single message) by adding a note that an = error remains Non-Critical if _at least one_ NLRI attributes can be = successfully parsed? I'm unclear here as to whether we're addressing a = common situation where multiple sets of NLRI are being contained within = a single message [1]. If so, then adding "at least one" and then a = further point that an implementation SHOULD use a single NLRI attribute = per UPDATE message, and put this at the start of the attributes would = seem to be a fair way forward. Does this sound a reasonable way forward? If so, I will update this in = an -07, as well as addressing the editorial issues that Chris = highlighted earlier. Many thanks for your feedback. HNY! r. [0]: I enumerated a small number of real-world incidents back in 2011 = when I presented this work at NANOG (slides: = http://rob.sh/files/nanog-slides.pdf). There have been numerous = incidents since, alongside many incidents that the operators involved = were not willing to share more public details of. It would be a massive = shame to me that when the inevitable next incident like this turns up in = the DFZ, or internally to a SP network, we are still questioning the = validity of the problem space. [1]: Trawling a number PCAPs that I have, I can't find an UPDATE that = contained MP_REACH_NLRI and MP_UNREACH_NLRI simultaneously from a = multi-vendor L3VPN network. Another operator informs me that they have a = certain implementation that appears to include both in a single message. From rraszuk@gmail.com Mon Dec 31 04:49:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF6B21F8809; Mon, 31 Dec 2012 04:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqa1PO5TkSlm; Mon, 31 Dec 2012 04:49:44 -0800 (PST) Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE9821F87FD; Mon, 31 Dec 2012 04:49:44 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id y25so10539836iay.33 for ; Mon, 31 Dec 2012 04:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VR7fuH6mLNCBx17lAuSQ6nBDmEdzB8aPGXNX7F7+D0w=; b=K0/BZXw6MGF7Y2EtCccLcV+oU8oDOdiKlVbXlzFgsEZtll5/ssy5S6xKqz59cRQwF/ 747sUDd1qLTuglJuUyzLYRiq9imudmUYnu7Y5WX1HGJFwKFKWMrz9xnGbt+LfTzcqV6S NrZm38Q1s5LDhDMakh6eu774FbEAxjeNJIQ6r1AqhK4C5ba996Gp3paNzcdATaBsoVhZ TqV1oIoVXHov9TjU90I+GYLQdtrXaPtptz7kqlzMx8KIqOtJ9c5O2S/kHQCFDnTDSfpa YmMrMod0oi6jrAvuUXa2nCxR+uiNtbct9f29dakjZjamFGaTHmp/Gc56h/eQ9YM6hcnT nkOQ== MIME-Version: 1.0 Received: by 10.42.52.204 with SMTP id k12mr31273105icg.3.1356958182107; Mon, 31 Dec 2012 04:49:42 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Mon, 31 Dec 2012 04:49:41 -0800 (PST) In-Reply-To: <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> Date: Mon, 31 Dec 2012 13:49:41 +0100 X-Google-Sender-Auth: rkijlS_drze8eJsD437mDLMlkO0 Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 12:49:45 -0000 Hi Rob, > we are still questioning the validity of the problem space. I am not sure where do you draw such impression from ? I think we are all clear that there is problem .. from time to time a bleeding wound appears. However it seems that there is serious concern if the cure proposed is the right one. It appears that the treat-as-withdraw is a piece of duck tape so the rest of the body can sort of function. One could argue that while for some this may even work if the wound is small, imagine such duck tape being applied on 1 meter wound ? Moreover such cut will not recover under duck tape. So to me it seems this is a valid debate if it is better to reset the guy and send him to hospital for proper bandage or stitching while counting on the co-pilot(s) (other BGP sessions) to seamlessly carry the services for customers in the mean time. I think your draft and even the proposed solution is the best for the current BGP4 transport of messages for the cases where some bug is remote and you would likely end-up resetting perhaps all of your upstream sessions .. no doubt. But we have no way of knowing that network wide and I think this one of the problems. Clearly in this case it is better to put even duck tape on the pilots so they can try to land rather then sit and watch the plane crash. Actually real life example: I have discovered last week in one of BGP implementation that BGP conditional advertisement will not kick in till the trigger (check condition) disappears completely from BGP table even if it's next hop is no longer present in global RIB. One could call this a bug, but it is one example where while today I can automatically prefer other exit when session goes down with treat-as-withdraw and keep-the-session-up this will no longer work as trigger route will happily continue to sit in BGP table. And with treat-as-withdraw being default in some cases after new software upgrade your expected BGP behavior will change. I doubt you will find this example described in the release notes too ;) Best, R. From rjs@rob.sh Mon Dec 31 07:46:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9EF21F8877; Mon, 31 Dec 2012 07:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFm-BKNU1BfC; Mon, 31 Dec 2012 07:46:49 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id CC57221F84E9; Mon, 31 Dec 2012 07:46:43 -0800 (PST) Received: from [46.65.174.227] (helo=latte.munster) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TphWU-0001Go-4d; Mon, 31 Dec 2012 15:43:30 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: Date: Mon, 31 Dec 2012 15:46:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <31A90AE9-ACBC-4C5F-9A3D-A68CDB391F2C@rob.sh> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 15:46:49 -0000 Hi Robert, On 31 Dec 2012, at 12:49, Robert Raszuk wrote: > I think your draft and even the proposed solution is the best for the > current BGP4 transport of messages for the cases where some bug is > remote and you would likely end-up resetting perhaps all of your > upstream sessions .. no doubt. But we have no way of knowing that > network wide and I think this one of the problems. Clearly in this > case it is better to put even duck tape on the pilots so they can try > to land rather then sit and watch the plane crash. The previous discussions on this subject would seem to indicate that = there are a significant number of cases where treat-as-withdraw is seen = as the best approach for both non-Internet and Internet deployments. In = my view, the presence of other paths for particular NLRI does not = necessarily imply that they are equally viable (for both capacity and = cost reasons) - so maintaining as much of the network in the normal = operating state seems the most beneficial approach. To do this we need = some form of NLRI-level error handling. There are undoubtedly some deployment scenarios where it is not what the = operator wants for their network - and this may be the case for your = example(s). The requirements draft is not asserting that this is a MUST = and should be the default -- but rather outlining the motivation for = those operators who want error handling that applies to particular NLRI, = as well as the tools that are needed to make such error handling = deployable. If your preference is to err more on the side of caution (as = an operator, or an implementor) then there is no reason that one could = not always just have session-level error handling, with Enhanced GR = deployed within your network. I think we need to have both approaches - and note the caveats around = each. At the moment, the approach of having no choice for operators is = concerning to me. Kind regards, r.= From jsw@inconcepts.biz Mon Dec 31 08:59:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E543221F8962 for ; Mon, 31 Dec 2012 08:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND6Fsg5qm1qe for ; Mon, 31 Dec 2012 08:59:16 -0800 (PST) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F98F21F88C3 for ; Mon, 31 Dec 2012 08:59:16 -0800 (PST) Received: by mail-ia0-f176.google.com with SMTP id y26so10534896iab.7 for ; Mon, 31 Dec 2012 08:59:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=UQga9xK3+Szvg2Y9hlrJ3jaazunZbbfH88VwAJdVsQg=; b=mjybntLfAqgs338Vq/TNhm+8c0tL/kGJpYqAv7zUHkLUvMMl/oYOHhPU/0RfPrYKcQ V7ittTHwlihzVahL+w47ma8+dbQ6sdzNpcFcm+a1i68CPQ96Aemd0aT1EgqaEujyYgjp HQ08QpfLgQPDBNpQCFo6/Jw50fqFF0Nx7PrIXeOQtwKmZ9egLFtntC3CqMKkfTehR29t SgzbiOQ6OtJG+s8+0OWPuQPgCImZdyYiVt0eXhIh4p8a9bYDLXq9RCZTPOaUtuzuVoRc yA9jKeko42oxy5iUYerqH4Eo2gPvHnjfpgfXjQgaSIf6ECstquaw6k3vGJ1d/2u8bS2s IF8Q== MIME-Version: 1.0 Received: by 10.50.173.34 with SMTP id bh2mr36085608igc.70.1356973155917; Mon, 31 Dec 2012 08:59:15 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 31 Dec 2012 08:59:15 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> Date: Mon, 31 Dec 2012 11:59:15 -0500 Message-ID: From: Jeff Wheeler To: Rob Shakir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnOF9vYJZoITrzhfFY99dwlVJ7STIOc9ORMSHl9iGaQSYAMAq5VjOdkmENPJ1MzP0sgcZqL Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 16:59:17 -0000 On Mon, Dec 31, 2012 at 5:52 AM, Rob Shakir wrote: > If we tear down the session based on a single bad UPDATE, then Bad Things= =99 happen. This is why I'm confused why you aren't more interested in giving the vendor (ultimately, the operator) the choice to simply ignore bad updates. You know that error-handling already leaves the RIB (network) in a bad state. You might as well give the option to reset the session under even fewer circumstances. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rjs@rob.sh Mon Dec 31 09:33:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0623721F88B1; Mon, 31 Dec 2012 09:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wd2IkGe2K6B; Mon, 31 Dec 2012 09:33:29 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 8217021F86BA; Mon, 31 Dec 2012 09:33:29 -0800 (PST) Received: from [46.65.174.227] (helo=latte.munster) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TpjBp-0001jm-EE; Mon, 31 Dec 2012 17:30:17 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Mon, 31 Dec 2012 17:33:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh> To: Jeff Wheeler X-Mailer: Apple Mail (2.1283) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 17:33:30 -0000 On 31 Dec 2012, at 16:59, Jeff Wheeler wrote: > On Mon, Dec 31, 2012 at 5:52 AM, Rob Shakir wrote: >> If we tear down the session based on a single bad UPDATE, then Bad = Things=99 happen. >=20 > This is why I'm confused why you aren't more interested in giving the > vendor (ultimately, the operator) the choice to simply ignore bad > updates. >=20 > You know that error-handling already leaves the RIB (network) in a bad > state. You might as well give the option to reset the session under > even fewer circumstances. This is, of course, another route that we could go down, and has been = discussed previously. If we receive an UPDATE we know that *something* = to do with this path has changed, and if this UPDATE is erroneous know = that *something* about the signalling path is not correct. If we do have = other paths to that particular prefix, then treat-as-withdraw lets us = use these. If we simply ignore the UPDATE, then we trust this path that = has something suspect about it just as much as those that we have not = seen any error in the messaging for. Cheers, r.= From jakob.heitz@ericsson.com Mon Dec 31 09:55:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FE21F8792; Mon, 31 Dec 2012 09:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsRDT8uECIof; Mon, 31 Dec 2012 09:55:07 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7A21F85DC; Mon, 31 Dec 2012 09:55:07 -0800 (PST) Received: from EUSAAHC004.ericsson.se ([147.117.188.84]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBVI8Q1S010951; Mon, 31 Dec 2012 12:08:27 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Mon, 31 Dec 2012 12:55:00 -0500 From: Jakob Heitz To: Robert Raszuk Thread-Topic: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN5zgrlXyLlAlYv0yHiK+hIwQIfZgzMXY6 Date: Mon, 31 Dec 2012 17:54:59 +0000 Message-ID: <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <20121231030925.GB62942@verdi>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" , John Leslie Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 17:55:08 -0000 I don't think treat-as-withdraw is trying to fix a single session reset. Gr= aceful restart can fix that. It's the rolling resets that need a human to r= emove a buggy router or a config that triggered the bug. That takes several= hours. Treat-as-withdraw limits the damage during those hours. Could we please settle on that without trying to solve the impossible? Cheers, Jakob Sent from my iPoo. On Dec 31, 2012, at 1:21 AM, "Robert Raszuk" wrote: > How about if we would mandate Enhance Route Refresh request to be send > to such peer who's bad updates triggered treat-as-withdraw action ? >=20 > If we resync databases OK the likehood of "bad things" should be > minimal. If we fail to sync (get another malformed update(s)) then > IMHO resetting the session should be granted. >=20 > Yes that means that "treat-as-withdraw" should be applied only to > those peers which support Enhanced Route Refresh. >=20 > Happy New Year, > R. >=20 >=20 >> On Mon, Dec 31, 2012 at 4:09 AM, John Leslie wrote: >>=20 >> Brian Dickson wrote: >>>=20 >>> But, the basic problem is this: missing an UPDATE won't trigger either >>> condition, it will at worst cause sub-optimal routing. Missing a WITHDR= AW >>> _CAN_ cause Bad Things (TM) to happen. >>=20 >> +1 >>=20 >> -- >> John Leslie >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From jsw@inconcepts.biz Mon Dec 31 10:13:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17C321F8842 for ; Mon, 31 Dec 2012 10:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6KgXYkij48I for ; Mon, 31 Dec 2012 10:13:52 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF5D21F8830 for ; Mon, 31 Dec 2012 10:13:52 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so14883638iea.8 for ; Mon, 31 Dec 2012 10:13:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=p26aorl2upw71e+E8nixMbqeSDDA2WRioFANLxiKL6Q=; b=o4W+Ah1SVSALNMklNYoH5pSadMFyO3sguMSvezVlJxZMptkPJEJqk1eSywRk0pWXsj thnBNIzQmX5AwkQgr4rEOykaM4a5zPSRlfCyFYYSp/HC8nfT5JyvHqazAO3rhB9jEMPx s0swB1qcVH2GjIQHaxdN9YznrckFj697iL7r3lIKGlE5V956L6P4TlHKtPldN3FvMM2S bwIWTKNU15BVQgCxg4PbMzD+80WAe1GFIPVaonsb+lFJbBmjH/CUXv03fAkVvBeO1YsE 8UyDKTxlRnZjX82pTgxOx0W6w1wybqIkXaOvDD8E2y8gPQOyroyv61cJdA9H4BIYbbdl RVlQ== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr35381902igb.45.1356977631657; Mon, 31 Dec 2012 10:13:51 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 31 Dec 2012 10:13:51 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <20121231030925.GB62942@verdi> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> Date: Mon, 31 Dec 2012 13:13:51 -0500 Message-ID: From: Jeff Wheeler To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlHe4t0ZNBYQdhMqiZ1OjU6d+aHFNVPoe1Jx/pNn+e+aLk0ckF9YnZWea2pOrK1SBlHh9g9 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 18:13:52 -0000 On Mon, Dec 31, 2012 at 12:54 PM, Jakob Heitz wr= ote: > I don't think treat-as-withdraw is trying to fix a single session reset. = Graceful restart can fix that. It's the rolling resets that need a human to= remove a buggy router or a config that triggered the bug. That takes sever= al hours. Treat-as-withdraw limits the damage during those hours. > > Could we please settle on that without trying to solve the impossible? If you read my posts to IDR on this topic, you'll see where I explain how it is possible to solve the "impossible." Specifically, you can ignore just about any bad update, or bad message of any kind, as long as you can figure out where the next message starts. This fixes the rolling resets. You may know that a lot of businesses suffered multi-hour outages in October simply because of 5 DFZ routes announced by LANL that had illegal attributes. This is very hard for operators to troubleshoot on most routers. The routers that experienced rolling resets were buggy but if the operators simply had a panic button, "ignore bad messages," their networks would have been up and they would not have been losing money by the minute. This is not the only time bad updates have propagated through the DFZ and caused big problems. It has happened repeatedly. I believe it will begin to happen more often inside datacenter networks, because BGP is being used for more and more things, like EVPN. Operators are going to need BGP to become more robust. You can make it a lot more robust just by deciding to ignore everything in a bad message. This is not good, but it is a lot better than session-reset, in most cases. Please, read my posts on this topic, and do not treat this problem as an unsolvable one. It can be largely solved in a way that gives a very useful fallback option to operators. This whole draft is about fallback options, and it is pretty stupid to have a large amount of complexity to solve a small set of potential bugs, when you could ALTERNATIVELY or IN ADDITION to that, have a very low-complexity option that solves more problems. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jakob.heitz@ericsson.com Mon Dec 31 10:15:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBB421F8830; Mon, 31 Dec 2012 10:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSvUK919k67i; Mon, 31 Dec 2012 10:15:36 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADBCA21F8738; Mon, 31 Dec 2012 10:15:36 -0800 (PST) Received: from EUSAAHC003.ericsson.se ([147.117.188.81]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBVIFXs9020835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Dec 2012 12:15:34 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Mon, 31 Dec 2012 13:15:33 -0500 From: Jakob Heitz To: Robert Raszuk Thread-Topic: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN5tV/uxLXJIv0r0ynEwftCG2icZgzD+gAgAAg2ICAAAc6qg== Date: Mon, 31 Dec 2012 18:15:32 +0000 Message-ID: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6EC403F6-43EE-4A70-860A-3196B1CF266C@rob.sh>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 18:15:37 -0000 On Dec 31, 2012, at 4:49 AM, "Robert Raszuk" wrote: >=20 > I have discovered last week in one of BGP implementation that BGP > conditional advertisement will not kick in till the trigger (check > condition) disappears completely from BGP table even if it's next hop > is no longer present in global RIB. One could call this a bug, Before we even consider this case, perhaps someone could update (and explai= n) rfc4271 to remove the following sentence from page 76: The function that calculates the degree of preference for a given route SHA= LL NOT use any of the following as its inputs: the existence of other route= s, the non-existence of other routes, or the path attributes of other route= s. Cheers, Jakob.= From jakob.heitz@ericsson.com Mon Dec 31 10:35:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687AF21F865D; Mon, 31 Dec 2012 10:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkN+DAzCno+U; Mon, 31 Dec 2012 10:35:43 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CAE4221F8651; Mon, 31 Dec 2012 10:35:43 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBVIZgs6021549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Dec 2012 12:35:43 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Mon, 31 Dec 2012 13:35:42 -0500 From: Jakob Heitz To: Jeff Wheeler Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN54KbFisNgDpWy0mj2cTgGt+EAZgzPEEA Date: Mon, 31 Dec 2012 18:35:42 +0000 Message-ID: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <20121231030925.GB62942@verdi> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 18:35:44 -0000 The difference between ignore and treat-as-withdraw is discussed in the dra= ft. Anyway, the feature will be knobbed. So far, I see 2 knob options: 1. Treat-as-withdraw / ignore 2. If stream sync is lost, search ahead for the next 16*0xFF / reset the se= ssion. Cheers, Jakob On Dec 31, 2012, at 10:14 AM, "Jeff Wheeler" wrote: > On Mon, Dec 31, 2012 at 12:54 PM, Jakob Heitz = wrote: >> I don't think treat-as-withdraw is trying to fix a single session reset.= Graceful restart can fix that. It's the rolling resets that need a human t= o remove a buggy router or a config that triggered the bug. That takes seve= ral hours. Treat-as-withdraw limits the damage during those hours. >>=20 >> Could we please settle on that without trying to solve the impossible? >=20 > If you read my posts to IDR on this topic, you'll see where I explain > how it is possible to solve the "impossible." >=20 > Specifically, you can ignore just about any bad update, or bad message > of any kind, as long as you can figure out where the next message > starts. This fixes the rolling resets. >=20 > You may know that a lot of businesses suffered multi-hour outages in > October simply because of 5 DFZ routes announced by LANL that had > illegal attributes. This is very hard for operators to troubleshoot > on most routers. The routers that experienced rolling resets were > buggy but if the operators simply had a panic button, "ignore bad > messages," their networks would have been up and they would not have > been losing money by the minute. >=20 > This is not the only time bad updates have propagated through the DFZ > and caused big problems. It has happened repeatedly. >=20 > I believe it will begin to happen more often inside datacenter > networks, because BGP is being used for more and more things, like > EVPN. Operators are going to need BGP to become more robust. >=20 > You can make it a lot more robust just by deciding to ignore > everything in a bad message. This is not good, but it is a lot better > than session-reset, in most cases. >=20 > Please, read my posts on this topic, and do not treat this problem as > an unsolvable one. It can be largely solved in a way that gives a > very useful fallback option to operators. >=20 > This whole draft is about fallback options, and it is pretty stupid to > have a large amount of complexity to solve a small set of potential > bugs, when you could ALTERNATIVELY or IN ADDITION to that, have a very > low-complexity option that solves more problems. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts From john@jlc.net Mon Dec 31 10:41:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7D621F8767; Mon, 31 Dec 2012 10:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjn-v+-lciQt; Mon, 31 Dec 2012 10:41:38 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9522121F870C; Mon, 31 Dec 2012 10:41:38 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8098833C3D; Mon, 31 Dec 2012 13:41:38 -0500 (EST) Date: Mon, 31 Dec 2012 13:41:38 -0500 From: John Leslie To: Jakob Heitz Message-ID: <20121231184138.GA25817@verdi> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> User-Agent: Mutt/1.4.1i Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 18:41:39 -0000 Jakob Heitz wrote: > On Dec 31, 2012, at 1:21 AM, "Robert Raszuk" wrote: >> On Mon, Dec 31, 2012 at 4:09 AM, John Leslie wrote: >>> Brian Dickson wrote: >>>> >>>> But, the basic problem is this: missing an UPDATE won't trigger either >>>> condition, it will at worst cause sub-optimal routing. I apologize for careless reading here. I took Brian to mean failing to process an UPDATE which changed the NLRI from a peer, but didn't change the _reachability_ of that block from that peer, breaks things but mildly. >>>> Missing a WITHDRAW _CAN_ cause Bad Things (TM) to happen. >>> >>> +1 I meant to +1 the statement that missing the notice that an NLRI was being withdrawn and not replaced (thereby changing reachability from positive to negative) is a much more serious breakage, since you may keep sending packets to that peer which no longer has the reachability you think it does. >> How about if we would mandate Enhance Route Refresh request to be send >> to such peer who's bad updates triggered treat-as-withdraw action ? A Route-Refresh cycle would ensure that we have the actual reachability status of that peer (if the Route-Refresh completes) instead of some outdated NLRI the peer intended to withdraw without replacement. >> Yes that means that "treat-as-withdraw" should be applied only to >> those peers which support Enhanced Route Refresh. We're discussing an area where "treat-as-withdraw" may no longer be a useful term, since we're considering an UPDATE so badly formed that we can't even extract which CIDR blocks are the subject of it. Personally, I'd prefer a Route-Refresh approach, where we make it perfectly clear to the peer in question that we no longer have a trustworthy state of its current advertised routing. > I don't think treat-as-withdraw is trying to fix a single session reset. > Graceful restart can fix that. It's the rolling resets that need a > human to remove a buggy router or a config that triggered the bug. > That takes several hours. Treat-as-withdraw limits the damage during > those hours. I agree with Jakob that we're _trying_ to discuss that -- but I don't agree we're succeeding very well. > Could we please settle on that without trying to solve the impossible? I'm not sure we can... First of all, most of us _aren't_ trying to solve the impossible: we're trying to design an error-management paradigm which passes _enough_ information on which to base intelligent routing decisions. And, I'm not sure what it means to "settle on" "treat-as-withdraw" that some of us consider "good enough" for a "limited" period while humans are working to resolve the actual problem. We know that the "limits" on such a period correlate all to well with the amount of pain being inflicted on paying customers. -- John Leslie From jsw@inconcepts.biz Mon Dec 31 11:59:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE921F87B3 for ; Mon, 31 Dec 2012 11:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6A0q4-gLRXq for ; Mon, 31 Dec 2012 11:59:21 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74121F8781 for ; Mon, 31 Dec 2012 11:59:21 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so15156539ieb.5 for ; Mon, 31 Dec 2012 11:59:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Cxd405Mu9Cj+XOBlF/lk+l5o5dSXmSNp+tW6LWTSM0k=; b=mke7x+UA8dpOzxRPkZNAA2dfRdJpD4Zry4pQDeoKvO7fB4tvYdCVurCV0KYbnXcpwv X/gMDdUVx7rsW9qRS4l2WXi9LAlpobRZD/59REbBukhv+GW4bFzLnsta31WvYz3bDYnW yrPxge3e9iz7QVUrUwa1ok/pxn10e3fpAaA9sbQz+dBAX45Ml1mlN0sHlKpQ70g/WamE IEslTOhs9HLXyiwBNMVM1RClUpxcBMuVn430iUTXx08zVTO0MipC6JTdw3SvYOh68QIz EfY/KSrwt2c8451AfF++ZOO0gSLJbC3eEQXelVSRu+rdZCZmKFF1bbka4TLrcBjIq2Ko +rtg== MIME-Version: 1.0 Received: by 10.50.173.34 with SMTP id bh2mr36385916igc.70.1356983960831; Mon, 31 Dec 2012 11:59:20 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 31 Dec 2012 11:59:20 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20121231184138.GA25817@verdi> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> <20121231184138.GA25817@verdi> Date: Mon, 31 Dec 2012 14:59:20 -0500 Message-ID: From: Jeff Wheeler To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQld8RDGMl2IJZD53Y1Yieog/b0NPN8sWPGL4R6sJJZWv+kmAhux07l+dj7o0LFJuowcsaiy Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 19:59:22 -0000 On Mon, Dec 31, 2012 at 1:41 PM, John Leslie wrote: > And, I'm not sure what it means to "settle on" "treat-as-withdraw" > that some of us consider "good enough" for a "limited" period while > humans are working to resolve the actual problem. We know that the > "limits" on such a period correlate all to well with the amount of > pain being inflicted on paying customers. It means just that, "settle on." Treat-As-Withdraw leaves plenty of circumstances where BGP will still be reset, perhaps endlessly until clue arrives. Let me just go through the explanation of what happened to many networks in October 2012 again. LANL announced some malformed routes to the DFZ. Most routers propagated them and ignored the malformed bits. Some routers did not, and instead, they reset the BGP session. That was a bug, but the customers had NO OPTIONS TO WORK AROUND THIS. Their ONLY CHOICE was to wait for a patch from their vendor (for folks whose vendor routers did this) or install a patch (for the lucky users who were running OpenBSD) or to ask their transit provider to install a prefix-list to block the 5 malformed paths from going to them. If customers had treat-as-withdraw in the form being discussed today, it would not have helped. Why? Malformed Attribute Flags are not one of the criteria it addresses. What networks need is an IGNORE BAD MESSAGES option so BGP can avoid session-reset, even if the cost is rather high (say a lot of RIB inconsistency.) Let the network operator choose when the cost of bad RIB information becomes so high that he would rather have BGP reset. After all, this will vary from one network to the next based on business needs, so there should be flexibility. That is why treat-as-withdraw is "settling." Ignore bad messages is a very simple option that "fixes" (mitigates) virtually all problems so the operator can buy time to diagnose it in detail, or wait for his vendor to provide a software update, or whatever. I'm not arguing this should be the only option or even the default option. I'm arguing that it should be ONE OPTION. As far as I'm concerned, you can have treat-as-withdraw, and you can build as much complicated error handling logic into it as you want. That effort might help me someday. But if it doesn't, I know for sure that IGNORE BAD MESSAGES is something I can fall back on, which is very likely to buy me the time I need. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rraszuk@gmail.com Mon Dec 31 12:15:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56E021F8596; Mon, 31 Dec 2012 12:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIJARpurcpjr; Mon, 31 Dec 2012 12:15:03 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1852C21F8566; Mon, 31 Dec 2012 12:15:03 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so15542014iea.10 for ; Mon, 31 Dec 2012 12:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gKfskRheaoGxzT2b0t2PGGxiDDULkKIcRuvGYSsSaAE=; b=lNh3KdkN02SV9nxKsrI/Z9P11oh5keI7bRC+6kXcty7Y06sM0jjZbQi2Qn8ku8w6r7 /Ww7N6ci02u9RCrqlMM76876JvjadBrSO5QI77QsYMLnEFrkP9wMeTYoJ3pSCmoDy9vS 5pjG4sH1Jg77IntS/KT3ZMJj4IeWbst347RVHpc5NtrEp691MzxGqh1q8bEcGkL26bFc A+vZuTUXGf7Xla5L/9iwGzttKjjFm9kw9ty5+PQUSjGVBd04wQO1PMHyHNibPoI+edCu HeVoppy2kivuCq3dWPKYBwr77kRfjtm83PvAhdGAA8LSDmF5mtUXECjDeHp/5+xbhlcq 9b4A== MIME-Version: 1.0 Received: by 10.42.72.132 with SMTP id o4mr21274564icj.44.1356984902692; Mon, 31 Dec 2012 12:15:02 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Mon, 31 Dec 2012 12:15:02 -0800 (PST) In-Reply-To: References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> <20121231184138.GA25817@verdi> Date: Mon, 31 Dec 2012 21:15:02 +0100 X-Google-Sender-Auth: dVap1hCJix_NbCKbDPyAbpFxNzs Message-ID: From: Robert Raszuk To: Jeff Wheeler Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , "grow@ietf.org" , John Leslie Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 20:15:03 -0000 Hi Jeff, > That was a bug, but the customers had NO OPTIONS TO WORK AROUND THIS. > Their ONLY CHOICE was to wait for a patch from their vendor (for folks > whose vendor routers did this) + > the operator can buy time to diagnose it in detail, or wait for his > vendor to provide a software update, or whatever. I think you have just hit the nail on it's head above. I think waiting for vendor's fix is just not acceptable for production environments .. it just takes too long [read days if not weeks] (not to mention that a lot of deployed hardware requires reload when you upgrade). When we originally discussed error handling solutions in junisco one option was to allow operator to apply filter to BGP messages between TCP and BGP. If the error is known it is pretty trivial to match on arbitrary string in such BGP pre-parser and filter it out or clear or reset the bit/bits if NOC decides it is operationally safe. The point is that for critical protocol like BGP4 (with current choice of transport) I am of the opinion that we should build a much more universal mechanism rather then add fixed twicks which may or may not always help and when operator has zero control on what such "session saver" twick actually does. Cheers, R. From jakob.heitz@ericsson.com Mon Dec 31 12:24:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB8021F8692; Mon, 31 Dec 2012 12:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiMGSAWt2Fpe; Mon, 31 Dec 2012 12:24:38 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE021F8470; Mon, 31 Dec 2012 12:24:38 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBVKbwdN018281; Mon, 31 Dec 2012 14:37:59 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Mon, 31 Dec 2012 15:24:30 -0500 From: Jakob Heitz To: Jeff Wheeler , John Leslie Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN55FWi/J3CnHlp0Sb55SRXym/4ZgzWYog Date: Mon, 31 Dec 2012 20:24:30 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E147337@eusaamb109.ericsson.se> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> <20121231184138.GA25817@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 20:24:40 -0000 On , Jeff Wheeler <> wrote: > On Mon, Dec 31, 2012 at 1:41 PM, John Leslie wrote: > Malformed Attribute Flags are not > one of the criteria it addresses.=20 http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 says When a path attribute (other than the MP_REACH_NLRI attribute [RFC4760] or the MP_UNREACH_NLRI attribute [RFC4760]) in an UPDATE message is determined to be malformed, the UPDATE message containing that attribute MUST be treated as though all contained routes had been withdrawn... ...In the case of an attribute which has no effect on route selection or installation, the malformed attribute MAY instead be discarded... That covers malformed attribute flags. --=20 Jakob Heitz. From jsw@inconcepts.biz Mon Dec 31 12:36:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C629521F88C3 for ; Mon, 31 Dec 2012 12:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8ArugOvbY9U for ; Mon, 31 Dec 2012 12:36:11 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 225E621F85B4 for ; Mon, 31 Dec 2012 12:36:11 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so15506449iea.15 for ; Mon, 31 Dec 2012 12:36:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=0ZYTIiDsVsBy5z6lIkNJaqxS9V9Y2v0I3ZOvXvBxrIY=; b=FAB3uTGU8Nh5cZgMySKDsCE0ZxYcsegKmilgV6HUfB8cfNCbV3zW2Gb/vd0pOA7Rsh 0uzdN9fQudvpNjRrYdOnRno7Wfjc4SXlKPsjz2gBheyONn/oOa3JYGmgjtocP95ZzF/v st5CMSrMwpZCahSxbL8qNMeFMWR0Z0RxWdLYayh3lJpvGQ3wT5D/gyoab7Xr3f67LdAx AjjWor2ppOLWRFL6UuJwZPdwcuhIAgF4/tmdWByaxKfZtbw4/zUmTRwE8/21WFBe0SV+ 6546eoR5ko1afKY0CDJJHtmqiUPSPsTiUKyVdROwYfdFkMSXbw5S1mKWRwaLcSZxRKhR kK+A== MIME-Version: 1.0 Received: by 10.42.180.65 with SMTP id bt1mr31909870icb.41.1356986165804; Mon, 31 Dec 2012 12:36:05 -0800 (PST) Received: by 10.64.132.33 with HTTP; Mon, 31 Dec 2012 12:36:05 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E147337@eusaamb109.ericsson.se> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> <20121231184138.GA25817@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E147337@eusaamb109.ericsson.se> Date: Mon, 31 Dec 2012 15:36:05 -0500 Message-ID: From: Jeff Wheeler To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmJrJTgavgJtjTqMYgKQYt9fC2Mbv6/L+2WHnGmtUc5cowtAo95HFTlNkuhGzWU7E0g5RXJ Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 20:36:11 -0000 On Mon, Dec 31, 2012 at 3:24 PM, Jakob Heitz wrote: > That covers malformed attribute flags. Except in the MP_REACH_NLRI or MP_UNREACH_NLRI, which is not a foolish exception if the goal is to recover all the NLRI; but if the goal is to avoid session-reset, it is. Like I keep saying, the goal of error-handling should be to make session-reset avoidable. Today it is not. It is creating complex rules which must be supported by both sides of the BGP session to try very hard to keep the network in a good state. This is a good goal in itself, but not to the exclusion of avoiding session-reset. Again, the existing draft also ignores conflicts with RFC4271. So do the updates to RFC4760. You are not allowed to put attributes into the attribute list in any order you want. RFC4271 explicitly requires that attributes be sorted by Attribute Type Code. A Capability negotiation is necessary to change the ordering of attributes. Finally, because the current error-handling concept can't be implemented without such a capability, it's not useful if the other BGP speaker lacks support. That is why IGNORE BAD MESSAGES is needed. It doesn't require support on both sides. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts