From jgs@juniper.net Mon Nov 5 10:56: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 9574A21F87B8 for ; Mon, 5 Nov 2012 10:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, 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 rdapJcDS-Yvj for ; Mon, 5 Nov 2012 10:56:04 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 112AE21F88A4 for ; Mon, 5 Nov 2012 10:56:03 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUJgLwnoQ9TITQK6zJAcm6o3XEi/o8xg7@postini.com; Mon, 05 Nov 2012 10:56:03 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; Mon, 5 Nov 2012 10:54:31 -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; Mon, 5 Nov 2012 10:54:31 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.144) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 5 Nov 2012 10:56:40 -0800 Received: from mail49-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 5 Nov 2012 18:53:57 +0000 Received: from mail49-db3 (localhost [127.0.0.1]) by mail49-db3-R.bigfish.com (Postfix) with ESMTP id 9A897300157 for ; Mon, 5 Nov 2012 18:53:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -18 X-BigFish: PS-18(zz1443Izz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h1155h) Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 1352141635820546_29731; Mon, 5 Nov 2012 18:53:55 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.234]) by mail49-db3.bigfish.com (Postfix) with ESMTP id BC1AF340175 for ; Mon, 5 Nov 2012 18:53:55 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 5 Nov 2012 18:53:55 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.84.38) with Microsoft SMTP Server (TLS) id 14.16.233.3; Mon, 5 Nov 2012 18:53:54 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <1531C70A-942E-4FB7-AFDF-5958C1BD6EE5@juniper.net> Date: Mon, 5 Nov 2012 13:53:52 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) 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%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] Jabber monitor, note takers, for Tuesday's IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 05 Nov 2012 18:56:04 -0000 Folks, We will need at least one person to monitor Jabber = (xmpp:idr@jabber.ietf.org) and relay questions/answers to the mic. We = won't be able to start the meeting without a Jabber monitor. We would also be grateful for any notes people may contribute. You can = take notes however you like, but some people like the collaborative = Etherpad tool: http://tools.ietf.org/wg/idr/minutes Thanks in advance for any help. --John= From internet-drafts@ietf.org Mon Nov 5 14:29: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 6B70A11E809B; Mon, 5 Nov 2012 14:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 eugWqWDCVJZO; Mon, 5 Nov 2012 14:29:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F185D21F8499; Mon, 5 Nov 2012 14:29:36 -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.35 Message-ID: <20121105222936.27141.59803.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 14:29:36 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-link-bandwidth-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, 05 Nov 2012 22:29:37 -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 Link Bandwidth Extended Community Author(s) : Pradosh Mohapatra Rex Fernando Filename : draft-ietf-idr-link-bandwidth-05.txt Pages : 5 Date : 2012-11-05 Abstract: This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-link-bandwidth-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gmanzano@cenit.gob.ve Mon Nov 5 19:32: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 9EFE121F84EE for ; Mon, 5 Nov 2012 19:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xxjyjnPhuaGZ for ; Mon, 5 Nov 2012 19:32:15 -0800 (PST) Received: from smtp.cenit.gob.ve (smtp.cenit.gob.ve [IPv6:2001:1338:1001:930::12]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB711E80E8 for ; Mon, 5 Nov 2012 19:32:14 -0800 (PST) Received: from [IPv6:2001:df8::64:21e:c2ff:fea8:d2c9] (unknown [IPv6:2001:df8:0:64:21e:c2ff:fea8:d2c9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.cenit.gob.ve (Postfix) with ESMTPSA id 37790360E5; Mon, 5 Nov 2012 22:52:06 -0430 (VET) Message-Id: <9756A5A8-8518-49C7-A94C-C8132793D5AC@cenit.gob.ve> From: Gregorio Manzano To: John Scudder In-Reply-To: <1531C70A-942E-4FB7-AFDF-5958C1BD6EE5@juniper.net> Content-Type: multipart/alternative; boundary=Apple-Mail-61-203473243 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Nov 2012 22:33:47 -0500 References: <1531C70A-942E-4FB7-AFDF-5958C1BD6EE5@juniper.net> X-Mailer: Apple Mail (2.936) Cc: "idr@ietf. org" Subject: Re: [Idr] Jabber monitor, note takers, for Tuesday's IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 06 Nov 2012 03:32:15 -0000 --Apple-Mail-61-203473243 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable John: if anyone can, I could monitor Jabber. If so, please lets =20 schedule a previous meeting for explanations. Best regards, Gregorio Manzano (a new attendee) El 05/11/2012, a las 01:53 p.m., John Scudder escribi=F3: > Folks, > > We will need at least one person to monitor Jabber = (xmpp:idr@jabber.ietf.org=20 > ) and relay questions/answers to the mic. We won't be able to start =20= > the meeting without a Jabber monitor. > > We would also be grateful for any notes people may contribute. You =20 > can take notes however you like, but some people like the =20 > collaborative Etherpad tool: http://tools.ietf.org/wg/idr/minutes > > Thanks in advance for any help. > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr Gregorio Manzano R. Jefe de Redes y Telecomunicaciones Direcci=F3n de Operaciones y Red Acad=E9mica Centro Nacional de Innovaci=F3n Tecnol=F3gica Tel=E9fono: 0212 555.8290 http://www.cenit.gob.ve --Apple-Mail-61-203473243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
John: if anyone can, I = could monitor Jabber. If so, please lets schedule a previous meeting for = explanations.

Best regards,
Gregorio = Manzano
(a new = attendee)
 

El 05/11/2012, a las 01:53 = p.m., John Scudder escribi=F3:

Folks,

We will need at least one person to = monitor Jabber (xmpp:idr@jabber.ietf.org) and = relay questions/answers to the mic. We won't be able to start the = meeting without a Jabber monitor.

We would also be grateful for = any notes people may contribute. You can take notes however you like, = but some people like the collaborative Etherpad tool: http://tools.ietf.org/wg/idr= /minutes

Thanks in advance for any = help.

--John
_______________________________________________
= Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr


Gregorio Manzano = R.
Jefe de Redes y Telecomunicaciones
Direcci=F3n de = Operaciones y Red Acad=E9mica
Centro Nacional de Innovaci=F3n = Tecnol=F3gica
Tel=E9fono: 0212 555.8290

= --Apple-Mail-61-203473243-- From internet-drafts@ietf.org Tue Nov 6 06:09: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 EE4AC21F88EF; Tue, 6 Nov 2012 06:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 6N3uDS8wju9x; Tue, 6 Nov 2012 06:09:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7308721F8772; Tue, 6 Nov 2012 06:09:31 -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.35 Message-ID: <20121106140931.3579.75358.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 06:09:31 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-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, 06 Nov 2012 14:09:32 -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 Filename : draft-ietf-idr-bgp-optimal-route-reflection-03.txt Pages : 19 Date : 2012-11-06 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-optimal-route-reflect= ion-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Tue Nov 6 08:44: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 5F06621F89BF for ; Tue, 6 Nov 2012 08:44: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=[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 WVTYqyXwu79l for ; Tue, 6 Nov 2012 08:44:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7663A21F8905 for ; Tue, 6 Nov 2012 08:44:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMM12453; Tue, 06 Nov 2012 16:44:32 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 16:44:22 +0000 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 16:44:30 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 00:44:27 +0800 From: Xuxiaohu To: "idr@ietf.org" Thread-Topic: Concerns with draft-vandevelde-idr-remote-next-hop Thread-Index: AQHNvDrVnxnp6uvf4kWRDemeZF0HcQ== Date: Tue, 6 Nov 2012 16:44:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756D8E9@szxeml525-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] Concerns with draft-vandevelde-idr-remote-next-hop X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 06 Nov 2012 16:44:35 -0000 Hi co-authors of this draft, As I mentioned during the WG session, I have the following concerns with t= his draft: 1) This draft proposes to use other address (i.e., remote next-hop address)= than the next-hop address as the tunnel endpoint address. In fact, the "BG= P Tunnel Address Prefix Attribute and Tunnel Address Prefix Extended Commun= ity" defined in http://tools.ietf.org/html/draft-xu-idr-tunnel-address-pref= ix-00 have already allow us to achieve such goal. 2) This draft proposes to optionally use multiple tunnel endpoints for a gi= ven NRLI. In fact, the "BGP Tunnel Address Prefix Attribute and Tunnel Add= ress Prefix Extended Community" defined in http://tools.ietf.org/html/draft= -xu-idr-tunnel-address-prefix-00 have already allowed us to achieve such go= al as well. 3) This draft proposes to associate the tunnel encapsulation advertisement = with the NRLI advertisement. In fact, RFC5512 has already provided such fle= xibility by using the BGP Tunnel Encapsulation Attribute, insteads of the B= GP Encapsulation SAFI. In addition, http://tools.ietf.org/html/draft-xu-idr= -tunnel-address-prefix-00 provides such flexibility as well. Best regards, Xiaohu= From randy@psg.com Tue Nov 6 16:48: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 9E37C21F8BB6 for ; Tue, 6 Nov 2012 16:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 mmuszoaRgxGA for ; Tue, 6 Nov 2012 16:48:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9D21F8BA5 for ; Tue, 6 Nov 2012 16:48:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TVtoS-0009l2-Kk; Wed, 07 Nov 2012 00:48:13 +0000 Date: Wed, 07 Nov 2012 09:48:11 +0900 Message-ID: From: Randy Bush To: Xuxiaohu In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756D8E9@szxeml525-mbx.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756D8E9@szxeml525-mbx.china.huawei.com> 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] Concerns with draft-vandevelde-idr-remote-next-hop X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 07 Nov 2012 00:48:13 -0000 nexthop is rewritten at provider borders, if not more often (some rewrite at RR). you are not going to change that. randy From jgs@juniper.net Thu Nov 8 13:07: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 6939C21F8BD6 for ; Thu, 8 Nov 2012 13:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.533 X-Spam-Level: X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=2.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 IGj++yP3qdSw for ; Thu, 8 Nov 2012 13:07:31 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFE621F8AAB for ; Thu, 8 Nov 2012 13:07:30 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUJwfEck9yeHdf+u++ibw97SJqxLl2VtU@postini.com; Thu, 08 Nov 2012 13:07:31 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 13:05:53 -0800 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.23.5.69]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qA8L5q393969 for ; Thu, 8 Nov 2012 13:05:53 -0800 (PST) (envelope-from jgs@juniper.net) From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Thu, 8 Nov 2012 16:05:52 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) Subject: [Idr] Deprecating path attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 08 Nov 2012 21:07:35 -0000 Folks, We noticed that the IANA BGP Path Attributes registry still lists DPA = (attribute 11), ADVERTISER (attribute 12) and RCID_PATH / CLUSTER_ID = (attribute 13). Considering none of these are, or ever have been, in = use, good registry hygiene suggests marking them as "deprecated", which = basically means "don't use this. At some point in the future we might = re-use it for something else." There would be no immediate consequences of doing this, other than the = registry would get updated to be more accurate. If at some point in the = future we run out of space in the registry (perish the thought) having = deprecated these code points would allow us to reuse them. If anyone has any objections, please raise them, otherwise I'll plan to = submit a tiny Internet Draft requesting IANA to make the change. (Per = Michelle @ IANA, this is the procedure to get it done.)=20 Thanks, --John= From svshah@cisco.com Thu Nov 8 21:18: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 1AF6921F8595 for ; Thu, 8 Nov 2012 21:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kijkDt-L-0-0 for ; Thu, 8 Nov 2012 21:18:49 -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 48F4021F84E6 for ; Thu, 8 Nov 2012 21:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1352438329; x=1353647929; h=from:to:subject:date:message-id:mime-version; bh=hCKwIx3BJD5uhSJaP2cEdRBD3h+imIZQxlnVHNt4uZ0=; b=YNLS7SGKomLw6UfEy58tORBqc7TvNk3rJmMHArzyiLJaXTjbJiMz2RC2 XwL2EOi4bxAwwOyf7KSwZOH1kdOscA0SHzVML41Y9XOoqdJExSNMblHwO ZBNlR7MhkSHqVpqbB/xu6B9W84GrJeRjFSdU/5xDFqaewpmWtL+Ua0qXK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIJAImRnFCtJV2Z/2dsb2JhbABEgkmvBYkFiHOBAQeCIAEEEgF4AQweVicEGxqHaAubFYEroBGReWEDlxeNPIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,743,1344211200"; d="scan'208,217";a="140440469" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2012 05:18:48 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA95Im8P004923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 Nov 2012 05:18:48 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 23:18:48 -0600 From: "Shitanshu Shah (svshah)" To: "idr@ietf.org" Thread-Topic: Post and Review request for revised draft : Interdomain SLA exchange Thread-Index: AQHNvjmxojOrweMpPk2RFe3AH2plOg== Date: Fri, 9 Nov 2012 05:18:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.101.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--30.072900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_F5C7FB9548FA6A4B8538AFEF6199B0ED150B792Bxmbalnx10ciscoc_" MIME-Version: 1.0 Subject: [Idr] Post and Review request for revised draft : Interdomain SLA exchange X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 09 Nov 2012 05:18:50 -0000 --_000_F5C7FB9548FA6A4B8538AFEF6199B0ED150B792Bxmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a post for latest revised draft for Interdomain SLA exchange : http= ://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange/ Please review/provide your comments.. Notable changes with respect to first revision presented at 83rd IETF * Drop QoS from "QoS SLA" all over the places from the draft * Change MPLS_EXP to MPLS_TC * Introduction section has been expanded with more details * Addition of an SLA identifier field in SLA message format * Addition of a DROP_THRESHOLD in SLA message format * DSCP length field changed from 8-bits to 6-bits * PHB_ID added as one of the service (traffic) classifier options * Section 3.1 has added bit more clarification when attribute message i= s forwarded thru aggregator. As well in Section 5.3 * Reference to new BGP error handling, the approach of attribute-discar= d" is added in Section 6 * Modified author list and acknowledgment list Thanks Shitanshu --_000_F5C7FB9548FA6A4B8538AFEF6199B0ED150B792Bxmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <741C5B21C8CA5846BB5342C6CAF2106C@cisco.com> Content-Transfer-Encoding: quoted-printable

Hi,

This is a post for latest revised draft for Interdomain SLA exchange :=  http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-e= xchange/
Please review/provide your comments..

Notable changes with respect to first revision presented at 83rd IETF<= /div>
  • Drop QoS from "QoS SLA" all over the places from the draft
  • Change MPLS_EXP to MPLS_TC
  • Introduction section has been expanded with more details
  • Addition of an SLA identifier field in SLA message format
  • Addi= tion of a DROP_THRESHOLD in SLA message format
  • DSCP length field ch= anged from 8-bits to 6-bits
  • PHB_ID added as one of the service (tra= ffic) classifier options
  • Section 3.1 has added bit more clarificati= on when attribute message is forwarded thru aggregator. As well in Section = 5.3
  • Reference to new BGP error handling, the approach of attribute-= discard" is added in Section 6
  • Modified author list and acknow= ledgment list

Thanks
Shitanshu
--_000_F5C7FB9548FA6A4B8538AFEF6199B0ED150B792Bxmbalnx10ciscoc_-- From svshah@cisco.com Thu Nov 8 21:21: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 1E75B11E80BA for ; Thu, 8 Nov 2012 21:21:09 -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 5pjnFC1lykMI for ; Thu, 8 Nov 2012 21:21:08 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1637F21F862E for ; Thu, 8 Nov 2012 21:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2020; q=dns/txt; s=iport; t=1352438468; x=1353648068; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wZCHx9lJAL79YtdaVk69zScVkzEE4nNzCgKtckfjPOg=; b=cJXpdJlL9b61EOAGilpTCAyHCKt+AddO65SuaXREL989CmnP+1TVcz0v F3XOR0iC1otQWZKYqp21UJEOYnhAlJZPUKH7vurkG88RNZpr2iy80dKgv XF5vPxprs+Q25xoVxZ84IuXvY0nrU3Opid98UzY1FpffTCUJV5cLMlqK8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACaSnFCtJV2a/2dsb2JhbABEw0aBCIIeAQEBBAEBAQ8BJzQBAwcMBgEIEQQBAQEKFAkuCxQJCAEBBAENBQgah2gLnECgEYwShWdhA5cXjTyBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,743,1344211200"; d="scan'208";a="140442493" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 09 Nov 2012 05:21:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA95L7eZ011223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 05:21:07 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 23:21:06 -0600 From: "Shitanshu Shah (svshah)" To: "Rajiv Asati (rajiva)" , Lou Berger Thread-Topic: [Idr] Two comments on draft-svshah-bgp-qos-sla-attribute-00.txt Thread-Index: Ac0LMrgvGIgPNFyL7UGvjzGsdFnkMgABCeDALLyYEwA= Date: Fri, 9 Nov 2012 05:21:05 +0000 Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C07BD9213@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.101.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--41.190700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8B085648C0C16845BA38BC9ED4B87F84@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] Two comments on draft-svshah-bgp-qos-sla-attribute-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: Fri, 09 Nov 2012 05:21:09 -0000 Comments addressed in the latest revision: http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange Thanks Shitanshu On 3/26/12 3:03 AM, "Rajiv Asati (rajiva)" wrote: >MPLS_EXP =3D MPLS_TC. Just a terminology change since rfc5462. > >Cheers, >Rajiv > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >> Shitanshu Shah (svshah) >> Sent: Monday, March 26, 2012 5:28 AM >> To: Lou Berger; draft-svshah-bgp-qos-sla-attribute@tools.ietf.org >> Cc: idr@ietf.org >> Subject: Re: [Idr] Two comments on >>draft-svshah-bgp-qos-sla-attribute-00.txt >> >> >> Hi Lou, >> >> Thank you for your comments >> >> 1) While agree MPLS Traffic Class may be more used in communication just >> like Diffserv Class is, it is very explicit to define them as MPLS_EXP >>just >> like we would as IP_DSCP for Diffserv classes. This explicit definition >>will >> leave no ambiguity for the receiver to instantiate filtering rules >> >> 2) Would "SLA" mean QoS only or is SLA generic to mean beyond QoS also? >>If >> it is earlier then it seems reasonable to follow your suggestion. In any >> case, your comment is well taken, we may refer in the draft as you say, >>with >> explicit definition of it in the beginning of the draft >> >> Shitanshu >> >> On 3/26/12 2:01 AM, "Lou Berger" wrote: >> >> > Hi, >> > I have two fairly pedantic comments on the draft: >> > >> > 1) Why MPLS_EXP and not MPLS_TC? >> > >> > 2) While QoS is used in a couple of RFCs related to DiffServ, its >>usage >> > in relationship to DS/TC seems to be more common in marketing usage. >>I >> > also thing calling this "QoS signaling" a bit of a stretch. So I >> > suggest not using QoS in this draft. Perhaps "SLA advertisement" is >> > sufficient. >> > >> > Lou >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From svshah@cisco.com Thu Nov 8 21:24: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 6B8A111E80D7 for ; Thu, 8 Nov 2012 21:24:57 -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 2UQ1usPezCB8 for ; Thu, 8 Nov 2012 21:24:56 -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 D802911E80D5 for ; Thu, 8 Nov 2012 21:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12483; q=dns/txt; s=iport; t=1352438695; x=1353648295; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/xhkz+UeKjeA74qst51n8N98rq7kMP07+Bw5YprLwi0=; b=D+23RZNum5ozDEmaK9D2qnBGJ4Otn+eDYwOYk35Rxnme6Y5CWRwGV+vM nR40FEzC9OQ81lkWuX5FHih6nT95HN0flQbUNaPDNHevugu2HhPi1SBm7 loCAZG4uyVBqy2cgIWLhOcb0byW+w1VX6QPJah2GmOC6CYyjHYoCrKonF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGySnFCtJV2d/2dsb2JhbABEw0aBCIIeAQEBBBIBJzEHBxIBCBIGChQxERcOAQEEDgUIAQsFCYdWAw8LnECWMA2JVIsqaIVnYQOUJoJxihaDJoFrgm+BWwcZHg X-IronPort-AV: E=Sophos;i="4.80,743,1344211200"; d="scan'208";a="140490227" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 09 Nov 2012 05:24:54 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA95Oses013364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 05:24:55 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 23:24:53 -0600 From: "Shitanshu Shah (svshah)" To: Brian E Carpenter Thread-Topic: I-D Action: draft-svshah-interdomain-sla-exchange-00.txt Thread-Index: Ac1GGmsByDT6HAuyR0KHGxr/NSDQ+gal8k0AACHMqIAABOYVgBc3MgiA Date: Fri, 9 Nov 2012 05:24:52 +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.4.120824 x-originating-ip: [10.21.101.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--70.014800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Sandeep Bajaj Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Fri, 09 Nov 2012 05:24:57 -0000 Keeping idr in the loop.. Brian, Your review comments are addressed in the revised draft: http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange Please review and suggest/comment if any.. Thanks Shitanshu On 7/13/12 6:12 PM, "Shitanshu Shah (svshah)" wrote: > > >On 7/13/12 8:52 AM, "Brian E Carpenter" >wrote: > >>Hi, >> >>On 13/07/2012 07:44, Shitanshu Shah (svshah) wrote: >>> Hi Brian, >>>=20 >>> Sorry for the delay in the response. Keeping co-authors also in the >>>loop. >>>=20 >>> Few clarifications >>> - The proposal is not about end to end SLA. It is about exchanging SLA >>> between 2 domains. >> >>Does that mean two adjacent domains, or two domains separated by >>non-participating domains? > >It could be any. Adjacent or two domains separated by non-participating >ones. > > >> >>This is critical, because if there are intermediate domains, we must >>assume >>that they will change the DSCP, because it is a mutable field. > > >It makes sense for SLA exchange between those two domains, that are >separated by >non-participating domains, to take place only if those two domains fall >under >same controlled administration. I do not see otherwise why would there be >a >need for SLA exchange. > >For example, Site A and Site B are administered by Enterprise XYZ. Even >though >XYZ's provider for Site A means "EF" for voice and XYZ's provider for Site >B >means "CS5" for voice. XYZ understands those differences for voice between >Site A and Site B. Thus SLA exchange from one site to the other in the >context >of any "EF" or "CS4" still is okay. A mapping may be defined at the >receiver >to handle the differences. > >If Site A and Site B are managed by two different Enterprise XYZ and ABC >respectively then I do not see why SLA exchange to take place among them >irrespective of what dscp they use for voice traffic. > > =20 >> >>> - SLA exchange does not necessarily mean automatic provision of >>>forwarding >>> policy. Draft does not mandate that. though a vendor may use this >>>exchange >>> to automatically provision forwarding policy. >> >>OK, these points need to be clearly stated in the Introduction, I think. >> >>> Couple of use-cases are described in "Deployment Considerations" >>>section. >>> I can clarify further that section with any clarification that comes >>>out >>> of this discussion. >>>=20 >>> Taking couple of use-cases to describe further in the context of >>>Diffserv >>> based SLA. >>> 1. >>> - SLA exchange between CE and PE where they are connected physically or >>> virtually. >>> - Customer buys voice (1 mbps), video (5 mbps) and data (2 mbps) >>>service >>> from the Provider. >>> - If provider supports that voice, video and data service with EF, AF4 >>>and >>> AF2 then instead >>> of telling those EF, AF4, AF2 code-points over the phone to the >>> customer, they are, along >>> with rates, conveyed thru BGP >>>=20 >>> SLA exchange here does not have any responsibility to tell CE domain >>> which end-points should >>> be using which dscp code-point or which ip addresses/flows should be >>> mapping to which dscp >>> Code-point. Thus there is no dscp mapping to or from to be conveyed >>>here >> >>Well, you seem to expect the receiver to parse "Traffic Class Description >>- Ascii Description of the Traffic Class" somehow and configure diffserv >>classification and marking accordingly. So the receiver has to figure out >>how the DSCPs that the provider accepts map to its internal DSCPs (if >>any). > >Yes if receiver is using different dscp internally then mapping has to >happen >between Provider's dscp and internal dscp. And that is what we have >highlighted >in Section 6.1. Repeating what I mentioned above, aim of this proposal is >to >define a protocol to exchange SLA but not the provision of the mapping >between >sender and receiver's code-points. Yeah, if user (user here means vendor >or >administrator) is not able to come up with his/her own mapping to use with >exchanged SLA and if it is left with any ambiguity then we need to look >into >it but then we first have to know the use-case where such condition may >arise. >In worst case it will be supplemental proposal which still won't not >change >protocol of SLA exchange. >=20 > >> >>> 2. >>> - In VPN deployments where dscp code-point is preserved over VPN >>>tunnels. >>> - Specific Enterprise n/w let's say is spanned over different regions >>>eg. >>> San Jose, Atlanta, >>> Orlando where there is a vpn network between those sites. San Jose >>>eg. >>> may convey its SLA >>> to Atlanta, Olando for EF, AF4 and AF2 traffic. >>>=20 >>> Here again there is no responsibility to tell which end-points should >>>be >>> using which dscp >>> Code-points. All San Jose is telling Orlando is that if it is sending >>> any EF traffic towards >>> San Jose then it does not have to send more than 1 mbps >> >>Yes, once they agree on what "EF" is and which DSCP value it uses. >>Again it seems to depend on the ASCII description. >> >>> I've looked at RFC3140. PHB id is something may make sense to be added >>>as >>> one of the SLA exchange >>> Parameter. Where can I find list of PHB ids? >> >>There's a registry: >>http://www.iana.org/assignments/phbid-codes/phbid-codes.xml >>However, it's empty - in other words, nobody has found it necessary to >>register >>a non-default value. That means that today, only the standardised DSCP >>values >>at http://www.iana.org/assignments/dscp-registry/dscp-registry.xml >>have PHB IDs. >> >>However, if an operator wanted its own PHB ID for use in its own SLAs, >>it should be easy to register one. (I see that I'm a designated expert >>for this.) >> >>This was set up to provide flexibility - in practice people seem to >>prefer standard DSCPs and PHBs, but at the time people insisted on >>flexibility. > > >Sure, understood. And in those deployments that use this flexible PHB ids, >SLA exchange needs to be in the context of such PHB ids. > >Regards, >Shitanshu > > >> >>Regards >> >> Brian >> >>>=20 >>>=20 >>> Thanks >>> Shitanshu >>>=20 >>>=20 >>> On 6/9/12 1:32 AM, "Brian E Carpenter" >>>wrote: >>>=20 >>>> Hi Shitanshu, >>>> >>>> I think what is missing in the draft is a clear explanation of the >>>> possible >>>> deployment models and how they relate to the diffserv architecture, >>>>which >>>> is very explicit in defining the concept of diffserv domains. >>>>Basically >>>> that model requires DSCP mapping at every domain boundary (even if it >>>>is >>>> a trivial 1:1 mapping). I think you have to be very explicit that if >>>> the BGP attribute is transmitted across a diffserv domain boundary, >>>>the >>>> conveyed DSCPs MUST be mapped at that boundary (with a note that >>>>domains >>>> could agree on a 1:1 mapping if they were within a single SLA >>>>community). >>>> Or you use the PHBID instead, in which case it is by definition mapped >>>> locally inside each domain. >>>> >>>> By the way, as well as RFC 2475, the architecture is discussed in >>>> RFC 3086 and in B.E. Carpenter and K. Nichols, Differentiated Services >>>> in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 2012-06-06 17:57, svshah wrote: >>>>> Thanks a bunch Brian for your comments. See further inline for >>>>>response >>>>> >>>>> On 6/6/12 6:00 AM, "Brian E Carpenter" >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have some comments on your draft: >>>>>> >>>>>>> 0x02 =3D IP_DSCP, (length =3D 08-bits, value =3D 0..63) >>>>>> 1. The DSCP is a 6 bit field (the other two bits are ECN, and you >>>>>> can't touch them). >>>>> If you are referring to change the length field to 6-bits, I agree. >>>>>It >>>>> does >>>>> not have to be 8-bits. >>>>> >>>>>> 2. More seriously, the DSCP *by definition* is domain-specific. How >>>>>> can it >>>>>> be valid or meaningful in an end-to-end SLA? >>>>> This question requires multiple answers, hopefully I can itemize them >>>>> appropriately >>>>> >>>>> - The proposal in the draft is not specifically only for end-to-end >>>>> SLA. The >>>>> intentional use-case of the draft is with next hop SLA like PE to CE >>>>> SLA, >>>>> where PE may have SLA defined eg. for Diffserv classes which CE >>>>>traffic >>>>> will >>>>> be subject to. Based on your comment I assume, you are not >>>>>questioning >>>>> this >>>>> specific use case but are referring to SLA exchange across multiple >>>>>hops >>>>> >>>>> - Beyond just next hop, one can envision a use-case where ASs, >>>>>multiple >>>>> sites spanned across multiple regions, managed by one corporate or >>>>> provider >>>>> may want to exchange SLAs site to site to manage traffic multi-site >>>>> >>>>> - Also to note that SLA exchange format is defined to send SLA to a >>>>> specific >>>>> one or specific list of recipients. If this SLA exchange is across >>>>> multiple >>>>> hops then intermediate speakers (ones that are not in the recipient >>>>> list) >>>>> are not subject to SLA >>>>> >>>>> - Receiver, for which SLA is meant to, does not have to listen to >>>>>those >>>>> SLA >>>>> messages. They can ignore them. The point being that in a well >>>>>designed >>>>> network, SLAs will be accepted only if by design sender and receivers >>>>> are >>>>> expected to do so >>>>> >>>>> >>>>> Please fill me in if you are referring to any specific point beyond >>>>>ones >>>>> described above >>>>> >>>>> >>>>> >>>>>> I realise that you say >>>>>> >>>>>>> Typical use-case aimed with this proposal is for Provider to >>>>>>> advertise contracted SLA to Customer Edge. >>>>>> but that is unenforceable; BGP speakers can't be expected to know >>>>>> about QoS domain boundaries, so we must assume that this attribute >>>>>> might cross such boundaries. In fact, you admit this in section >>>>>> 6.1. The traffic class mapping described there MUST be applied >>>>>> at every diffserv domain boundary that this SLA attribute crosses, >>>>>> even to map DSCP1 to DSCP2. That seems like a bit of a deployment >>>>>> and operational nightmare. >>>>> While programming QoS automatically with this SLA exchange can be >>>>>very >>>>> helpful, there are other benefits that this method provides that >>>>> simplifies >>>>> administrators life specifically ones who are not very fluent on some >>>>> of the >>>>> QoS specifics, >>>>> >>>>> Taking an example Where SLA with PE is based on Diffserv classes with >>>>> specific rates for each diffserv class >>>>> 1) When admin has to provision QoS policy on CE, they first need to >>>>>know >>>>> what diffserv classes with what associated rates >>>>> >>>>> 2) Once that is known, translate them to Vendor specific provisioning >>>>> (eg. >>>>> What classification rules/configurations in Vendor's provisioning >>>>> language >>>>> and same for associated actions) >>>>> >>>>> 3) As required, define traffic class mapping as you pointed out >>>>> >>>>> 4) Once came up with appropriate mapping and policy, associate them >>>>> with the >>>>> forwarding >>>>> >>>>> >>>>> While, in some cases if not all, there may be challenges for step >>>>>(3), >>>>> customers get it so much simplified even with step (1) and (2) >>>>> >>>>> >>>>>> This is exactly what PHBIDs were intended for. Please see RFC3140. >>>>>> You should use those instead of DSCP values. Or better still, >>>>>> generalise the PHBID definition to cover MPLS and 802.1Q as well. >>>>> I'll certainly look into it. I'll definitely be happy if something >>>>>can >>>>> be >>>>> leveraged from RFC3140 or if can be enhanced in the context. >>>>> >>>>>> 3. What is the relationship of this work to >>>>>> draft-knoll-idr-qos-attribute? >>>>> I'll have to evaluate that. Will look into it. >>>>> >>>>>> 4. Finally, please run the draft through >>>>>> http://www.ietf.org/tools/idnits/. >>>>>> There are a lot of warnings. >>>>> Sure, thx. >>>>> >>>>> Looking forward for your response/comments/suggestions >>>>> >>>>> >>>>> Regards, >>>>> Shitanshu >>>>> >>>>> >>>>>> Regards >>>>>> Brian Carpenter >>>>> >>>=20 >>>=20 > From jgs@juniper.net Wed Nov 14 10:18: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 D6B3E21F85F3 for ; Wed, 14 Nov 2012 10:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_2=2.5, 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 aCvE5cyIARmy for ; Wed, 14 Nov 2012 10:18:44 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id BB55621F88CB for ; Wed, 14 Nov 2012 10:18:43 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUKPggyC7GyYfsHljSCf97rTP9RaqrCXO@postini.com; Wed, 14 Nov 2012 10:18:43 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; Wed, 14 Nov 2012 10:17: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; Wed, 14 Nov 2012 10:17:12 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.15) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Nov 2012 10:24:07 -0800 Received: from mail203-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 18:17:10 +0000 Received: from mail203-tx2 (localhost [127.0.0.1]) by mail203-tx2-R.bigfish.com (Postfix) with ESMTP id 98FB2980391 for ; Wed, 14 Nov 2012 18:17:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz9371I936eI1432I4015Izz1de0h1202h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h1155h) Received: from mail203-tx2 (localhost.localdomain [127.0.0.1]) by mail203-tx2 (MessageSwitch) id 135291702841776_31312; Wed, 14 Nov 2012 18:17:08 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.241]) by mail203-tx2.bigfish.com (Postfix) with ESMTP id F24CEA8004E; Wed, 14 Nov 2012 18:17:07 +0000 (UTC) Received: from SN2PRD0510HT003.namprd05.prod.outlook.com (157.56.234.117) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 18:17:00 +0000 Received: from sa-nc-mfg-245.static.jnpr.net (66.129.224.50) by pod51010.outlook.com (10.255.116.38) with Microsoft SMTP Server (TLS) id 14.16.233.3; Wed, 14 Nov 2012 18:16:59 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "John G. Scudder" Date: Wed, 14 Nov 2012 13:16:55 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1498) X-Originating-IP: [66.129.224.50] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NDZH.COM$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 Subject: [Idr] Requesting WG adoption and WGLC of 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: Wed, 14 Nov 2012 18:18:45 -0000 Hi, Nobody responded to my note of November 8 ("Deprecating path attributes = DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've = submitted the below tiny Internet Draft. The substantive text of the = draft is: 1. Introduction As of this writing the BGP Path Attributes registry maintained by IANA contains entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID. The first of these is associated with [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in 1996. The latter are associated with [RFC1863], an RFC that was reclassified as Historic in 2005. Neither of these specifications is in use now, nor ever was. 2. IANA Considerations This document requests IANA to mark the BGP Path Attributes registry entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as "Deprecated". The rest is boilerplate, references, etc.=20 I would like to ask the WG to adopt the draft. Since the draft is so = trivial, I would like to also request a WGLC, to run in parallel.=20 Since many WG members will be on holiday for part of next week, let's = have the call for adoption + WGLC end on December 3. Please send any = comments before December 3. Also, regarding the out-of-the-ordinary expedited WGLC: If there's any = disagreement whatsoever (with the content or wording of the draft, its = adoption, or indeed the expedited procedure itself), let's have only the = call for adoption end on December 3, and then we can do a normal WGLC = when appropriate. Thanks, --John (wearing two hats) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-scudder-deprecate-dpa-etal-00.txt > Date: November 14, 2012 1:06:11 PM EST > To: jgs@bgp.nu > Cc: jgs@juniper.net >=20 >=20 > A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt > has been successfully submitted by John Scudder and posted to the > IETF repository. >=20 > Filename: draft-scudder-deprecate-dpa-etal > Revision: 00 > Title: Deprecation of BGP Path Attributes DPA, = ADVERTISER and RCID_PATH / CLUSTER_ID > Creation date: 2012-11-14 > WG ID: Individual Submission > Number of pages: 2 > URL: = http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.tx= t > Status: = http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal > Htmlized: = http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 >=20 >=20 > Abstract: > This document requests IANA to deprecate several BGP path = attributes, > associated with an abandoned Internet Draft and a Historic RFC, > respectively. >=20 >=20 >=20 >=20 > The IETF Secretariat From keyupate@cisco.com Wed Nov 14 10:34: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 839AD21F879B for ; Wed, 14 Nov 2012 10:34:37 -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 8HTG1WDKkPnC for ; Wed, 14 Nov 2012 10:34:36 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 54C3D21F852D for ; Wed, 14 Nov 2012 10:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3054; q=dns/txt; s=iport; t=1352918076; x=1354127676; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/+2fvQjplwVaMgpLHOz0ql9defvPhgwg5380mQYqDHU=; b=QK6vooS2j3EFNr39rit4BBUhLp7BlwT3CVMWtOEBv4adX4uEiD/4lH96 SP7s0kVkg9qapivKobkoOgyOs22ScrwG4yrWWUum9Q2M5uvRHBOh4E5XI fCUu8/Vnj++eJz7tequ0wrqACOHqJbH0h1cP2fqksyzCxyDDAvQeKEPyF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACjjo1CtJXHB/2dsb2JhbABEwziBCIIeAQEBBAEBAQ8BCh00HQEIEQMBAgsUNwsdCAIEARIIARmHaAubJqAWjC2FS2EDlxiNPIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142399997" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 14 Nov 2012 18:34:34 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEIYYue025241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 18:34:34 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 12:34:34 -0600 From: "Keyur Patel (keyupate)" To: "John G. Scudder" , "idr@ietf. org" Thread-Topic: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt Thread-Index: AQHNwpaxworxh8sPFUinnFbuN06n3g== Date: Wed, 14 Nov 2012 18:34:34 +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.13.0.110805 x-originating-ip: [10.154.208.162] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--45.952300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3CCF65D697080E43A79C50408B656FDC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Wed, 14 Nov 2012 18:34:37 -0000 Support for both. Regards, Keyur On 11/14/12 10:16 AM, "John G. Scudder" wrote: >Hi, > >Nobody responded to my note of November 8 ("Deprecating path attributes >DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted >the below tiny Internet Draft. The substantive text of the draft is: > >1. Introduction > > As of this writing the BGP Path Attributes registry maintained by > IANA contains entries for DPA, ADVERTISER, and RCID_PATH / > CLUSTER_ID. The first of these is associated with > [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in > 1996. The latter are associated with [RFC1863], an RFC that was > reclassified as Historic in 2005. Neither of these specifications is > in use now, nor ever was. > > >2. IANA Considerations > > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". > >The rest is boilerplate, references, etc. > >I would like to ask the WG to adopt the draft. Since the draft is so >trivial, I would like to also request a WGLC, to run in parallel. > >Since many WG members will be on holiday for part of next week, let's >have the call for adoption + WGLC end on December 3. Please send any >comments before December 3. > >Also, regarding the out-of-the-ordinary expedited WGLC: If there's any >disagreement whatsoever (with the content or wording of the draft, its >adoption, or indeed the expedited procedure itself), let's have only the >call for adoption end on December 3, and then we can do a normal WGLC >when appropriate. > >Thanks, > >--John (wearing two hats) > >Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for >>draft-scudder-deprecate-dpa-etal-00.txt >> Date: November 14, 2012 1:06:11 PM EST >> To: jgs@bgp.nu >> Cc: jgs@juniper.net >>=20 >>=20 >> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt >> has been successfully submitted by John Scudder and posted to the >> IETF repository. >>=20 >> Filename: draft-scudder-deprecate-dpa-etal >> Revision: 00 >> Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and >>RCID_PATH / CLUSTER_ID >> Creation date: 2012-11-14 >> WG ID: Individual Submission >> Number of pages: 2 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.t >>xt >> Status: =20 >>http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal >> Htmlized: =20 >>http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 >>=20 >>=20 >> Abstract: >> This document requests IANA to deprecate several BGP path attributes, >> associated with an abandoned Internet Draft and a Historic RFC, >> respectively. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From brian.peter.dickson@gmail.com Wed Nov 14 12:19: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 1C61221F8755 for ; Wed, 14 Nov 2012 12:19:17 -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 VBI-fTc3E7uT for ; Wed, 14 Nov 2012 12:19:16 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B487521F8749 for ; Wed, 14 Nov 2012 12:19:15 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so431125bku.31 for ; Wed, 14 Nov 2012 12:19:14 -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=+x3LnH83NiDxD2ryZ876GOgNGf+5POdIFgQ24G4AhW0=; b=k7f7usgpE0Ee31woB0/KIFpKmTiXlXFHKUHj/eAdMfbGDToB/xICfMB7RZHakopr9c cRb+da2zinM/kW3VP8n/K3P9NhRbYKy5SKWKktv59TupedZJ8Cc6G+AcQXE3G8cDmlKB j/O7YG1lspKK1CPTvQtsFM+3/C8FL4oCFbHu0DwDP08Ygjk520eETrhe7oQkyb1XKA0C TJAUMTDDX6GlgKn161FIlWR/LiQ1Fwb7G9kk6GMZwEREj5CndrcDEc/1263IeJg7vq4P eqdc0s2UwdBl++T/LWWHkyVoHh5A6TC4bS6n04p2dvrnF5jg0NFx1ytfjxFeiVbsDkFN b/xQ== MIME-Version: 1.0 Received: by 10.204.150.210 with SMTP id z18mr9269189bkv.53.1352924354574; Wed, 14 Nov 2012 12:19:14 -0800 (PST) Received: by 10.204.66.83 with HTTP; Wed, 14 Nov 2012 12:19:14 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 15:19:14 -0500 Message-ID: From: Brian Dickson To: "Keyur Patel (keyupate)" Content-Type: multipart/alternative; boundary=0015175cae4a8ff8ca04ce7a3f34 Cc: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Wed, 14 Nov 2012 20:19:17 -0000 --0015175cae4a8ff8ca04ce7a3f34 Content-Type: text/plain; charset=ISO-8859-1 Support both for both. Brian P.S. If only more IDs were as short. :-) On Wed, Nov 14, 2012 at 1:34 PM, Keyur Patel (keyupate) wrote: > Support for both. > > Regards, > Keyur > > On 11/14/12 10:16 AM, "John G. Scudder" wrote: > > >Hi, > > > >Nobody responded to my note of November 8 ("Deprecating path attributes > >DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted > >the below tiny Internet Draft. The substantive text of the draft is: > > > >1. Introduction > > > > As of this writing the BGP Path Attributes registry maintained by > > IANA contains entries for DPA, ADVERTISER, and RCID_PATH / > > CLUSTER_ID. The first of these is associated with > > [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in > > 1996. The latter are associated with [RFC1863], an RFC that was > > reclassified as Historic in 2005. Neither of these specifications is > > in use now, nor ever was. > > > > > >2. IANA Considerations > > > > This document requests IANA to mark the BGP Path Attributes registry > > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > > "Deprecated". > > > >The rest is boilerplate, references, etc. > > > >I would like to ask the WG to adopt the draft. Since the draft is so > >trivial, I would like to also request a WGLC, to run in parallel. > > > >Since many WG members will be on holiday for part of next week, let's > >have the call for adoption + WGLC end on December 3. Please send any > >comments before December 3. > > > >Also, regarding the out-of-the-ordinary expedited WGLC: If there's any > >disagreement whatsoever (with the content or wording of the draft, its > >adoption, or indeed the expedited procedure itself), let's have only the > >call for adoption end on December 3, and then we can do a normal WGLC > >when appropriate. > > > >Thanks, > > > >--John (wearing two hats) > > > >Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for > >>draft-scudder-deprecate-dpa-etal-00.txt > >> Date: November 14, 2012 1:06:11 PM EST > >> To: jgs@bgp.nu > >> Cc: jgs@juniper.net > >> > >> > >> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt > >> has been successfully submitted by John Scudder and posted to the > >> IETF repository. > >> > >> Filename: draft-scudder-deprecate-dpa-etal > >> Revision: 00 > >> Title: Deprecation of BGP Path Attributes DPA, > ADVERTISER and > >>RCID_PATH / CLUSTER_ID > >> Creation date: 2012-11-14 > >> WG ID: Individual Submission > >> Number of pages: 2 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.t > >>xt > >> Status: > >>http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal > >> Htmlized: > >>http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 > >> > >> > >> Abstract: > >> This document requests IANA to deprecate several BGP path attributes, > >> associated with an abandoned Internet Draft and a Historic RFC, > >> respectively. > >> > >> > >> > >> > >> The IETF Secretariat > > > > > >_______________________________________________ > >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 > --0015175cae4a8ff8ca04ce7a3f34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support both for both.

Brian

P.= S. If only more IDs were as short. :-)

On= Wed, Nov 14, 2012 at 1:34 PM, Keyur Patel (keyupate) <= ;keyupate@cisco.com= > wrote:
Support for both.

Regards,
Keyur

On 11/14/12 10:16 AM, "John G. Scudder" <jgs@juniper.net> wrote:

>Hi,
>
>Nobody responded to my note of November 8 ("Deprecating path attri= butes
>DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I'v= e submitted
>the below tiny Internet Draft. The substantive text of the draft is: >
>1. =A0Introduction
>
> =A0 As of this writing the BGP Path Attributes registry maintained by<= br> > =A0 IANA contains entries for DPA, ADVERTISER, and RCID_PATH /
> =A0 CLUSTER_ID. =A0The first of these is associated with
> =A0 [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned = in
> =A0 1996. =A0The latter are associated with [RFC1863], an RFC that was=
> =A0 reclassified as Historic in 2005. =A0Neither of these specificatio= ns is
> =A0 in use now, nor ever was.
>
>
>2. =A0IANA Considerations
>
> =A0 This document requests IANA to mark the BGP Path Attributes regist= ry
> =A0 entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as
> =A0 "Deprecated".
>
>The rest is boilerplate, references, etc.
>
>I would like to ask the WG to adopt the draft. Since the draft is so >trivial, I would like to also request a WGLC, to run in parallel.
>
>Since many WG members will be on holiday for part of next week, let'= ;s
>have the call for adoption + WGLC end on December 3. Please send any >comments before December 3.
>
>Also, regarding the out-of-the-ordinary expedited WGLC: If there's = any
>disagreement whatsoever (with the content or wording of the draft, its<= br> >adoption, or indeed the expedited procedure itself), let's have onl= y the
>call for adoption end on December 3, and then we can do a normal WGLC >when appropriate.
>
>Thanks,
>
>--John (wearing two hats)
>
>Begin forwarded message:
>
>> From: internet-drafts@= ietf.org
>> Subject: New Version Notification for
>>draft-scudder-deprecate-dpa-etal-00.txt
>> Date: November 14, 2012 1:06:11 PM EST
>> To: jgs@bgp.nu
>> Cc: jgs@juniper.net
>>
>>
>> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt
>> has been successfully submitted by John Scudder and posted to the<= br> >> IETF repository.
>>
>> Filename: =A0 =A0 draft-scudder-deprecate-dpa-etal
>> Revision: =A0 =A0 00
>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Deprecation of BGP Path Attr= ibutes DPA, ADVERTISER and
>>RCID_PATH / CLUSTER_ID
>> Creation date: =A0 =A0 =A0 =A02012-11-14
>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Individual Submission
>> Number of pages: 2
>> URL:
>>http://www.ietf.org/internet-drafts/dr= aft-scudder-deprecate-dpa-etal-00.t
>>xt
>> Status:
>>http://datatracker.ietf.org/doc/draft-scudder-d= eprecate-dpa-etal
>> Htmlized:
>>http://tools.ietf.org/html/draft-scudder-deprecat= e-dpa-etal-00
>>
>>
>> Abstract:
>> =A0 This document requests IANA to deprecate several BGP path attr= ibutes,
>> =A0 associated with an abandoned Internet Draft and a Historic RFC= ,
>> =A0 respectively.
>>
>>
>>
>>
>> The IETF Secretariat
>
>
>_______________________________________________
>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

--0015175cae4a8ff8ca04ce7a3f34-- From hannes@juniper.net Thu Nov 15 00:17: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 1DFA121F869C for ; Thu, 15 Nov 2012 00:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[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 hai9FwXyhXLx for ; Thu, 15 Nov 2012 00:17:55 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8221F85C7 for ; Thu, 15 Nov 2012 00:17:55 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUKSlMsenSWUsGDjt5msOAHbUuWYPtG+9@postini.com; Thu, 15 Nov 2012 00:17:55 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, 15 Nov 2012 00:17:52 -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; Thu, 15 Nov 2012 00:17:52 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.205) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 15 Nov 2012 00:20:08 -0800 Received: from mail50-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 08:17:49 +0000 Received: from mail50-am1 (localhost [127.0.0.1]) by mail50-am1-R.bigfish.com (Postfix) with ESMTP id 98B5422013D for ; Thu, 15 Nov 2012 08:17:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I936eI1432I4015Izz1de0h1202h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1155h) Received: from mail50-am1 (localhost.localdomain [127.0.0.1]) by mail50-am1 (MessageSwitch) id 1352967466627379_30301; Thu, 15 Nov 2012 08:17:46 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.248]) by mail50-am1.bigfish.com (Postfix) with ESMTP id 8CDCE3A001D for ; Thu, 15 Nov 2012 08:17:46 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 08:17:37 +0000 Received: from macbookair-9.lan (66.129.224.53) by pod51010.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.233.3; Thu, 15 Nov 2012 08:17:36 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Thu, 15 Nov 2012 09:07:51 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <690E0595-A8F9-4E8A-B85C-D8FD2EFCF4EA@juniper.net> References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> To: "John G. Scudder" X-Mailer: Apple Mail (2.1283) 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%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Thu, 15 Nov 2012 08:17:56 -0000 support; On Nov 14, 2012, at 7:16 PM, John G. Scudder wrote: > Hi, >=20 > Nobody responded to my note of November 8 ("Deprecating path = attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, = I've submitted the below tiny Internet Draft. The substantive text of = the draft is: >=20 > 1. Introduction >=20 > As of this writing the BGP Path Attributes registry maintained by > IANA contains entries for DPA, ADVERTISER, and RCID_PATH / > CLUSTER_ID. The first of these is associated with > [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in > 1996. The latter are associated with [RFC1863], an RFC that was > reclassified as Historic in 2005. Neither of these specifications = is > in use now, nor ever was. >=20 >=20 > 2. IANA Considerations >=20 > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". >=20 > The rest is boilerplate, references, etc.=20 >=20 > I would like to ask the WG to adopt the draft. Since the draft is so = trivial, I would like to also request a WGLC, to run in parallel.=20 >=20 > Since many WG members will be on holiday for part of next week, let's = have the call for adoption + WGLC end on December 3. Please send any = comments before December 3. >=20 > Also, regarding the out-of-the-ordinary expedited WGLC: If there's any = disagreement whatsoever (with the content or wording of the draft, its = adoption, or indeed the expedited procedure itself), let's have only the = call for adoption end on December 3, and then we can do a normal WGLC = when appropriate. >=20 > Thanks, >=20 > --John (wearing two hats) >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-scudder-deprecate-dpa-etal-00.txt >> Date: November 14, 2012 1:06:11 PM EST >> To: jgs@bgp.nu >> Cc: jgs@juniper.net >>=20 >>=20 >> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt >> has been successfully submitted by John Scudder and posted to the >> IETF repository. >>=20 >> Filename: draft-scudder-deprecate-dpa-etal >> Revision: 00 >> Title: Deprecation of BGP Path Attributes DPA, = ADVERTISER and RCID_PATH / CLUSTER_ID >> Creation date: 2012-11-14 >> WG ID: Individual Submission >> Number of pages: 2 >> URL: = http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.tx= t >> Status: = http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal >> Htmlized: = http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 >>=20 >>=20 >> Abstract: >> This document requests IANA to deprecate several BGP path = attributes, >> associated with an abandoned Internet Draft and a Historic RFC, >> respectively. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From bruno.decraene@orange.com Thu Nov 15 00: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 7FFFF21F85EB for ; Thu, 15 Nov 2012 00:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.583, 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 KHHWbhAxcJH8 for ; Thu, 15 Nov 2012 00:57:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3607721F85CD for ; Thu, 15 Nov 2012 00:57:34 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 049F932431A; Thu, 15 Nov 2012 09:57:33 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DE4864C05D; Thu, 15 Nov 2012 09:57:32 +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; Thu, 15 Nov 2012 09:57:32 +0100 From: To: "John G. Scudder" Thread-Topic: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt Thread-Index: AQHNwpaxworxh8sPFUinnFbuN06n3pfqmSfg Date: Thu, 15 Nov 2012 08:57:31 +0000 Message-ID: <3454_1352969852_50A4AE7C_3454_467_1_53C29892C857584299CBF5D05346208A106836@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: 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.6] 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] Requesting WG adoption and WGLC of 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: Thu, 15 Nov 2012 08:57:35 -0000 Support for both. >From: Keyur Patel (keyupate) > >Support for both. > >Regards, >Keyur > >On 11/14/12 10:16 AM, "John G. Scudder" wrote: > >>Hi, >> >>Nobody responded to my note of November 8 ("Deprecating path attributes >>DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted >>the below tiny Internet Draft. The substantive text of the draft is: >> >>1. Introduction >> >> As of this writing the BGP Path Attributes registry maintained by >> IANA contains entries for DPA, ADVERTISER, and RCID_PATH / >> CLUSTER_ID. The first of these is associated with >> [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in >> 1996. The latter are associated with [RFC1863], an RFC that was >> reclassified as Historic in 2005. Neither of these specifications is >> in use now, nor ever was. >> >> >>2. IANA Considerations >> >> This document requests IANA to mark the BGP Path Attributes registry >> entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as >> "Deprecated". >> >>The rest is boilerplate, references, etc. >> >>I would like to ask the WG to adopt the draft. Since the draft is so >>trivial, I would like to also request a WGLC, to run in parallel. >> >>Since many WG members will be on holiday for part of next week, let's >>have the call for adoption + WGLC end on December 3. Please send any >>comments before December 3. >> >>Also, regarding the out-of-the-ordinary expedited WGLC: If there's any >>disagreement whatsoever (with the content or wording of the draft, its >>adoption, or indeed the expedited procedure itself), let's have only the >>call for adoption end on December 3, and then we can do a normal WGLC >>when appropriate. >> >>Thanks, >> >>--John (wearing two hats) >> >>Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>>draft-scudder-deprecate-dpa-etal-00.txt >>> Date: November 14, 2012 1:06:11 PM EST >>> To: jgs@bgp.nu >>> Cc: jgs@juniper.net >>> >>> >>> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt >>> has been successfully submitted by John Scudder and posted to the >>> IETF repository. >>> >>> Filename: draft-scudder-deprecate-dpa-etal >>> Revision: 00 >>> Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and >>>RCID_PATH / CLUSTER_ID >>> Creation date: 2012-11-14 >>> WG ID: Individual Submission >>> Number of pages: 2 >>> URL: >>>http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.t >>>xt >>> Status: >>>http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal >>> Htmlized: >>>http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 >>> >>> >>> Abstract: >>> This document requests IANA to deprecate several BGP path attributes, >>> associated with an abandoned Internet Draft and a Historic RFC, >>> respectively. >>> >>> >>> >>> >>> The IETF Secretariat >> >> >>_______________________________________________ >>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 jie.dong@huawei.com Thu Nov 15 01:09: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 9BE3121F869A for ; Thu, 15 Nov 2012 01:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 6g588NwcVuGj for ; Thu, 15 Nov 2012 01:09:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7421F867F for ; Thu, 15 Nov 2012 01:09:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALP07277; Thu, 15 Nov 2012 09:09:40 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 09:09:17 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 09:09:31 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.86]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 17:09:25 +0800 From: Jie Dong To: "John G. Scudder" , "idr@ietf. org" Thread-Topic: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt Thread-Index: AQHNwpSCUH1Ao9I7xECZnBf93OheR5fqnF7Q Date: Thu, 15 Nov 2012 09:09:24 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927325A72BC@szxeml504-mbx.china.huawei.com> References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Thu, 15 Nov 2012 09:09:45 -0000 Support both. Best regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Joh= n G. > Scudder > Sent: Thursday, November 15, 2012 2:17 AM > To: idr@ietf. org > Subject: [Idr] Requesting WG adoption and WGLC of > draft-scudder-deprecate-dpa-etal-00.txt >=20 > Hi, >=20 > Nobody responded to my note of November 8 ("Deprecating path attributes > DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted > the below tiny Internet Draft. The substantive text of the draft is: >=20 > 1. Introduction >=20 > As of this writing the BGP Path Attributes registry maintained by > IANA contains entries for DPA, ADVERTISER, and RCID_PATH / > CLUSTER_ID. The first of these is associated with > [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in > 1996. The latter are associated with [RFC1863], an RFC that was > reclassified as Historic in 2005. Neither of these specifications is > in use now, nor ever was. >=20 >=20 > 2. IANA Considerations >=20 > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". >=20 > The rest is boilerplate, references, etc. >=20 > I would like to ask the WG to adopt the draft. Since the draft is so triv= ial, I would > like to also request a WGLC, to run in parallel. >=20 > Since many WG members will be on holiday for part of next week, let's hav= e the > call for adoption + WGLC end on December 3. Please send any comments > before December 3. >=20 > Also, regarding the out-of-the-ordinary expedited WGLC: If there's any > disagreement whatsoever (with the content or wording of the draft, its > adoption, or indeed the expedited procedure itself), let's have only the = call for > adoption end on December 3, and then we can do a normal WGLC when > appropriate. >=20 > Thanks, >=20 > --John (wearing two hats) >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-scudder-deprecate-dpa-etal-= 00.txt > > Date: November 14, 2012 1:06:11 PM EST > > To: jgs@bgp.nu > > Cc: jgs@juniper.net > > > > > > A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt > > has been successfully submitted by John Scudder and posted to the > > IETF repository. > > > > Filename: draft-scudder-deprecate-dpa-etal > > Revision: 00 > > Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and > RCID_PATH / CLUSTER_ID > > Creation date: 2012-11-14 > > WG ID: Individual Submission > > Number of pages: 2 > > URL: > http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.t= xt > > Status: > http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal > > Htmlized: > http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 > > > > > > Abstract: > > This document requests IANA to deprecate several BGP path attributes, > > associated with an abandoned Internet Draft and a Historic RFC, > > respectively. > > > > > > > > > > The IETF Secretariat >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From chandra.appanna@yahoo.com Thu Nov 15 09:37: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 B054A21F8A75 for ; Thu, 15 Nov 2012 09:37:55 -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 VIShbUdSe0GZ for ; Thu, 15 Nov 2012 09:37:54 -0800 (PST) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id 938D621F8ACB for ; Thu, 15 Nov 2012 09:37:47 -0800 (PST) Received: from [98.139.215.140] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2012 17:37:46 -0000 Received: from [98.139.212.193] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 15 Nov 2012 17:37:46 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 15 Nov 2012 17:37:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 666719.1762.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 21964 invoked by uid 60001); 15 Nov 2012 17:37:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353001066; bh=Ii9FgF8rE/AXIHd7vSpkTXo3WgLH91BBGs8jY1havEo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Zyzl8jw9Xc1ASDtGERTzZmJv8rKkgom9ujxwgPQLUbZYn47aRgtKB9cHQtaxxQVExivGsun224zDN1FqWmX+ELuR3oz72GWG1Q+CMWmPSbHOlzXBSEurWHSWOzv1Lpe2GMYMHN2e3RCxZgMEJ7xH9sHI5mWNk64xgdVa49Emv9A= 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:In-Reply-To:MIME-Version:Content-Type; b=kLKl9AZOLAKEOy0KQQekwMFjcUHNjCWcTfcs6D/p9Pdtw/JWMXtFjimv8inxwc8pRt0+eqyEXglAuejdav+iMgTVH7SZCqfjkr++HrnRtQ48xpvgYQoYBQ8sR/Md+KjdOQINdKuqar4iDr4EBsnHRUxKa9PI1CLU+Z5EdvrlfjU=; X-YMail-OSG: VXC3RucVM1npdRIk3G08aOahsc6dGbXJwAb9YjVD76w2SIq f9tMxI7jwM9x_a6Va2uE3meyKxYIDSE0uC9DSGCDVHqBwksHE6wOeUkYUCZo tuZ7Py5viY3k1XRXUdGRd1Zb3rHPraH_niUR1Ca75pxpZRIEErOOsiiDr5bF WOA_JrvmpN_QyZD_OKuNS1q71eMXAaJiaMCDKwZtsACFJH3UgobJULuL35lh kKYVqke2Io.vswnVr.Gd.LoGWnj9K6ya05QnrtN5jXiCoCkGUVRloBwSBSUI D4sYC1f1fslFIUZmfqpwSUuqvOrLymLw9IVQF1eSNrIrGhtfX8EGrnx6PKxx Xo7LyUuj3xx0yoge5v0edG0xiwxQli3OWdy7g6jBrIEvdLv1Vy4dL2THVG5p mQkGZU.RKU_xcYrltr.swW6q7GugxDPAOvc5sUjhRWKxJ6VFa0l4u4Rw.fqN hdjUrzss3K_lz1LOHl3F.bP3c6tXfY5WNBo9JPTVBpIb2YyGkqTB7Tbgsf73 KWIs9XQUQ2kgmUXoof2IvzN7PWqJEwj2wPScNYtK50nnTvgvATWC8nxKUqDn 1rdTK0F8- Received: from [4.53.128.218] by web162902.mail.bf1.yahoo.com via HTTP; Thu, 15 Nov 2012 09:37:45 PST X-Rocket-MIMEInfo: 001.001, U3VwcG9ydCBmb3IgYm90aC4uCgpDaGFuZHJhLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSm9obiBHLiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ.ClRvOiAiaWRyQGlldGYuIG9yZyIgPGlkckBpZXRmLm9yZz4gClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTQsIDIwMTIgMTA6MTYgQU0KU3ViamVjdDogW0lkcl0gUmVxdWVzdGluZyBXRyBhZG9wdGlvbiBhbmQgV0dMQyBvZiBkcmFmdC1zY3VkZGVyLWRlcHJlY2F0ZS1kcGEtZXRhbC0wMC50eHQKIApIaSwKCk5vYm9keSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> Message-ID: <1353001065.19286.YahooMailNeo@web162902.mail.bf1.yahoo.com> Date: Thu, 15 Nov 2012 09:37:45 -0800 (PST) From: Chandra Appanna To: "idr@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1114306876-29471671-1353001065=:19286" Subject: Re: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt 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: Thu, 15 Nov 2012 17:37:55 -0000 --1114306876-29471671-1353001065=:19286 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support for both..=0A=0AChandra.=0A=0A=0A=0A_______________________________= _=0A From: John G. Scudder =0ATo: "idr@ietf. org" =0ASent: Wednesday, November 14, 2012 10:16 AM=0ASubject: [Idr] Requ= esting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt=0A = =0AHi,=0A=0ANobody responded to my note of November 8 ("Deprecating path at= tributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've su= bmitted the below tiny Internet Draft. The substantive text of the draft is= :=0A=0A1.=A0 Introduction=0A=0A=A0 As of this writing the BGP Path Attribu= tes registry maintained by=0A=A0 IANA contains entries for DPA, ADVERTISER= , and RCID_PATH /=0A=A0 CLUSTER_ID.=A0 The first of these is associated wi= th=0A=A0 [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned= in=0A=A0 1996.=A0 The latter are associated with [RFC1863], an RFC that w= as=0A=A0 reclassified as Historic in 2005.=A0 Neither of these specificati= ons is=0A=A0 in use now, nor ever was.=0A=0A=0A2.=A0 IANA Considerations= =0A=0A=A0 This document requests IANA to mark the BGP Path Attributes regi= stry=0A=A0 entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as=0A= =A0 "Deprecated".=0A=0AThe rest is boilerplate, references, etc. =0A=0AI w= ould like to ask the WG to adopt the draft. Since the draft is so trivial, = I would like to also request a WGLC, to run in parallel. =0A=0ASince many W= G members will be on holiday for part of next week, let's have the call for= adoption + WGLC end on December 3. Please send any comments before Decembe= r 3.=0A=0AAlso, regarding the out-of-the-ordinary expedited WGLC: If there'= s any disagreement whatsoever (with the content or wording of the draft, it= s adoption, or indeed the expedited procedure itself), let's have only the = call for adoption end on December 3, and then we can do a normal WGLC when = appropriate.=0A=0AThanks,=0A=0A--John (wearing two hats)=0A=0ABegin forward= ed message:=0A=0A> From: internet-drafts@ietf.org=0A> Subject: New Version = Notification for draft-scudder-deprecate-dpa-etal-00.txt=0A> Date: November= 14, 2012 1:06:11 PM EST=0A> To: jgs@bgp.nu=0A> Cc: jgs@juniper.net=0A> =0A= > =0A> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt=0A> ha= s been successfully submitted by John Scudder and posted to the=0A> IETF re= pository.=0A> =0A> Filename:=A0=A0=A0 draft-scudder-deprecate-dpa-etal=0A>= Revision:=A0=A0=A0 00=0A> Title:=A0=A0=A0 =A0=A0=A0 Deprecation of BGP P= ath Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID=0A> Creation date= :=A0=A0=A0 2012-11-14=0A> WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission= =0A> Number of pages: 2=0A> URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org= /internet-drafts/draft-scudder-deprecate-dpa-etal-00.txt=0A> Status:=A0 =A0= =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-et= al=0A> Htmlized:=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-scudder-de= precate-dpa-etal-00=0A> =0A> =0A> Abstract:=0A>=A0 This document requests = IANA to deprecate several BGP path attributes,=0A>=A0 associated with an a= bandoned Internet Draft and a Historic RFC,=0A>=A0 respectively.=0A> =0A> = =0A> =0A> =0A> The IETF Secretariat=0A=0A=0A_______________________________= ________________=0AIdr mailing list=0AIdr@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/idr --1114306876-29471671-1353001065=:19286 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Support for both..

Chandra.

From: John G. Sc= udder <jgs@juniper.net>
To:= "idr@ietf. org" <idr@ietf.org>
Sent: Wednesday, November 14, 2012 10:16 AM
Subject: [Idr] Requesting WG adoptio= n and WGLC of draft-scudder-deprecate-dpa-etal-00.txt
Hi,

Nobody responded to my note of November 8 ("Deprecating path a= ttributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've s= ubmitted the below tiny Internet Draft. The substantive text of the draft i= s:

1.  Introduction

  As of this writing the BGP P= ath Attributes registry maintained by
  IANA contains entries for = DPA, ADVERTISER, and RCID_PATH /
  CLUSTER_ID.  The first of = these is associated with
  [draft-ietf-idr-bgp-dpa-05], an Interne= t Draft that was abandoned in
  1996.  The latter are associa= ted with [RFC1863], an RFC that was
  reclassified as Historic in 2005.  Neither of these specifications is
  in use now, n= or ever was.


2.  IANA Considerations

  This do= cument requests IANA to mark the BGP Path Attributes registry
  en= tries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as
  "Deprec= ated".

The rest is boilerplate, references, etc.

I would lik= e to ask the WG to adopt the draft. Since the draft is so trivial, I would = like to also request a WGLC, to run in parallel.

Since many WG memb= ers will be on holiday for part of next week, let's have the call for adopt= ion + WGLC end on December 3. Please send any comments before December 3.
Also, regarding the out-of-the-ordinary expedited WGLC: If there's an= y disagreement whatsoever (with the content or wording of the draft, its ad= option, or indeed the expedited procedure itself), let's have only the call= for adoption end on December 3, and then we can do a normal WGLC when appropriate.

Thanks,

--John (wearing two hats)

B= egin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-scudder-deprec= ate-dpa-etal-00.txt
> Date: November 14, 2012 1:06:11 PM EST
> = To: jgs@bgp.nu<= /a>
> Cc: jgs@juniper.net
>
>
> A new version of I= -D, draft-scudder-deprecate-dpa-etal-00.txt
> has been successfully s= ubmitted by John Scudder and posted to the
> IETF repository.
>=
> Filename:    draft-scudder-deprecate-dpa-etal
= > Revision:    00
> Title:     = ;   Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_= PATH / CLUSTER_ID
> Creation date:    2012-11-14
> = WG ID:        Individual Submission
> = Number of pages: 2
> URL:            <= a href=3D"http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-e= tal-00.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-scu= dder-deprecate-dpa-etal-00.txt
> Status:      &nbs= p;   http://datatracker.ietf.org/doc/draft-scudder= -deprecate-dpa-etal
> Htmlized:        http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00<= /a>
>
>
> Abstract:
>  This document reques= ts IANA to deprecate several BGP path attributes,
>  associated= with an abandoned Internet Draft and a Historic RFC,
>  respectivel= y.
>
>
>
>
> The IETF Secretariat

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


--1114306876-29471671-1353001065=:19286-- From jeff.tantsura@ericsson.com Thu Nov 15 11:37: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 C353521F8559 for ; Thu, 15 Nov 2012 11:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 9TUxonb3dN8h for ; Thu, 15 Nov 2012 11:37:51 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 170C121F8522 for ; Thu, 15 Nov 2012 11:37:51 -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 qAFJiCnE001127; Thu, 15 Nov 2012 13:44:13 -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; Thu, 15 Nov 2012 14:37:43 -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; Thu, 15 Nov 2012 14:37:43 -0500 From: Jeff Tantsura To: "John G. Scudder" , "idr@ietf. org" Thread-Topic: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt Thread-Index: AQHNwpSFuvBLU0Wpg06K6Rc/L6Ag0JfrTBpA Date: Thu, 15 Nov 2012 19:37:43 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748390A228E@EUSAAMB109.ericsson.se> References: <20121114180611.17620.93258.idtracker@ietfa.amsl.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Thu, 15 Nov 2012 19:37:51 -0000 Yes/support -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = G. Scudder Sent: Wednesday, November 14, 2012 10:17 AM To: idr@ietf. org Subject: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-d= pa-etal-00.txt Hi, Nobody responded to my note of November 8 ("Deprecating path attributes DPA= , ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted the = below tiny Internet Draft. The substantive text of the draft is: 1. Introduction As of this writing the BGP Path Attributes registry maintained by IANA contains entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID. The first of these is associated with [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in 1996. The latter are associated with [RFC1863], an RFC that was reclassified as Historic in 2005. Neither of these specifications is in use now, nor ever was. 2. IANA Considerations This document requests IANA to mark the BGP Path Attributes registry entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as "Deprecated". The rest is boilerplate, references, etc.=20 I would like to ask the WG to adopt the draft. Since the draft is so trivia= l, I would like to also request a WGLC, to run in parallel.=20 Since many WG members will be on holiday for part of next week, let's have = the call for adoption + WGLC end on December 3. Please send any comments be= fore December 3. Also, regarding the out-of-the-ordinary expedited WGLC: If there's any disa= greement whatsoever (with the content or wording of the draft, its adoption= , or indeed the expedited procedure itself), let's have only the call for a= doption end on December 3, and then we can do a normal WGLC when appropriat= e. Thanks, --John (wearing two hats) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for=20 > draft-scudder-deprecate-dpa-etal-00.txt > Date: November 14, 2012 1:06:11 PM EST > To: jgs@bgp.nu > Cc: jgs@juniper.net >=20 >=20 > A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt > has been successfully submitted by John Scudder and posted to the IETF=20 > repository. >=20 > Filename: draft-scudder-deprecate-dpa-etal > Revision: 00 > Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH= / CLUSTER_ID > Creation date: 2012-11-14 > WG ID: Individual Submission > Number of pages: 2 > URL: http://www.ietf.org/internet-drafts/draft-scudder-deprec= ate-dpa-etal-00.txt > Status: http://datatracker.ietf.org/doc/draft-scudder-deprecate-= dpa-etal > Htmlized: http://tools.ietf.org/html/draft-scudder-deprecate-dpa-e= tal-00 >=20 >=20 > Abstract: > This document requests IANA to deprecate several BGP path attributes, > associated with an abandoned Internet Draft and a Historic RFC, > respectively. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Fri Nov 16 10:53: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 0000C21F8AD5; Fri, 16 Nov 2012 10:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 PTqwJ4n2dS12; Fri, 16 Nov 2012 10:53:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8423F21F84CC; Fri, 16 Nov 2012 10:53:38 -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: <20121116185338.10417.56848.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 10:53:38 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-custom-decision-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, 16 Nov 2012 18:53:39 -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 Custom Decision Process Author(s) : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-02.txt Pages : 9 Date : 2012-11-16 Abstract: The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-custom-decision-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-custom-decision-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From warren@kumari.net Fri Nov 16 18:20: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 5B51221F8B06 for ; Fri, 16 Nov 2012 18:20:02 -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 Y86GF+mCwh9i for ; Fri, 16 Nov 2012 18:20:01 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516F021F890F for ; Fri, 16 Nov 2012 18:20:00 -0800 (PST) Received: from [192.168.2.103] (unknown [209.133.29.2]) by vimes.kumari.net (Postfix) with ESMTPSA id A7FF91B405D3; Fri, 16 Nov 2012 21:19:59 -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: <60DEDD93F5E54B4AB55647B8B6C748390A228E@EUSAAMB109.ericsson.se> Date: Fri, 16 Nov 2012 21:19:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <253D76FC-C5F7-4835-B33C-643CBBE3C715@kumari.net> References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> <60DEDD93F5E54B4AB55647B8B6C748390A228E@EUSAAMB109.ericsson.se> To: Jeff Tantsura X-Mailer: Apple Mail (2.1499) Cc: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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, 17 Nov 2012 02:20:02 -0000 =85 and the support text is now longer than the entire draft (- = boilerplate ) :-) Support for both=85 W On Nov 15, 2012, at 2:37 PM, Jeff Tantsura = wrote: > Yes/support >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = John G. Scudder > Sent: Wednesday, November 14, 2012 10:17 AM > To: idr@ietf. org > Subject: [Idr] Requesting WG adoption and WGLC of = draft-scudder-deprecate-dpa-etal-00.txt >=20 > Hi, >=20 > Nobody responded to my note of November 8 ("Deprecating path = attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, = I've submitted the below tiny Internet Draft. The substantive text of = the draft is: >=20 > 1. Introduction >=20 > As of this writing the BGP Path Attributes registry maintained by > IANA contains entries for DPA, ADVERTISER, and RCID_PATH / > CLUSTER_ID. The first of these is associated with > [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in > 1996. The latter are associated with [RFC1863], an RFC that was > reclassified as Historic in 2005. Neither of these specifications = is > in use now, nor ever was. >=20 >=20 > 2. IANA Considerations >=20 > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". >=20 > The rest is boilerplate, references, etc.=20 >=20 > I would like to ask the WG to adopt the draft. Since the draft is so = trivial, I would like to also request a WGLC, to run in parallel.=20 >=20 > Since many WG members will be on holiday for part of next week, let's = have the call for adoption + WGLC end on December 3. Please send any = comments before December 3. >=20 > Also, regarding the out-of-the-ordinary expedited WGLC: If there's any = disagreement whatsoever (with the content or wording of the draft, its = adoption, or indeed the expedited procedure itself), let's have only the = call for adoption end on December 3, and then we can do a normal WGLC = when appropriate. >=20 > Thanks, >=20 > --John (wearing two hats) >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for=20 >> draft-scudder-deprecate-dpa-etal-00.txt >> Date: November 14, 2012 1:06:11 PM EST >> To: jgs@bgp.nu >> Cc: jgs@juniper.net >>=20 >>=20 >> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt >> has been successfully submitted by John Scudder and posted to the = IETF=20 >> repository. >>=20 >> Filename: draft-scudder-deprecate-dpa-etal >> Revision: 00 >> Title: Deprecation of BGP Path Attributes DPA, = ADVERTISER and RCID_PATH / CLUSTER_ID >> Creation date: 2012-11-14 >> WG ID: Individual Submission >> Number of pages: 2 >> URL: = http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.tx= t >> Status: = http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal >> Htmlized: = http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 >>=20 >>=20 >> Abstract: >> This document requests IANA to deprecate several BGP path = attributes, >> associated with an abandoned Internet Draft and a Historic RFC, >> respectively. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 >=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 >=20 --=20 "He who laughs last, thinks slowest."=20 -- Anonymous From randy@psg.com Sat Nov 17 00:58: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 74A1F21F861A for ; Sat, 17 Nov 2012 00:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Seg+xMnHW3-a for ; Sat, 17 Nov 2012 00:58:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2037B21F8618 for ; Sat, 17 Nov 2012 00:58:33 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TZeER-0006WC-CU; Sat, 17 Nov 2012 08:58:32 +0000 Date: Sat, 17 Nov 2012 15:58:27 +0700 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> 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] Requesting WG adoption and WGLC of 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, 17 Nov 2012 08:58:33 -0000 read and support. when you cut the draft-ietf-idr version, it might reduce confusion if it made clear that CLUSTER_ID != CLUSTER_LIST randy From shares@ndzh.com Sat Nov 17 17:48: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 6F84E21F863F for ; Sat, 17 Nov 2012 17:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wVxdKIad5MJL for ; Sat, 17 Nov 2012 17:48:14 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B85D621F863A for ; Sat, 17 Nov 2012 17:48:13 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; Received: from SKH2012HPLT (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 89927-1945496 for multiple; Sat, 17 Nov 2012 20:48:09 -0500 From: "Susan Hares" To: "'John G. Scudder'" , "'idr@ietf. org'" References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sat, 17 Nov 2012 20:48:07 -0500 Message-ID: <004c01cdc52e$c2035c20$460a1460$@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: AQISjlPaKXKo7+qdMrxHPjL5B4IsvQHb1ptdl1ZiCTA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Sun, 18 Nov 2012 01:48:14 -0000 +1 support Sue Hares -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net] Sent: Wednesday, November 14, 2012 1:17 PM To: idr@ietf. org Cc: Susan Hares Subject: Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt Hi, Nobody responded to my note of November 8 ("Deprecating path attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted the below tiny Internet Draft. The substantive text of the draft is: 1. Introduction As of this writing the BGP Path Attributes registry maintained by IANA contains entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID. The first of these is associated with [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in 1996. The latter are associated with [RFC1863], an RFC that was reclassified as Historic in 2005. Neither of these specifications is in use now, nor ever was. 2. IANA Considerations This document requests IANA to mark the BGP Path Attributes registry entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as "Deprecated". The rest is boilerplate, references, etc. I would like to ask the WG to adopt the draft. Since the draft is so trivial, I would like to also request a WGLC, to run in parallel. Since many WG members will be on holiday for part of next week, let's have the call for adoption + WGLC end on December 3. Please send any comments before December 3. Also, regarding the out-of-the-ordinary expedited WGLC: If there's any disagreement whatsoever (with the content or wording of the draft, its adoption, or indeed the expedited procedure itself), let's have only the call for adoption end on December 3, and then we can do a normal WGLC when appropriate. Thanks, --John (wearing two hats) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for > draft-scudder-deprecate-dpa-etal-00.txt > Date: November 14, 2012 1:06:11 PM EST > To: jgs@bgp.nu > Cc: jgs@juniper.net > > > A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt > has been successfully submitted by John Scudder and posted to the IETF > repository. > > Filename: draft-scudder-deprecate-dpa-etal > Revision: 00 > Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID > Creation date: 2012-11-14 > WG ID: Individual Submission > Number of pages: 2 > URL: http://www.ietf.org/internet-drafts/draft-scudder-deprecate-dpa-etal-00.txt > Status: http://datatracker.ietf.org/doc/draft-scudder-deprecate-dpa-etal > Htmlized: http://tools.ietf.org/html/draft-scudder-deprecate-dpa-etal-00 > > > Abstract: > This document requests IANA to deprecate several BGP path attributes, > associated with an abandoned Internet Draft and a Historic RFC, > respectively. > > > > > The IETF Secretariat From pmohapat@cisco.com Sun Nov 18 22: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 6A18D21F8593 for ; Sun, 18 Nov 2012 22:49:50 -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 JM-JIu0MN+To for ; Sun, 18 Nov 2012 22:49:49 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C756421F8576 for ; Sun, 18 Nov 2012 22:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=346; q=dns/txt; s=iport; t=1353307789; x=1354517389; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Bb8Fu12jtkRxMaTBWCSXeuQOuNTqFAPdo1oJxTWWwCo=; b=mkxKFPGeF4hXuXB+yNWKCWKZ8YznT/+3JHGmazY/be74ns12HMsisf0s W2q3Z3yQDTYE0ctn8IvZLhv/sIlu3CqHZTMBNW29ZOA9ncj9qbOegbyYv Fl8N1ovacYpgEzm6abmH+4jBwaMTX+y/qgabXhYC9Zn7M+dW+n4R27PDw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADTVqVCtJV2c/2dsb2JhbABFwz6BCIIeAQEBAwESASdEDQEIIhRCJQIEARoah2UGoAefLpBgYQOkVIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6900"; a="143819043" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 19 Nov 2012 06:49:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAJ6nm8T031856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Nov 2012 06:49:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.237]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 19 Nov 2012 00:49:48 -0600 From: "Pradosh Mohapatra (pmohapat)" To: "John G. Scudder" , "idr@ietf. org" Thread-Topic: [Idr] Requesting WG adoption and WGLC of draft-scudder-deprecate-dpa-etal-00.txt Thread-Index: AQHNxiIQSA/b9tllSkWxlLWvrisBJg== Date: Mon, 19 Nov 2012 06:49:47 +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.4.120824 x-originating-ip: [10.21.66.182] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19378.005 x-tm-as-result: No--25.504500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Mon, 19 Nov 2012 06:49:50 -0000 John, > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". Given that these have never been used/deployed, won't it be better to reuse the values? Something like "Unavailable" for six months followed by "Unassigned"? - Pradosh From internet-drafts@ietf.org Mon Nov 19 06:26: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 21EF721F85D6; Mon, 19 Nov 2012 06:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 kez4v49ur-6w; Mon, 19 Nov 2012 06:25:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFD121F8470; Mon, 19 Nov 2012 06:25:29 -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: <20121119142529.9958.28769.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 06:25:29 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-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, 19 Nov 2012 14:26:00 -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 : Assigned BGP extended communities Author(s) : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-04.txt Pages : 6 Date : 2012-11-19 Abstract: This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-reserved-extended-communiti= es There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-reserved-extended-communi= ties-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bruno.decraene@orange.com Mon Nov 19 06:32: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 0E3C021F8608 for ; Mon, 19 Nov 2012 06:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.292, 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 EA-n7MT9FzX6 for ; Mon, 19 Nov 2012 06:32:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7DB21F85E0 for ; Mon, 19 Nov 2012 06:32:25 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2362518C437 for ; Mon, 19 Nov 2012 15:32:24 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0BA0F35C055 for ; Mon, 19 Nov 2012 15:32:24 +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, 19 Nov 2012 15:32:23 +0100 From: To: "idr@ietf. org" Thread-Topic: New Version Notification for draft-ietf-idr-reserved-extended-communities-04.txt Thread-Index: AQHNxmKwWjFPsb2m20moBqbPe4jZXA== Date: Mon, 19 Nov 2012 14:32:23 +0000 Message-ID: <23226_1353335544_50AA42F8_23226_1858_1_53C29892C857584299CBF5D05346208A108F1B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: [Idr] New Version Notification for draft-ietf-idr-reserved-extended-communities-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, 19 Nov 2012 14:32:26 -0000 SGkgYWxsLA0KDQpDaGFuZ2VzIC0wNDogbm8gY2hhbmdlLCByZWZyZXNoIG9ubHkuIA0KRGlmZjog aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlkci1yZXNlcnZl ZC1leHRlbmRlZC1jb21tdW5pdGllcy0wNC50eHQNCg0KDQpSZWdhcmRpbmcgZG9jIHN0YXR1cywg d2UgYmVsaWV2ZSB0aGUgZHJhZnQgaXMgc3RhYmxlIGFuZCB3ZSBhcmUgd2FpdGluZyBmb3IgdGhl IG5vcm1hdGl2ZSBkZXBlbmRlbmN5IGRyYWZ0LWlldGYtaWRyLWFzNG9jdGV0LWV4dGNvbW0tZ2Vu ZXJpYy1zdWJ0eXBlIHRvIHByb2dyZXNzLg0KDQpSZWdhcmRzLA0KQnJ1bm8NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE5LCAy MDEyIDM6MjYgUE0NClRvOiBERUNSQUVORSBCcnVubyBPTE5DL09MTg0KQ2M6IHBpZXJyZS5mcmFu Y29pc0BpbWRlYS5vcmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaWV0Zi1pZHItcmVzZXJ2ZWQtZXh0ZW5kZWQtY29tbXVuaXRpZXMtMDQudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtaWRyLXJlc2VydmVkLWV4dGVuZGVkLWNvbW11 bml0aWVzLTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCcnVubyBE ZWNyYWVuZSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJ IGRyYWZ0LWlldGYtaWRyLXJlc2VydmVkLWV4dGVuZGVkLWNvbW11bml0aWVzDQpSZXZpc2lvbjoJ IDA0DQpUaXRsZToJCSBBc3NpZ25lZCBCR1AgZXh0ZW5kZWQgY29tbXVuaXRpZXMNCkNyZWF0aW9u IGRhdGU6CSAyMDEyLTExLTE5DQpXRyBJRDoJCSBpZHINCk51bWJlciBvZiBwYWdlczogNg0KVVJM OiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWlkci1yZXNlcnZlZC1leHRlbmRlZC1jb21tdW5pdGllcy0wNC50eHQNClN0YXR1czogICAg ICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1yZXNl cnZlZC1leHRlbmRlZC1jb21tdW5pdGllcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1yZXNlcnZlZC1leHRlbmRlZC1jb21tdW5pdGll cy0wNA0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWlkci1yZXNlcnZlZC1leHRlbmRlZC1jb21tdW5pdGllcy0wNA0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBJQU5BIHJlZ2lzdHJ5IGluIG9yZGVyIHRv IGFzc2lnbiBub24tDQogICB0cmFuc2l0aXZlIGV4dGVuZGVkIGNvbW11bml0aWVzIGZyb20uICBU aGVzZSBhcmUgc2ltaWxhciB0byB0aGUNCiAgIGV4aXN0aW5nIHdlbGwta25vd24gQkdQIGNvbW11 bml0aWVzIGRlZmluZWQgaW4gUkZDIDE5OTcgYnV0IHByb3ZpZGUgYQ0KICAgY29udHJvbCBvdmVy IGludGVyLUFTIGNvbW11bml0eSBhZHZlcnRpc2VtZW50IGFzLCBwZXIgUkZDIFJGQyA0MzYwLA0K ICAgdGhleSBhcmUgbm90IHRyYW5zaXRpdmUgYWNyb3NzIEF1dG9ub21vdXMgU3lzdGVtIGJvdW5k YXJpZXMuDQoNCiAgIEZvciB0aGF0IHB1cnBvc2UsIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUg dXNlIG9mIHRoZSByZXNlcnZlZA0KICAgQXV0b25vbW91cyBTeXN0ZW0gbnVtYmVyIDAuNjU1MzUg aW4gdGhlIG5vbi10cmFuc2l0aXZlIGdlbmVyaWMgZm91ci0NCiAgIG9jdGV0IEFTIHNwZWNpZmlj IGV4dGVuZGVkIGNvbW11bml0eSB0eXBlLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZy YW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From brian.e.carpenter@gmail.com Tue Nov 20 06:51: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 3ADE521F856E for ; Tue, 20 Nov 2012 06:51:41 -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 aQMC4HssU9SP for ; Tue, 20 Nov 2012 06:51:40 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D55A21F84CE for ; Tue, 20 Nov 2012 06:51:39 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2601714wgb.13 for ; Tue, 20 Nov 2012 06:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/aNuhreAE58mHpsU6TSk+WKCZKLe9Yi7p+a/t5Ea2qc=; b=xwuChsTZQbeR0HSYhGxgJ71JUoHr0ey5bwBiOXJ3BvRAOQghLScpEc+m2/Wj/zqhKv Lzz3qU3P+eXBO9BV8+kaIAHhKNLOwkeUnPucLzA0QVo8nZctdNK3HQrJPbIe9ytJh0Rj Iy74YnrZJ5sS4ExyaTPGd/HEDqeFCClSfZlVhkM/OwBoIqtlXIAHWOwAGguUmwZ9BnRa DtuPqo6YMaFIL+9i39zRF92ai+HZHwVyGRtajZkiYIUlcVkYdbdQff+zMgyAyevTVUlI ncHffk1e0pBG3dt8sZ3gtBu3jFard4mqaTBNxuEmvFHnDIqnaeRjGrIqNvQqxJgnFfnb Em0A== Received: by 10.180.101.231 with SMTP id fj7mr14929179wib.4.1353423098309; Tue, 20 Nov 2012 06:51:38 -0800 (PST) Received: from [128.232.110.79] (c079.al.cl.cam.ac.uk. [128.232.110.79]) by mx.google.com with ESMTPS id hv4sm18052404wib.0.2012.11.20.06.51.34 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 06:51:35 -0800 (PST) Message-ID: <50AB98FC.5080702@gmail.com> Date: Tue, 20 Nov 2012 14:51:40 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Shitanshu Shah (svshah)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Sandeep Bajaj Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Tue, 20 Nov 2012 14:51:41 -0000 On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: > Keeping idr in the loop.. > > Brian, > Your review comments are addressed in the revised draft: > http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange > Please review and suggest/comment if any.. I think you still need to state somewhere that if a DSCP is signalled, the two parties must have an out-of-band agreement about what that DSCP means. There's an active discussion on this topic in the TSVWG (draft-polk-diffserv-stds-problem-statement, draft-geib-tsvwg-diffserv-intercon, etc.) > 3. What is the relationship of this work to > >>>>>> draft-knoll-idr-qos-attribute? >>>>> I'll have to evaluate that. Will look into it. Still open, I think. Brian > > Thanks > Shitanshu > > > On 7/13/12 6:12 PM, "Shitanshu Shah (svshah)" wrote: > >> >> On 7/13/12 8:52 AM, "Brian E Carpenter" >> wrote: >> >>> Hi, >>> >>> On 13/07/2012 07:44, Shitanshu Shah (svshah) wrote: >>>> Hi Brian, >>>> >>>> Sorry for the delay in the response. Keeping co-authors also in the >>>> loop. >>>> >>>> Few clarifications >>>> - The proposal is not about end to end SLA. It is about exchanging SLA >>>> between 2 domains. >>> Does that mean two adjacent domains, or two domains separated by >>> non-participating domains? >> It could be any. Adjacent or two domains separated by non-participating >> ones. >> >> >>> This is critical, because if there are intermediate domains, we must >>> assume >>> that they will change the DSCP, because it is a mutable field. >> >> It makes sense for SLA exchange between those two domains, that are >> separated by >> non-participating domains, to take place only if those two domains fall >> under >> same controlled administration. I do not see otherwise why would there be >> a >> need for SLA exchange. >> >> For example, Site A and Site B are administered by Enterprise XYZ. Even >> though >> XYZ's provider for Site A means "EF" for voice and XYZ's provider for Site >> B >> means "CS5" for voice. XYZ understands those differences for voice between >> Site A and Site B. Thus SLA exchange from one site to the other in the >> context >> of any "EF" or "CS4" still is okay. A mapping may be defined at the >> receiver >> to handle the differences. >> >> If Site A and Site B are managed by two different Enterprise XYZ and ABC >> respectively then I do not see why SLA exchange to take place among them >> irrespective of what dscp they use for voice traffic. >> >> >>>> - SLA exchange does not necessarily mean automatic provision of >>>> forwarding >>>> policy. Draft does not mandate that. though a vendor may use this >>>> exchange >>>> to automatically provision forwarding policy. >>> OK, these points need to be clearly stated in the Introduction, I think. >>> >>>> Couple of use-cases are described in "Deployment Considerations" >>>> section. >>>> I can clarify further that section with any clarification that comes >>>> out >>>> of this discussion. >>>> >>>> Taking couple of use-cases to describe further in the context of >>>> Diffserv >>>> based SLA. >>>> 1. >>>> - SLA exchange between CE and PE where they are connected physically or >>>> virtually. >>>> - Customer buys voice (1 mbps), video (5 mbps) and data (2 mbps) >>>> service >>>> from the Provider. >>>> - If provider supports that voice, video and data service with EF, AF4 >>>> and >>>> AF2 then instead >>>> of telling those EF, AF4, AF2 code-points over the phone to the >>>> customer, they are, along >>>> with rates, conveyed thru BGP >>>> >>>> SLA exchange here does not have any responsibility to tell CE domain >>>> which end-points should >>>> be using which dscp code-point or which ip addresses/flows should be >>>> mapping to which dscp >>>> Code-point. Thus there is no dscp mapping to or from to be conveyed >>>> here >>> Well, you seem to expect the receiver to parse "Traffic Class Description >>> - Ascii Description of the Traffic Class" somehow and configure diffserv >>> classification and marking accordingly. So the receiver has to figure out >>> how the DSCPs that the provider accepts map to its internal DSCPs (if >>> any). >> Yes if receiver is using different dscp internally then mapping has to >> happen >> between Provider's dscp and internal dscp. And that is what we have >> highlighted >> in Section 6.1. Repeating what I mentioned above, aim of this proposal is >> to >> define a protocol to exchange SLA but not the provision of the mapping >> between >> sender and receiver's code-points. Yeah, if user (user here means vendor >> or >> administrator) is not able to come up with his/her own mapping to use with >> exchanged SLA and if it is left with any ambiguity then we need to look >> into >> it but then we first have to know the use-case where such condition may >> arise. >> In worst case it will be supplemental proposal which still won't not >> change >> protocol of SLA exchange. >> >> >>>> 2. >>>> - In VPN deployments where dscp code-point is preserved over VPN >>>> tunnels. >>>> - Specific Enterprise n/w let's say is spanned over different regions >>>> eg. >>>> San Jose, Atlanta, >>>> Orlando where there is a vpn network between those sites. San Jose >>>> eg. >>>> may convey its SLA >>>> to Atlanta, Olando for EF, AF4 and AF2 traffic. >>>> >>>> Here again there is no responsibility to tell which end-points should >>>> be >>>> using which dscp >>>> Code-points. All San Jose is telling Orlando is that if it is sending >>>> any EF traffic towards >>>> San Jose then it does not have to send more than 1 mbps >>> Yes, once they agree on what "EF" is and which DSCP value it uses. >>> Again it seems to depend on the ASCII description. >>> >>>> I've looked at RFC3140. PHB id is something may make sense to be added >>>> as >>>> one of the SLA exchange >>>> Parameter. Where can I find list of PHB ids? >>> There's a registry: >>> http://www.iana.org/assignments/phbid-codes/phbid-codes.xml >>> However, it's empty - in other words, nobody has found it necessary to >>> register >>> a non-default value. That means that today, only the standardised DSCP >>> values >>> at http://www.iana.org/assignments/dscp-registry/dscp-registry.xml >>> have PHB IDs. >>> >>> However, if an operator wanted its own PHB ID for use in its own SLAs, >>> it should be easy to register one. (I see that I'm a designated expert >>> for this.) >>> >>> This was set up to provide flexibility - in practice people seem to >>> prefer standard DSCPs and PHBs, but at the time people insisted on >>> flexibility. >> >> Sure, understood. And in those deployments that use this flexible PHB ids, >> SLA exchange needs to be in the context of such PHB ids. >> >> Regards, >> Shitanshu >> >> >>> Regards >>> >>> Brian >>> >>>> >>>> Thanks >>>> Shitanshu >>>> >>>> >>>> On 6/9/12 1:32 AM, "Brian E Carpenter" >>>> wrote: >>>> >>>>> Hi Shitanshu, >>>>> >>>>> I think what is missing in the draft is a clear explanation of the >>>>> possible >>>>> deployment models and how they relate to the diffserv architecture, >>>>> which >>>>> is very explicit in defining the concept of diffserv domains. >>>>> Basically >>>>> that model requires DSCP mapping at every domain boundary (even if it >>>>> is >>>>> a trivial 1:1 mapping). I think you have to be very explicit that if >>>>> the BGP attribute is transmitted across a diffserv domain boundary, >>>>> the >>>>> conveyed DSCPs MUST be mapped at that boundary (with a note that >>>>> domains >>>>> could agree on a 1:1 mapping if they were within a single SLA >>>>> community). >>>>> Or you use the PHBID instead, in which case it is by definition mapped >>>>> locally inside each domain. >>>>> >>>>> By the way, as well as RFC 2475, the architecture is discussed in >>>>> RFC 3086 and in B.E. Carpenter and K. Nichols, Differentiated Services >>>>> in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> On 2012-06-06 17:57, svshah wrote: >>>>>> Thanks a bunch Brian for your comments. See further inline for >>>>>> response >>>>>> >>>>>> On 6/6/12 6:00 AM, "Brian E Carpenter" >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have some comments on your draft: >>>>>>> >>>>>>>> 0x02 = IP_DSCP, (length = 08-bits, value = 0..63) >>>>>>> 1. The DSCP is a 6 bit field (the other two bits are ECN, and you >>>>>>> can't touch them). >>>>>> If you are referring to change the length field to 6-bits, I agree. >>>>>> It >>>>>> does >>>>>> not have to be 8-bits. >>>>>> >>>>>>> 2. More seriously, the DSCP *by definition* is domain-specific. How >>>>>>> can it >>>>>>> be valid or meaningful in an end-to-end SLA? >>>>>> This question requires multiple answers, hopefully I can itemize them >>>>>> appropriately >>>>>> >>>>>> - The proposal in the draft is not specifically only for end-to-end >>>>>> SLA. The >>>>>> intentional use-case of the draft is with next hop SLA like PE to CE >>>>>> SLA, >>>>>> where PE may have SLA defined eg. for Diffserv classes which CE >>>>>> traffic >>>>>> will >>>>>> be subject to. Based on your comment I assume, you are not >>>>>> questioning >>>>>> this >>>>>> specific use case but are referring to SLA exchange across multiple >>>>>> hops >>>>>> >>>>>> - Beyond just next hop, one can envision a use-case where ASs, >>>>>> multiple >>>>>> sites spanned across multiple regions, managed by one corporate or >>>>>> provider >>>>>> may want to exchange SLAs site to site to manage traffic multi-site >>>>>> >>>>>> - Also to note that SLA exchange format is defined to send SLA to a >>>>>> specific >>>>>> one or specific list of recipients. If this SLA exchange is across >>>>>> multiple >>>>>> hops then intermediate speakers (ones that are not in the recipient >>>>>> list) >>>>>> are not subject to SLA >>>>>> >>>>>> - Receiver, for which SLA is meant to, does not have to listen to >>>>>> those >>>>>> SLA >>>>>> messages. They can ignore them. The point being that in a well >>>>>> designed >>>>>> network, SLAs will be accepted only if by design sender and receivers >>>>>> are >>>>>> expected to do so >>>>>> >>>>>> >>>>>> Please fill me in if you are referring to any specific point beyond >>>>>> ones >>>>>> described above >>>>>> >>>>>> >>>>>> >>>>>>> I realise that you say >>>>>>> >>>>>>>> Typical use-case aimed with this proposal is for Provider to >>>>>>>> advertise contracted SLA to Customer Edge. >>>>>>> but that is unenforceable; BGP speakers can't be expected to know >>>>>>> about QoS domain boundaries, so we must assume that this attribute >>>>>>> might cross such boundaries. In fact, you admit this in section >>>>>>> 6.1. The traffic class mapping described there MUST be applied >>>>>>> at every diffserv domain boundary that this SLA attribute crosses, >>>>>>> even to map DSCP1 to DSCP2. That seems like a bit of a deployment >>>>>>> and operational nightmare. >>>>>> While programming QoS automatically with this SLA exchange can be >>>>>> very >>>>>> helpful, there are other benefits that this method provides that >>>>>> simplifies >>>>>> administrators life specifically ones who are not very fluent on some >>>>>> of the >>>>>> QoS specifics, >>>>>> >>>>>> Taking an example Where SLA with PE is based on Diffserv classes with >>>>>> specific rates for each diffserv class >>>>>> 1) When admin has to provision QoS policy on CE, they first need to >>>>>> know >>>>>> what diffserv classes with what associated rates >>>>>> >>>>>> 2) Once that is known, translate them to Vendor specific provisioning >>>>>> (eg. >>>>>> What classification rules/configurations in Vendor's provisioning >>>>>> language >>>>>> and same for associated actions) >>>>>> >>>>>> 3) As required, define traffic class mapping as you pointed out >>>>>> >>>>>> 4) Once came up with appropriate mapping and policy, associate them >>>>>> with the >>>>>> forwarding >>>>>> >>>>>> >>>>>> While, in some cases if not all, there may be challenges for step >>>>>> (3), >>>>>> customers get it so much simplified even with step (1) and (2) >>>>>> >>>>>> >>>>>>> This is exactly what PHBIDs were intended for. Please see RFC3140. >>>>>>> You should use those instead of DSCP values. Or better still, >>>>>>> generalise the PHBID definition to cover MPLS and 802.1Q as well. >>>>>> I'll certainly look into it. I'll definitely be happy if something >>>>>> can >>>>>> be >>>>>> leveraged from RFC3140 or if can be enhanced in the context. >>>>>> >>>>>>> 3. What is the relationship of this work to >>>>>>> draft-knoll-idr-qos-attribute? >>>>>> I'll have to evaluate that. Will look into it. >>>>>> >>>>>>> 4. Finally, please run the draft through >>>>>>> http://www.ietf.org/tools/idnits/. >>>>>>> There are a lot of warnings. >>>>>> Sure, thx. >>>>>> >>>>>> Looking forward for your response/comments/suggestions >>>>>> >>>>>> >>>>>> Regards, >>>>>> Shitanshu >>>>>> >>>>>> >>>>>>> Regards >>>>>>> Brian Carpenter >>>> > > From jgs@juniper.net Tue Nov 20 13:08: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 85E4421F8817 for ; Tue, 20 Nov 2012 13:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Ug2RpKXI-QS8 for ; Tue, 20 Nov 2012 13:08:11 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A621F8815 for ; Tue, 20 Nov 2012 13:08:10 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUKvxOv3uJ7/LIAloycexfA3F58qa2qjZ@postini.com; Tue, 20 Nov 2012 13:08:11 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; Tue, 20 Nov 2012 13:03:57 -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; Tue, 20 Nov 2012 13:03:56 -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; Tue, 20 Nov 2012 13:10:48 -0800 Received: from mail132-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 20 Nov 2012 21:03:55 +0000 Received: from mail132-va3 (localhost [127.0.0.1]) by mail132-va3-R.bigfish.com (Postfix) with ESMTP id BF6052C0255 for ; Tue, 20 Nov 2012 21:03:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zz98dI9371I1432Izz1de0h1202h1d1ah1d2ah1082kzz8275bhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1155h) Received: from mail132-va3 (localhost.localdomain [127.0.0.1]) by mail132-va3 (MessageSwitch) id 135344543310568_13772; Tue, 20 Nov 2012 21:03:53 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.251]) by mail132-va3.bigfish.com (Postfix) with ESMTP id F36851A0093; Tue, 20 Nov 2012 21:03:52 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 20 Nov 2012 21:03:50 +0000 Received: from [172.28.152.9] (66.129.232.2) by pod51010.outlook.com (10.255.159.36) with Microsoft SMTP Server (TLS) id 14.16.233.3; Tue, 20 Nov 2012 21:03:49 +0000 References: MIME-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <36997E71-CD2E-469A-A8F4-9318E044E581@juniper.net> X-Mailer: iPhone Mail (10A525) From: "John G. Scudder" Date: Tue, 20 Nov 2012 16:03:27 -0500 To: "Pradosh Mohapatra (pmohapat)" X-Originating-IP: [66.129.232.2] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$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: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Tue, 20 Nov 2012 21:08:11 -0000 That's basically the point of "deprecated". I see no rush to reuse the value= s given we're nowhere near exhausting the space. --John On Nov 19, 2012, at 1:49 AM, "Pradosh Mohapatra (pmohapat)" wrote: > John, >=20 >=20 >> This document requests IANA to mark the BGP Path Attributes registry >> entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as >> "Deprecated". >=20 >=20 > Given that these have never been used/deployed, won't it be better to > reuse the values? Something like "Unavailable" for six months followed by > "Unassigned"? >=20 > - Pradosh >=20 >=20 From knoll@etit.tu-chemnitz.de Tue Nov 20 22:36: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 E29F721F884B for ; Tue, 20 Nov 2012 22:36:08 -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 Y0+YnKSm2mqW for ; Tue, 20 Nov 2012 22:36:06 -0800 (PST) Received: from cora.hrz.tu-chemnitz.de (cora.hrz.tu-chemnitz.de [134.109.228.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6121F884A for ; Tue, 20 Nov 2012 22:36:06 -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=oHV55DdnYROo+hITlWBAdgqNxzI4BC/I/pDBYzmWsFs=; b=cIJQPfrPWBNXIbmScNkv1qj1T3hkiDIm2LREMT9pgPX01R9iwPNxbvYEPrrh/7cwVtODZ4mNcwm7TEj8Wv15tZw4B5SzbQzvCf4aRINzg9cbdVDAa2n58jO5X8ygJE+42/OViiIUZ/pZoV48FwRq2MZ/hEoRa6M6cfbcNLfCFgw=; Received: from pat.hrz.tu-chemnitz.de ([134.109.133.4] helo=mailbox.hrz.tu-chemnitz.de) by cora.hrz.tu-chemnitz.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tb3uk-0003os-Vu; Wed, 21 Nov 2012 07:36:03 +0100 Received: from a253-2.24online.fi ([84.239.253.2] helo=[192.168.4.51]) by mailbox.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tb3uk-0002do-JG; Wed, 21 Nov 2012 07:36:02 +0100 Message-ID: <50AC7652.4080306@etit.tu-chemnitz.de> Date: Wed, 21 Nov 2012 07:36:02 +0100 From: "Thomas M. Knoll" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <50AB98FC.5080702@gmail.com> In-Reply-To: <50AB98FC.5080702@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-11-21 07:36:02; a8d1ae0f64c39177cefcbe7c4a210cc7 X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1353479763-00000CD1-7123975C/0-0/0-0 X-Scan-SA: cora.hrz.tu-chemnitz.de; 2012-11-21 07:36:03; 76265cbacea0c548aa77f3f191efe102 Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , Sandeep Bajaj , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Wed, 21 Nov 2012 06:36:09 -0000 Hi Brian and all, as a short update to my mentioned BGP QoS signalling drafts, some lines about available resources. 1) http://tools.ietf.org/html/draft-knoll-idr-qos-attribute 2) http://tools.ietf.org/html/draft-knoll-idr-cos-interconnect The respective BGP communities for DSCP/PHBID marking as well as class of service support signalling by ASes have IANA assigned numbers for public use. http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xml A quagga implementation is available and the dissection of the attributes is already part of the wireshark code base. I have also made some simulations about what happens if some ASes support different markings and some possibly none. The outcome for the overall QoS achieved is dependent on the sequence of such marking mismatch. More background information can be found in http://www.qucosa.de/fileadmin/data/qucosa/documents/5887/data/dissertation_knoll.pdf So long Thomas -- +---------------------------------------------------------+ + Dr.-Ing. Thomas M. Knoll + + Chemnitz University + + of Technology Ph. : +49 (0)371 531 33246 + + Reichenhainer Str. 70 Fax : +49 (0)371 531 833246 + + Room 416 + + 09126 Chemnitz + + GERMANY + + WWW : http://www.tu-chemnitz.de/~tkn + + E-Mail : knoll@etit.tu-chemnitz.de + +---------------------------------------------------------+ On 20.11.2012 15:51, Brian E Carpenter wrote: > On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: >> Keeping idr in the loop.. >> >> Brian, >> Your review comments are addressed in the revised draft: >> http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange >> Please review and suggest/comment if any.. > > I think you still need to state somewhere that if a DSCP is signalled, > the two parties must have an out-of-band agreement about what that > DSCP means. There's an active discussion on this topic in the TSVWG > (draft-polk-diffserv-stds-problem-statement, draft-geib-tsvwg-diffserv-intercon, > etc.) > >> 3. What is the relationship of this work to >>>>>>>> draft-knoll-idr-qos-attribute? >>>>>> I'll have to evaluate that. Will look into it. > > Still open, I think. > > Brian >> >> Thanks >> Shitanshu >> >> >> On 7/13/12 6:12 PM, "Shitanshu Shah (svshah)" wrote: >> >>> >>> On 7/13/12 8:52 AM, "Brian E Carpenter" >>> wrote: >>> >>>> Hi, >>>> >>>> On 13/07/2012 07:44, Shitanshu Shah (svshah) wrote: >>>>> Hi Brian, >>>>> >>>>> Sorry for the delay in the response. Keeping co-authors also in the >>>>> loop. >>>>> >>>>> Few clarifications >>>>> - The proposal is not about end to end SLA. It is about exchanging SLA >>>>> between 2 domains. >>>> Does that mean two adjacent domains, or two domains separated by >>>> non-participating domains? >>> It could be any. Adjacent or two domains separated by non-participating >>> ones. >>> >>> >>>> This is critical, because if there are intermediate domains, we must >>>> assume >>>> that they will change the DSCP, because it is a mutable field. >>> >>> It makes sense for SLA exchange between those two domains, that are >>> separated by >>> non-participating domains, to take place only if those two domains fall >>> under >>> same controlled administration. I do not see otherwise why would there be >>> a >>> need for SLA exchange. >>> >>> For example, Site A and Site B are administered by Enterprise XYZ. Even >>> though >>> XYZ's provider for Site A means "EF" for voice and XYZ's provider for Site >>> B >>> means "CS5" for voice. XYZ understands those differences for voice between >>> Site A and Site B. Thus SLA exchange from one site to the other in the >>> context >>> of any "EF" or "CS4" still is okay. A mapping may be defined at the >>> receiver >>> to handle the differences. >>> >>> If Site A and Site B are managed by two different Enterprise XYZ and ABC >>> respectively then I do not see why SLA exchange to take place among them >>> irrespective of what dscp they use for voice traffic. >>> >>> >>>>> - SLA exchange does not necessarily mean automatic provision of >>>>> forwarding >>>>> policy. Draft does not mandate that. though a vendor may use this >>>>> exchange >>>>> to automatically provision forwarding policy. >>>> OK, these points need to be clearly stated in the Introduction, I think. >>>> >>>>> Couple of use-cases are described in "Deployment Considerations" >>>>> section. >>>>> I can clarify further that section with any clarification that comes >>>>> out >>>>> of this discussion. >>>>> >>>>> Taking couple of use-cases to describe further in the context of >>>>> Diffserv >>>>> based SLA. >>>>> 1. >>>>> - SLA exchange between CE and PE where they are connected physically or >>>>> virtually. >>>>> - Customer buys voice (1 mbps), video (5 mbps) and data (2 mbps) >>>>> service >>>>> from the Provider. >>>>> - If provider supports that voice, video and data service with EF, AF4 >>>>> and >>>>> AF2 then instead >>>>> of telling those EF, AF4, AF2 code-points over the phone to the >>>>> customer, they are, along >>>>> with rates, conveyed thru BGP >>>>> >>>>> SLA exchange here does not have any responsibility to tell CE domain >>>>> which end-points should >>>>> be using which dscp code-point or which ip addresses/flows should be >>>>> mapping to which dscp >>>>> Code-point. Thus there is no dscp mapping to or from to be conveyed >>>>> here >>>> Well, you seem to expect the receiver to parse "Traffic Class Description >>>> - Ascii Description of the Traffic Class" somehow and configure diffserv >>>> classification and marking accordingly. So the receiver has to figure out >>>> how the DSCPs that the provider accepts map to its internal DSCPs (if >>>> any). >>> Yes if receiver is using different dscp internally then mapping has to >>> happen >>> between Provider's dscp and internal dscp. And that is what we have >>> highlighted >>> in Section 6.1. Repeating what I mentioned above, aim of this proposal is >>> to >>> define a protocol to exchange SLA but not the provision of the mapping >>> between >>> sender and receiver's code-points. Yeah, if user (user here means vendor >>> or >>> administrator) is not able to come up with his/her own mapping to use with >>> exchanged SLA and if it is left with any ambiguity then we need to look >>> into >>> it but then we first have to know the use-case where such condition may >>> arise. >>> In worst case it will be supplemental proposal which still won't not >>> change >>> protocol of SLA exchange. >>> >>> >>>>> 2. >>>>> - In VPN deployments where dscp code-point is preserved over VPN >>>>> tunnels. >>>>> - Specific Enterprise n/w let's say is spanned over different regions >>>>> eg. >>>>> San Jose, Atlanta, >>>>> Orlando where there is a vpn network between those sites. San Jose >>>>> eg. >>>>> may convey its SLA >>>>> to Atlanta, Olando for EF, AF4 and AF2 traffic. >>>>> >>>>> Here again there is no responsibility to tell which end-points should >>>>> be >>>>> using which dscp >>>>> Code-points. All San Jose is telling Orlando is that if it is sending >>>>> any EF traffic towards >>>>> San Jose then it does not have to send more than 1 mbps >>>> Yes, once they agree on what "EF" is and which DSCP value it uses. >>>> Again it seems to depend on the ASCII description. >>>> >>>>> I've looked at RFC3140. PHB id is something may make sense to be added >>>>> as >>>>> one of the SLA exchange >>>>> Parameter. Where can I find list of PHB ids? >>>> There's a registry: >>>> http://www.iana.org/assignments/phbid-codes/phbid-codes.xml >>>> However, it's empty - in other words, nobody has found it necessary to >>>> register >>>> a non-default value. That means that today, only the standardised DSCP >>>> values >>>> at http://www.iana.org/assignments/dscp-registry/dscp-registry.xml >>>> have PHB IDs. >>>> >>>> However, if an operator wanted its own PHB ID for use in its own SLAs, >>>> it should be easy to register one. (I see that I'm a designated expert >>>> for this.) >>>> >>>> This was set up to provide flexibility - in practice people seem to >>>> prefer standard DSCPs and PHBs, but at the time people insisted on >>>> flexibility. >>> >>> Sure, understood. And in those deployments that use this flexible PHB ids, >>> SLA exchange needs to be in the context of such PHB ids. >>> >>> Regards, >>> Shitanshu >>> >>> >>>> Regards >>>> >>>> Brian >>>> >>>>> >>>>> Thanks >>>>> Shitanshu >>>>> >>>>> >>>>> On 6/9/12 1:32 AM, "Brian E Carpenter" >>>>> wrote: >>>>> >>>>>> Hi Shitanshu, >>>>>> >>>>>> I think what is missing in the draft is a clear explanation of the >>>>>> possible >>>>>> deployment models and how they relate to the diffserv architecture, >>>>>> which >>>>>> is very explicit in defining the concept of diffserv domains. >>>>>> Basically >>>>>> that model requires DSCP mapping at every domain boundary (even if it >>>>>> is >>>>>> a trivial 1:1 mapping). I think you have to be very explicit that if >>>>>> the BGP attribute is transmitted across a diffserv domain boundary, >>>>>> the >>>>>> conveyed DSCPs MUST be mapped at that boundary (with a note that >>>>>> domains >>>>>> could agree on a 1:1 mapping if they were within a single SLA >>>>>> community). >>>>>> Or you use the PHBID instead, in which case it is by definition mapped >>>>>> locally inside each domain. >>>>>> >>>>>> By the way, as well as RFC 2475, the architecture is discussed in >>>>>> RFC 3086 and in B.E. Carpenter and K. Nichols, Differentiated Services >>>>>> in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494. >>>>>> >>>>>> Regards >>>>>> Brian Carpenter >>>>>> >>>>>> On 2012-06-06 17:57, svshah wrote: >>>>>>> Thanks a bunch Brian for your comments. See further inline for >>>>>>> response >>>>>>> >>>>>>> On 6/6/12 6:00 AM, "Brian E Carpenter" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have some comments on your draft: >>>>>>>> >>>>>>>>> 0x02 = IP_DSCP, (length = 08-bits, value = 0..63) >>>>>>>> 1. The DSCP is a 6 bit field (the other two bits are ECN, and you >>>>>>>> can't touch them). >>>>>>> If you are referring to change the length field to 6-bits, I agree. >>>>>>> It >>>>>>> does >>>>>>> not have to be 8-bits. >>>>>>> >>>>>>>> 2. More seriously, the DSCP *by definition* is domain-specific. How >>>>>>>> can it >>>>>>>> be valid or meaningful in an end-to-end SLA? >>>>>>> This question requires multiple answers, hopefully I can itemize them >>>>>>> appropriately >>>>>>> >>>>>>> - The proposal in the draft is not specifically only for end-to-end >>>>>>> SLA. The >>>>>>> intentional use-case of the draft is with next hop SLA like PE to CE >>>>>>> SLA, >>>>>>> where PE may have SLA defined eg. for Diffserv classes which CE >>>>>>> traffic >>>>>>> will >>>>>>> be subject to. Based on your comment I assume, you are not >>>>>>> questioning >>>>>>> this >>>>>>> specific use case but are referring to SLA exchange across multiple >>>>>>> hops >>>>>>> >>>>>>> - Beyond just next hop, one can envision a use-case where ASs, >>>>>>> multiple >>>>>>> sites spanned across multiple regions, managed by one corporate or >>>>>>> provider >>>>>>> may want to exchange SLAs site to site to manage traffic multi-site >>>>>>> >>>>>>> - Also to note that SLA exchange format is defined to send SLA to a >>>>>>> specific >>>>>>> one or specific list of recipients. If this SLA exchange is across >>>>>>> multiple >>>>>>> hops then intermediate speakers (ones that are not in the recipient >>>>>>> list) >>>>>>> are not subject to SLA >>>>>>> >>>>>>> - Receiver, for which SLA is meant to, does not have to listen to >>>>>>> those >>>>>>> SLA >>>>>>> messages. They can ignore them. The point being that in a well >>>>>>> designed >>>>>>> network, SLAs will be accepted only if by design sender and receivers >>>>>>> are >>>>>>> expected to do so >>>>>>> >>>>>>> >>>>>>> Please fill me in if you are referring to any specific point beyond >>>>>>> ones >>>>>>> described above >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I realise that you say >>>>>>>> >>>>>>>>> Typical use-case aimed with this proposal is for Provider to >>>>>>>>> advertise contracted SLA to Customer Edge. >>>>>>>> but that is unenforceable; BGP speakers can't be expected to know >>>>>>>> about QoS domain boundaries, so we must assume that this attribute >>>>>>>> might cross such boundaries. In fact, you admit this in section >>>>>>>> 6.1. The traffic class mapping described there MUST be applied >>>>>>>> at every diffserv domain boundary that this SLA attribute crosses, >>>>>>>> even to map DSCP1 to DSCP2. That seems like a bit of a deployment >>>>>>>> and operational nightmare. >>>>>>> While programming QoS automatically with this SLA exchange can be >>>>>>> very >>>>>>> helpful, there are other benefits that this method provides that >>>>>>> simplifies >>>>>>> administrators life specifically ones who are not very fluent on some >>>>>>> of the >>>>>>> QoS specifics, >>>>>>> >>>>>>> Taking an example Where SLA with PE is based on Diffserv classes with >>>>>>> specific rates for each diffserv class >>>>>>> 1) When admin has to provision QoS policy on CE, they first need to >>>>>>> know >>>>>>> what diffserv classes with what associated rates >>>>>>> >>>>>>> 2) Once that is known, translate them to Vendor specific provisioning >>>>>>> (eg. >>>>>>> What classification rules/configurations in Vendor's provisioning >>>>>>> language >>>>>>> and same for associated actions) >>>>>>> >>>>>>> 3) As required, define traffic class mapping as you pointed out >>>>>>> >>>>>>> 4) Once came up with appropriate mapping and policy, associate them >>>>>>> with the >>>>>>> forwarding >>>>>>> >>>>>>> >>>>>>> While, in some cases if not all, there may be challenges for step >>>>>>> (3), >>>>>>> customers get it so much simplified even with step (1) and (2) >>>>>>> >>>>>>> >>>>>>>> This is exactly what PHBIDs were intended for. Please see RFC3140. >>>>>>>> You should use those instead of DSCP values. Or better still, >>>>>>>> generalise the PHBID definition to cover MPLS and 802.1Q as well. >>>>>>> I'll certainly look into it. I'll definitely be happy if something >>>>>>> can >>>>>>> be >>>>>>> leveraged from RFC3140 or if can be enhanced in the context. >>>>>>> >>>>>>>> 3. What is the relationship of this work to >>>>>>>> draft-knoll-idr-qos-attribute? >>>>>>> I'll have to evaluate that. Will look into it. >>>>>>> >>>>>>>> 4. Finally, please run the draft through >>>>>>>> http://www.ietf.org/tools/idnits/. >>>>>>>> There are a lot of warnings. >>>>>>> Sure, thx. >>>>>>> >>>>>>> Looking forward for your response/comments/suggestions >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Shitanshu >>>>>>> >>>>>>> >>>>>>>> Regards >>>>>>>> Brian Carpenter >>>>> >> >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From mohamed.boucadair@orange.com Tue Nov 20 23: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 2672621E802E for ; Tue, 20 Nov 2012 23:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.246, 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 9SImjrZwKP0J for ; Tue, 20 Nov 2012 23:17:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 39CF121F85C2 for ; Tue, 20 Nov 2012 23:17:21 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 200B52DC413; Wed, 21 Nov 2012 08:17:20 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 00B2535C045; Wed, 21 Nov 2012 08:17:20 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 21 Nov 2012 08:17:19 +0100 From: To: Brian E Carpenter , "Shitanshu Shah (svshah)" Date: Wed, 21 Nov 2012 08:17:18 +0100 Thread-Topic: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-00.txt Thread-Index: Ac3HLpLBxvf21AG1SA+udYt4o6RhjwAiUhEw Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751EE14@PUEXCB1B.nanterre.francetelecom.fr> References: <50AB98FC.5080702@gmail.com> In-Reply-To: <50AB98FC.5080702@gmail.com> 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 Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , Sandeep Bajaj , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Wed, 21 Nov 2012 07:17:22 -0000 Dear Brian, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la=20 >part de Brian E Carpenter >Envoy=E9 : mardi 20 novembre 2012 15:52 >=C0 : Shitanshu Shah (svshah) >Cc : draft-svshah-interdomain-sla-exchange@tools.ietf.org;=20 >Keyur Patel (keyupate); idr@ietf.org; Sandeep Bajaj >Objet : Re: [Idr] I-D Action:=20 >draft-svshah-interdomain-sla-exchange-00.txt > >On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: >> Keeping idr in the loop.. >>=20 >> Brian, >> Your review comments are addressed in the revised draft: >> http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange >> Please review and suggest/comment if any.. > >I think you still need to state somewhere that if a DSCP is signalled, >the two parties must have an out-of-band agreement about what that >DSCP means.=20 Med: Isn't this already covered in the introduction text:=20 =3D=3D=3D Typically there is a contractual Service Level Agreement (SLA) negotiated between Customer and Provider or between one Provider to another Provider [CPP]. This contractual agreement defines the nature of the various traffic classes (i.e. traffic match conditions) and services needed for each traffic class. The contract may exist at different levels of traffic granularity. The contract could be full line-rate or sub rate for aggregate traffic. Or it could be even finer granular traffic distinction with services defined for standard code-points or for specific set of prefix or for set of well-known application types. [CPP] http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-= profile-02 =20 =3D=3D=3D=3D From brian.e.carpenter@gmail.com Wed Nov 21 00:13: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 47BCD21F8768 for ; Wed, 21 Nov 2012 00:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 6myanMj8KDn1 for ; Wed, 21 Nov 2012 00:13:13 -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 5F91021F873A for ; Wed, 21 Nov 2012 00:13:13 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so897162wey.31 for ; Wed, 21 Nov 2012 00:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FN5zKXYPwqaGjToAs5iMP0LAtVPQWCxrD32x2F9aiyA=; b=0EFbcwOeK24715q/81hlc1nihiF351Wodnw2E4Bd9wOQ1IGQBm6Fnd+GZDb9R7A88A fWldptmAs78bzw3y+rzKkWU4Ltr9VLtbzCCtSgwPg+NaIxgIZd+AVeQ5yjLikWrVMFGg ss/61QhUb+/bIDM0uzWimPzlJIl0m/4U/QjT0K5QZjrYuTrx1RUUVxEx7hj1Ah9Z3zoN V36sQGJBq1vLPw5uNKOJXAu9n9yip9qMLIYVxvPvRcYlPgd2KT2CngUBdpCy8mZErlKY K6GIkn2r01uF2h8K2CidPL1TqUpo1uH6em4KIBfdheOPlY/CLtclGzRhu2ZKHpi8bmvl yrFg== Received: by 10.180.19.73 with SMTP id c9mr18291884wie.8.1353485592440; Wed, 21 Nov 2012 00:13:12 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-77.as13285.net. [2.101.188.77]) by mx.google.com with ESMTPS id i6sm20921980wix.5.2012.11.21.00.13.10 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 00:13:11 -0800 (PST) Message-ID: <50AC8D1A.3080604@gmail.com> Date: Wed, 21 Nov 2012 08:13:14 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <50AB98FC.5080702@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751EE14@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9751EE14@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , Sandeep Bajaj , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Wed, 21 Nov 2012 08:13:14 -0000 Hi Med, On 21/11/2012 07:17, mohamed.boucadair@orange.com wrote: > Dear Brian, >=20 > Please see inline.=20 >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la=20 >> part de Brian E Carpenter >> Envoy=C3=A9 : mardi 20 novembre 2012 15:52 >> =C3=80 : Shitanshu Shah (svshah) >> Cc : draft-svshah-interdomain-sla-exchange@tools.ietf.org;=20 >> Keyur Patel (keyupate); idr@ietf.org; Sandeep Bajaj >> Objet : Re: [Idr] I-D Action:=20 >> draft-svshah-interdomain-sla-exchange-00.txt >> >> On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: >>> Keeping idr in the loop.. >>> >>> Brian, >>> Your review comments are addressed in the revised draft: >>> http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange= >>> Please review and suggest/comment if any.. >> I think you still need to state somewhere that if a DSCP is signalled,= >> the two parties must have an out-of-band agreement about what that >> DSCP means.=20 >=20 > Med: Isn't this already covered in the introduction text:=20 I don't believe that is specific enough. The correspondence between a DSCP and a PHB is locally defined and the exact parameters of a PHB are locally defined - that is the nature of diffserv. While there is a move in TSVWG to define standard inter-operator semantics for diffserv, at the moment it is quite insufficient to agree on the "nature" - you need to agree on the capacity limit for EF, for example. Without numeric parameters, the SLA is incomplete. Brian >=20 > =3D=3D=3D > Typically there is a contractual Service Level Agreement (SLA) > negotiated between Customer and Provider or between one Provider to > another Provider [CPP]. This contractual agreement defines the > nature of the various traffic classes (i.e. traffic match conditions= ) > and services needed for each traffic class. The contract may exist > at different levels of traffic granularity. The contract could be > full line-rate or sub rate for aggregate traffic. Or it could be > even finer granular traffic distinction with services defined for > standard code-points or for specific set of prefix or for set of > well-known application types. >=20 > [CPP] http://tools.ietf.org/html/draft-boucadair-connectivity-provision= ing-profile-02 > =20 > =3D=3D=3D=3D >=20 From mohamed.boucadair@orange.com Wed Nov 21 00:27: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 E0B1F21F8443 for ; Wed, 21 Nov 2012 00:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.221, 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 rc-ZXQ2a52qM for ; Wed, 21 Nov 2012 00:27:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10821F842D for ; Wed, 21 Nov 2012 00:27:27 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 26DCA22C6BA; Wed, 21 Nov 2012 09:27:26 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 06FCE27C053; Wed, 21 Nov 2012 09:27:26 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 21 Nov 2012 09:27:25 +0100 From: To: Brian E Carpenter Date: Wed, 21 Nov 2012 09:27:24 +0100 Thread-Topic: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-00.txt Thread-Index: Ac3HwA3HS/nmzF+eR1ed8V9cmS2cIgAAZTmg Message-ID: <94C682931C08B048B7A8645303FDC9F36E9751EE7B@PUEXCB1B.nanterre.francetelecom.fr> References: <50AB98FC.5080702@gmail.com> <94C682931C08B048B7A8645303FDC9F36E9751EE14@PUEXCB1B.nanterre.francetelecom.fr> <50AC8D1A.3080604@gmail.com> In-Reply-To: <50AC8D1A.3080604@gmail.com> 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.11.21.74515 Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , Sandeep Bajaj , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Wed, 21 Nov 2012 08:27:28 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 >Envoy=E9 : mercredi 21 novembre 2012 09:13 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Shitanshu Shah (svshah);=20 >draft-svshah-interdomain-sla-exchange@tools.ietf.org; Keyur=20 >Patel (keyupate); idr@ietf.org; Sandeep Bajaj >Objet : Re: [Idr] I-D Action:=20 >draft-svshah-interdomain-sla-exchange-00.txt > >Hi Med, > >On 21/11/2012 07:17, mohamed.boucadair@orange.com wrote: >> Dear Brian, >>=20 >> Please see inline.=20 >>=20 >> Cheers, >> Med=20 >>=20 >>> -----Message d'origine----- >>> De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la=20 >>> part de Brian E Carpenter >>> Envoy=E9 : mardi 20 novembre 2012 15:52 >>> =C0 : Shitanshu Shah (svshah) >>> Cc : draft-svshah-interdomain-sla-exchange@tools.ietf.org;=20 >>> Keyur Patel (keyupate); idr@ietf.org; Sandeep Bajaj >>> Objet : Re: [Idr] I-D Action:=20 >>> draft-svshah-interdomain-sla-exchange-00.txt >>> >>> On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: >>>> Keeping idr in the loop.. >>>> >>>> Brian, >>>> Your review comments are addressed in the revised draft: >>>>=20 >http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange >>>> Please review and suggest/comment if any.. >>> I think you still need to state somewhere that if a DSCP is=20 >signalled, >>> the two parties must have an out-of-band agreement about what that >>> DSCP means.=20 >>=20 >> Med: Isn't this already covered in the introduction text:=20 > >I don't believe that is specific enough. The correspondence between >a DSCP and a PHB is locally defined and the exact parameters of >a PHB are locally defined - that is the nature of diffserv. Med: Fully agree.=20 >While there is a move in TSVWG to define standard inter-operator >semantics for diffserv, at the moment it is quite insufficient >to agree on the "nature" - you need to agree on the capacity >limit for EF, for example. Without numeric parameters, the SLA >is incomplete. Med: Agreed. This is the purpose of http://tools.ietf.org/html/draft-boucad= air-connectivity-provisioning-profile-02 which is cited in draft-svshah-int= erdomain-sla-exchange (See Section 3 of the CPP draft).=20 > > Brian > >>=20 >> =3D=3D=3D >> Typically there is a contractual Service Level Agreement (SLA) >> negotiated between Customer and Provider or between one=20 >Provider to >> another Provider [CPP]. This contractual agreement defines the >> nature of the various traffic classes (i.e. traffic match=20 >conditions) >> and services needed for each traffic class. The contract=20 >may exist >> at different levels of traffic granularity. The contract could be >> full line-rate or sub rate for aggregate traffic. Or it could be >> even finer granular traffic distinction with services defined for >> standard code-points or for specific set of prefix or for set of >> well-known application types. >>=20 >> [CPP]=20 >http://tools.ietf.org/html/draft-boucadair-connectivity-provisi >oning-profile-02 >> =20 >> =3D=3D=3D=3D >>=20 > >= From internet-drafts@ietf.org Wed Nov 21 11:13: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 B9BC921F87E7; Wed, 21 Nov 2012 11:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 AAWHiFk8TUQf; Wed, 21 Nov 2012 11:13:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BF21F8809; Wed, 21 Nov 2012 11:13:21 -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: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2012 11:13:21 -0800 Cc: idr@ietf.org Subject: [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: Wed, 21 Nov 2012 19:13:21 -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 : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-03.txt Pages : 12 Date : 2012-11-21 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From enkechen@cisco.com Wed Nov 21 11:20: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 74E2B21F87BC for ; Wed, 21 Nov 2012 11:20:42 -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 9bWu+WRC2YR1 for ; Wed, 21 Nov 2012 11:20:41 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0D921F87AC for ; Wed, 21 Nov 2012 11:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2859; q=dns/txt; s=iport; t=1353525641; x=1354735241; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=52aBGN5C4epqTw6kuKPkHxDmtqaX/uoGRSik5BslHj8=; b=GZvt7i9O/rvk2uddZ08QFI7+d0nw07BnrLwD5xCBimk+doQmYzY+l4AG rWP1iBjaGTsVkzRHA4tVBomB7GzjJuMcwyWOhQGhSVi2llr41LWDE+R5p GULb0rzGislnQi92oO15lXAgINAchS8Yz9OTaaOMkGVna5/wc0gnygDFL E=; X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="9818765" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 21 Nov 2012 19:20:40 +0000 Received: from [10.21.75.82] ([10.21.75.82]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qALJKc9x024983; Wed, 21 Nov 2012 19:20:39 GMT Message-ID: <50AD2986.90705@cisco.com> Date: Wed, 21 Nov 2012 11:20:38 -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: idr@ietf.org References: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> In-Reply-To: <20121121191321.6164.6887.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 21 Nov 2012 19:20:42 -0000 Hi, folks: The revised version includes the following changes: o specify local repair for only the "Optional bit" and "Transitive" bit in the Attribute Flags o use treat-as-withdraw for missing mandatory attributes o reset session for duplicate MP_REACH or MP_UNRAECH o specify precedence for error handling actions: session reset, treat-as-withdraw, attribute discard o cover all attributes specified in the base spec, community, ext-community (including the ipv6 address based ext-community) o reference RFC4760 (instead of the rfc4760bis) to avoid circular dependencies Please note that: o The MP_REACH and MP_UNREACH will be covered in a re-spin of the existing MP extension draft. o The RR related attributes will be covered by a RR re-spin. Regards, -- Enke On 11/21/12 11:13 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : Revised Error Handling for BGP UPDATE Messages > Author(s) : John G. Scudder > Enke Chen > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-03.txt > Pages : 12 > Date : 2012-11-21 > > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From svshah@cisco.com Wed Nov 21 16:40: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 1589321E803F for ; Wed, 21 Nov 2012 16:40:36 -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 uIccH040tb7A for ; Wed, 21 Nov 2012 16:40:35 -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 2B4ED21E8034 for ; Wed, 21 Nov 2012 16:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3984; q=dns/txt; s=iport; t=1353544835; x=1354754435; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Iuj3mNYzqKYAYZo+udIYxqTrZKeH8w19gnpekfQ0ses=; b=U+twmrZdyHVGzBSGPb6rvSVbmFwaQ3huhJRjBIOp/iY4gZ/BSggCwXjC Z+IIMwhbgGL2XRaUHE68AYbc9ROWZL4xSj82ZBp2klYTdoxs3Hu6xqTw0 8aY8NVKqpsW6Sbqe/pA9L+2rrq9bbD2Cl7a8HA0dmJPZHsryPPlVtBJKh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANxzrVCtJV2c/2dsb2JhbABEwhgWc4IeAQEBBHkSAQgYCh0oERQRAgQBDQUIh3MDDwu1Ug2JVItLaRaDbGEDiCeMAoJxihaFD4JvgVwfHg X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145059934" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 22 Nov 2012 00:40:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAM0eYkq024337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 00:40:34 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.96]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 18:40:34 -0600 From: "Shitanshu Shah (svshah)" To: Brian E Carpenter , "mohamed.boucadair@orange.com" Thread-Topic: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-00.txt Thread-Index: Ac1GGmsByDT6HAuyR0KHGxr/NSDQ+gal8k0AACHMqIAABOYVgBc3MgiAAk3D6AAAImw/AAAB9BUAABG3ngA= Date: Thu, 22 Nov 2012 00:40:33 +0000 Message-ID: In-Reply-To: <50AC8D1A.3080604@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.71.172] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "Keyur Patel \(keyupate\)" , Sandeep Bajaj , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-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: Thu, 22 Nov 2012 00:40:36 -0000 Hi Brian, The intention of the proposal is certainly to exchange full SLA parameters, including if DSCP is signaled, what that DSCP means. That is eg. capacity limit for EF and any other service (eg. relative priority, worst case latency) that may associated with it. It is captured in the full SLA details defined in the draft. If you mean that to be captured in the text, it certainly can be done. Probably we can elaborate somewhere in the text that Med highlighted. Regarding, draft-knoll-idr-qos-attribute, after reading it through more carefully, the purpose and usage of it is fundamentally quite different from the purpose/usage of proposal in draft-svshah-interdomain-sla-exchange What draft-knoll-idr-qos-attribute seems to propose is to signal eg. DSCP (or any other relevant QoS code-point) along with IP prefix. I suspect that would mean if one AS to advertise DSCP for an IP prefix, receiver AS to trust advertised code-point for that IP prefix and install that for forwarding purpose. In another words, contract is being established through signaling (unless assumption is to have off-band contract between AS to establish for what list of IP prefix, advertised code-point to be trusted?). Thomas please feel free to correct me if I've not got it right. Proposal/use-case in draft-svshah-interdomain-sla-exchange, is to exchange after contract SLA between 2 AS. Regards, Shitanshu On 11/21/12 12:13 AM, "Brian E Carpenter" wrote: >Hi Med, > >On 21/11/2012 07:17, mohamed.boucadair@orange.com wrote: >> Dear Brian, >>=20 >> Please see inline. >>=20 >> Cheers, >> Med=20 >>=20 >>> -----Message d'origine----- >>> De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la >>> part de Brian E Carpenter >>> Envoy=E9 : mardi 20 novembre 2012 15:52 >>> =C0 : Shitanshu Shah (svshah) >>> Cc : draft-svshah-interdomain-sla-exchange@tools.ietf.org; >>> Keyur Patel (keyupate); idr@ietf.org; Sandeep Bajaj >>> Objet : Re: [Idr] I-D Action: >>> draft-svshah-interdomain-sla-exchange-00.txt >>> >>> On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: >>>> Keeping idr in the loop.. >>>> >>>> Brian, >>>> Your review comments are addressed in the revised draft: >>>> http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange >>>> Please review and suggest/comment if any.. >>> I think you still need to state somewhere that if a DSCP is signalled, >>> the two parties must have an out-of-band agreement about what that >>> DSCP means.=20 >>=20 >> Med: Isn't this already covered in the introduction text: > >I don't believe that is specific enough. The correspondence between >a DSCP and a PHB is locally defined and the exact parameters of >a PHB are locally defined - that is the nature of diffserv. >While there is a move in TSVWG to define standard inter-operator >semantics for diffserv, at the moment it is quite insufficient >to agree on the "nature" - you need to agree on the capacity >limit for EF, for example. Without numeric parameters, the SLA >is incomplete. > > Brian > >>=20 >> =3D=3D=3D >> Typically there is a contractual Service Level Agreement (SLA) >> negotiated between Customer and Provider or between one Provider to >> another Provider [CPP]. This contractual agreement defines the >> nature of the various traffic classes (i.e. traffic match conditions) >> and services needed for each traffic class. The contract may exist >> at different levels of traffic granularity. The contract could be >> full line-rate or sub rate for aggregate traffic. Or it could be >> even finer granular traffic distinction with services defined for >> standard code-points or for specific set of prefix or for set of >> well-known application types. >>=20 >> [CPP]=20 >>http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-prof >>ile-02 >> =20 >> =3D=3D=3D=3D >>=20 > From knoll@etit.tu-chemnitz.de Thu Nov 22 01: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 4360521F885A for ; Thu, 22 Nov 2012 01:46:37 -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 8y-nuSVlo8T0 for ; Thu, 22 Nov 2012 01:46:36 -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 EC47921F8839 for ; Thu, 22 Nov 2012 01:46:35 -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=1LgqDCEoqaDZqggNQGlFn/GQEte3xv0vhrnoD51lSQo=; b=vOv0cQbYazu5Iof1RsXfLJwTQUuOJ+NEhBdqsY9rgmKU1Oz0Zzm1D6Mz9DxluVgskNheN8kTax4uKcfuyvvJyVr7cU4Q/FAUqIx3aZ/ZXOPOOAV6+e53Udssm+updH/OtEVnBX47vKfnJiS1BnvQSlY4CDqYZ9Nq9+qrOJCJqjw=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] 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 1TbTMc-0001xg-4r; Thu, 22 Nov 2012 10:46:30 +0100 Received: from [194.251.119.201] (helo=[10.255.243.104]) by mailbox.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TbTMb-0006ED-UE; Thu, 22 Nov 2012 10:46:30 +0100 Message-ID: <50ADF477.3070302@etit.tu-chemnitz.de> Date: Thu, 22 Nov 2012 10:46:31 +0100 From: "Thomas M. Knoll" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Shitanshu Shah (svshah)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: knoll@etit.tu-chemnitz.de X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2012-11-22 10:46:30; 9889f6ef02b017027416997f327620ac X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1353577590-00005597-8F0F6722/0-0/0-0 X-Scan-SA: nick.hrz.tu-chemnitz.de; 2012-11-22 10:46:30; d6e10076acbb482ab6c320b0f5d58cff Cc: "draft-svshah-interdomain-sla-exchange@tools.ietf.org" , "idr@ietf.org" , Sandeep Bajaj , "Keyur Patel \(keyupate\)" , Brian E Carpenter Subject: Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-00.txt - relation to draft-knoll-idr-qos-attribute and draft-knoll-idr-cos-interconnect X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 22 Nov 2012 09:46:37 -0000 Hi Shitanshu, thank you for your comment and I will just address your section in the email regarding my QoS signalling drafts. 1) http://tools.ietf.org/html/draft-knoll-idr-qos-attribute 2) http://tools.ietf.org/html/draft-knoll-idr-cos-interconnect The reasoning behind those drafts in a nutshell are as follows: a) having even just 2 QoS classes distinguished in the global Internet traffic forwarding will make a huge difference in the experienced quality for delay sensitive services b) signalling too detailed QoS parameters might quickly get too complex, which will hinder its deployment c) prioritizing packets will often be sufficient to make the difference and strict reservations, delay budgets etc. create unnecessary complexity for the involved parties, even more so, when measurements, agreement validations and resulting violation charges get into place. Hence, priority marking only is a good compromise between complexity and resulting service quality improvement. --> Keeping (QoS signalling) things simple was the design guideline d) priority marking should be aligned across layers. Thus, IP DSCP, Etherner prio and MPLS prio are signalled together for a homogeneous setup of frame/packet prioritisation across the layers. Having said this, you are right, Shitanshu, that my drafts only address proper marking signalling only. The prefix originating AS signals its supported classes (DSCPs and possibly L2 prios) alongside with the BGP update. Neighbouring ASes will relay the prefixes and update the associated QoS class marking information as they forward the reachability information to their neighbours. Finally, the operators AS might now receive several AS paths towards the originating AS and can see, which transit path will support which set of QoS classes along the way. This information can now be used to select the best path (QoS wise) towards the prefix originator. At the same time, this could also steer the wholesale decision for transit path contracts in the long run. As a last remark, each forwarding AS can signal in the process of updating the QoS marking information in the BGP update, whether it will ignore a certain marking (or even all) or do a remapping into a different set of classes as traffic will traverse its AS. I am not sure, whether my drafts are of relevance for your work, Shitanshu. However, if you regard it as related work, feel free to reference it in your drafts. Best regards Thomas On 22.11.2012 01:40, Shitanshu Shah (svshah) wrote: > > Hi Brian, > > The intention of the proposal is certainly to exchange full SLA > parameters, including if DSCP is signaled, what that DSCP means. That is > eg. capacity limit for EF and any other service (eg. relative priority, > worst case latency) that may associated with it. It is captured in the > full SLA details defined in the draft. If you mean that to be captured in > the text, it certainly can be done. Probably we can elaborate somewhere in > the text that Med highlighted. > > > Regarding, draft-knoll-idr-qos-attribute, after reading it through more > carefully, the purpose and usage of it is fundamentally quite different > from the purpose/usage of proposal in draft-svshah-interdomain-sla-exchange > > What draft-knoll-idr-qos-attribute seems to propose is to signal eg. DSCP > (or any other relevant QoS code-point) along with IP prefix. I suspect > that would mean if one AS to advertise DSCP for an IP prefix, receiver AS > to trust advertised code-point for that IP prefix and install that for > forwarding purpose. In another words, contract is being established > through signaling (unless assumption is to have off-band contract between > AS to establish for what list of IP prefix, advertised code-point to be > trusted?). Thomas please feel free to correct me if I've not got it right. > Proposal/use-case in draft-svshah-interdomain-sla-exchange, is to exchange > after contract SLA between 2 AS. > > > Regards, > Shitanshu > > On 11/21/12 12:13 AM, "Brian E Carpenter" > wrote: > >> Hi Med, >> >> On 21/11/2012 07:17, mohamed.boucadair@orange.com wrote: >>> Dear Brian, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la >>>> part de Brian E Carpenter >>>> Envoyé : mardi 20 novembre 2012 15:52 >>>> À : Shitanshu Shah (svshah) >>>> Cc : draft-svshah-interdomain-sla-exchange@tools.ietf.org; >>>> Keyur Patel (keyupate); idr@ietf.org; Sandeep Bajaj >>>> Objet : Re: [Idr] I-D Action: >>>> draft-svshah-interdomain-sla-exchange-00.txt >>>> >>>> On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote: >>>>> Keeping idr in the loop.. >>>>> >>>>> Brian, >>>>> Your review comments are addressed in the revised draft: >>>>> http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange >>>>> Please review and suggest/comment if any.. >>>> I think you still need to state somewhere that if a DSCP is signalled, >>>> the two parties must have an out-of-band agreement about what that >>>> DSCP means. >>> >>> Med: Isn't this already covered in the introduction text: >> >> I don't believe that is specific enough. The correspondence between >> a DSCP and a PHB is locally defined and the exact parameters of >> a PHB are locally defined - that is the nature of diffserv. >> While there is a move in TSVWG to define standard inter-operator >> semantics for diffserv, at the moment it is quite insufficient >> to agree on the "nature" - you need to agree on the capacity >> limit for EF, for example. Without numeric parameters, the SLA >> is incomplete. >> >> Brian >> >>> >>> === >>> Typically there is a contractual Service Level Agreement (SLA) >>> negotiated between Customer and Provider or between one Provider to >>> another Provider [CPP]. This contractual agreement defines the >>> nature of the various traffic classes (i.e. traffic match conditions) >>> and services needed for each traffic class. The contract may exist >>> at different levels of traffic granularity. The contract could be >>> full line-rate or sub rate for aggregate traffic. Or it could be >>> even finer granular traffic distinction with services defined for >>> standard code-points or for specific set of prefix or for set of >>> well-known application types. >>> >>> [CPP] >>> http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-prof >>> ile-02 >>> >>> ==== >>> >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jrmitche@puck.nether.net Sat Nov 24 16:28: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 3C62D21F8550 for ; Sat, 24 Nov 2012 16:28:12 -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 i3+njSmT1zML for ; Sat, 24 Nov 2012 16:28:11 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 783C221F854E for ; Sat, 24 Nov 2012 16:28:11 -0800 (PST) Received: from [192.168.1.2] (pool-173-72-197-133.clppva.fios.verizon.net [173.72.197.133]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qAP0S8m9032162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Nov 2012 19:28:10 -0500 References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4752DF98-DB6E-41DD-9B39-01A5CE209EB9@puck.nether.net> X-Mailer: iPhone Mail (10A523) From: Jon Mitchell Date: Sat, 24 Nov 2012 19:28:06 -0500 To: "John G. Scudder" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Sat, 24 Nov 2012 19:28:10 -0500 (EST) Cc: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Sun, 25 Nov 2012 00:28:12 -0000 Support -Jon On Nov 14, 2012, at 1:16 PM, "John G. Scudder" wrote: > Hi, >=20 > Nobody responded to my note of November 8 ("Deprecating path attributes DP= A, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted the b= elow tiny Internet Draft. The substantive text of the draft is: >=20 > 1. Introduction >=20 > As of this writing the BGP Path Attributes registry maintained by > IANA contains entries for DPA, ADVERTISER, and RCID_PATH / > CLUSTER_ID. The first of these is associated with > [draft-ietf-idr-bgp-dpa-05], an Internet Draft that was abandoned in > 1996. The latter are associated with [RFC1863], an RFC that was > reclassified as Historic in 2005. Neither of these specifications is > in use now, nor ever was. >=20 >=20 > 2. IANA Considerations >=20 > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". >=20 > The rest is boilerplate, references, etc.=20 >=20 > I would like to ask the WG to adopt the draft. Since the draft is so trivi= al, I would like to also request a WGLC, to run in parallel.=20 >=20 > Since many WG members will be on holiday for part of next week, let's have= the call for adoption + WGLC end on December 3. Please send any comments be= fore December 3. >=20 > Also, regarding the out-of-the-ordinary expedited WGLC: If there's any dis= agreement whatsoever (with the content or wording of the draft, its adoption= , or indeed the expedited procedure itself), let's have only the call for ad= option end on December 3, and then we can do a normal WGLC when appropriate.= >=20 > Thanks, >=20 > --John (wearing two hats) >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-scudder-deprecate-dpa-etal-00= .txt >> Date: November 14, 2012 1:06:11 PM EST >> To: jgs@bgp.nu >> Cc: jgs@juniper.net >>=20 >>=20 >> A new version of I-D, draft-scudder-deprecate-dpa-etal-00.txt >> has been successfully submitted by John Scudder and posted to the >> IETF repository. >>=20 >> Filename: draft-scudder-deprecate-dpa-etal >> Revision: 00 >> Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and RCI= D_PATH / CLUSTER_ID >> Creation date: 2012-11-14 >> WG ID: Individual Submission >> Number of pages: 2 >> URL: http://www.ietf.org/internet-drafts/draft-scudder-deprec= ate-dpa-etal-00.txt >> Status: http://datatracker.ietf.org/doc/draft-scudder-deprecate-= dpa-etal >> Htmlized: http://tools.ietf.org/html/draft-scudder-deprecate-dpa-e= tal-00 >>=20 >>=20 >> Abstract: >> This document requests IANA to deprecate several BGP path attributes, >> associated with an abandoned Internet Draft and a Historic RFC, >> respectively. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Mon Nov 26 08:49: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 C481E21F867F; Mon, 26 Nov 2012 08:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 oC1qmWIxUFI8; Mon, 26 Nov 2012 08:49:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEA121F85D0; Mon, 26 Nov 2012 08:49:26 -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: <20121126164926.10037.53986.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 08:49:26 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-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, 26 Nov 2012 16:49:26 -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 : Best Practices for Advertisement of Multiple Paths in IB= GP Author(s) : Jim Uttaro Virginie Van den Schrieck Pierre Francois Roberto Fragassi Adam Simpson Pradosh Mohapatra Filename : draft-ietf-idr-add-paths-guidelines-04.txt Pages : 23 Date : 2012-11-26 Abstract: Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-add-paths-guidelines-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Nov 27 10:35: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 D5C5021F8753; Tue, 27 Nov 2012 10:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 rmuiwaptdR9c; Tue, 27 Nov 2012 10:35:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC39A21F888E; Tue, 27 Nov 2012 10:35:28 -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: <20121127183528.26990.28280.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 10:35:28 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-09.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, 27 Nov 2012 18:35:30 -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 : The Accumulated IGP Metric Attribute for BGP Author(s) : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-09.txt Pages : 14 Date : 2012-11-27 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-aigp-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From danny@tcb.net Wed Nov 28 09: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 4BDC721F889E for ; Wed, 28 Nov 2012 09:49: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_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 4VmT+W7aApyS for ; Wed, 28 Nov 2012 09:49:56 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id DD7AA21F888E for ; Wed, 28 Nov 2012 09:49:56 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 8AAD822D6 for ; Wed, 28 Nov 2012 17:49:56 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 34EA22206; Wed, 28 Nov 2012 10:49:56 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Wed, 28 Nov 2012 12:49:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> To: John G. Scudder X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 28 10:49:56 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50b64ec4199634325019771 X-DSPAM-Factors: 27, of+#+#+Deprecating, 0.40000, Subject*Idr+#+WG, 0.40000, use+#+so, 0.40000, to+#+point, 0.40000, CLUSTER+#+#+#+submitted, 0.40000, a+#+where, 0.40000, If+#+ever, 0.40000, as+#+If, 0.40000, tiny+#+#+#+substantive, 0.40000, to+#+the, 0.40000, to+#+the, 0.40000, as+#+Might, 0.40000, ADVERTISER+#+RCID, 0.40000, ADVERTISER+#+RCID, 0.40000, CLUSTER+#+#+#+as, 0.40000, remove+#+ambiguities, 0.40000, I+#+#+#+changes, 0.40000, To*Scudder+jgs, 0.40000, ambiguities+#+IANA, 0.40000, Deprecated+The, 0.40000, ambiguities+#+#+Considerations, 0.40000, IESG+#+#+#+changing, 0.40000, changing+#+#+values, 0.40000, Might+#+#+this, 0.40000, as+Deprecated, 0.40000, as+Deprecated, 0.40000, points+the, 0.40000 Cc: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Wed, 28 Nov 2012 17:49:57 -0000 On Nov 14, 2012, at 1:16 PM, John G. Scudder wrote: > Hi, >=20 > Nobody responded to my note of November 8 ("Deprecating path = attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, = I've submitted the below tiny Internet Draft. The substantive text of = the draft is: ... > 2. IANA Considerations >=20 > This document requests IANA to mark the BGP Path Attributes registry > entries for DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID as > "Deprecated". >=20 > The rest is boilerplate, references, etc.=20 John,=20 I support this as well. Might I offer this trivial changes to remove=20 potential ambiguities: =3D=3D=3D=3D=3D 2. IANA Considerations This document requests IANA to mark the BGP Path Attributes registry entries for DPA (Value 11), ADVERTISER (Value 12), and RCID_PATH /=20 CLUSTER_ID (Value 13) as "Deprecated". =3D=3D=3D=3D=3D If we ever get to a point where there is a lack of code points, the IESG=20= would then confirm changing the deprecated values to be unassigned=20 for use, or so it goes.. -danny= From jgs@juniper.net Wed Nov 28 13:29: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 BAF5B21F867B for ; Wed, 28 Nov 2012 13:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[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 XJ9p63ugCLiE for ; Wed, 28 Nov 2012 13:29:40 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6921F85E1 for ; Wed, 28 Nov 2012 13:29:40 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKULaCQ8X88mVG6Kt/VOelEoc4fVws1xj4@postini.com; Wed, 28 Nov 2012 13:29:40 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Nov 2012 13:26:19 -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; Wed, 28 Nov 2012 13:26:18 -0800 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Nov 2012 13:32:56 -0800 Received: from mail140-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Nov 2012 21:26:11 +0000 Received: from mail140-co1 (localhost [127.0.0.1]) by mail140-co1-R.bigfish.com (Postfix) with ESMTP id 2165B4800AF for ; Wed, 28 Nov 2012 21:26:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz4015Izz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275dh17598diz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1155h) Received: from mail140-co1 (localhost.localdomain [127.0.0.1]) by mail140-co1 (MessageSwitch) id 1354137969209026_4299; Wed, 28 Nov 2012 21:26:09 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.241]) by mail140-co1.bigfish.com (Postfix) with ESMTP id 266059A027D for ; Wed, 28 Nov 2012 21:26:09 +0000 (UTC) Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Nov 2012 21:26:07 +0000 Received: from sa-nc-common2-127.static.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.233.5; Wed, 28 Nov 2012 21:26:07 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Wed, 28 Nov 2012 16:26:03 -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] 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, 28 Nov 2012 21:29:40 -0000 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.= From farmer@umn.edu Wed Nov 28 14: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 E04F321F85DD for ; Wed, 28 Nov 2012 14:53: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=[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 gVUPdAEVxFtD for ; Wed, 28 Nov 2012 14:53:51 -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 5E06A21F85D9 for ; Wed, 28 Nov 2012 14:53:51 -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 ; Wed, 28 Nov 2012 16:53:40 -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 k14so64289332oag.1 for ; Wed, 28 Nov 2012 14:53:39 -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=ju0M2ntBP777c+pEKX2RCMeWJ/mM97i1V4oLhU5UyYs=; b=g65fYK08H9oGHuFPhaTzsTsVpjIdolHNb01y1HCDg427IhtmfiMzhiZNkD2It7wb74 EtABM9RG+5szY80ERDe517Scxub72tOqDNNHG8TacMFuyuWqcCpzyzKHCB5kx79bdH2Z u5Ley49cVQ/n4+3IDcAzbi5ctgDN1wgo9pOUjy4WC8gzirp63FInegus0rP/GLvKVzgw y67t+n4AjQcyjl0xMPWxwn1twrzSr/V/i/0vujvbGIwUQdr2i1jh0xwSkgV1TLjs6stJ RTvZ0wSa6r1ADnbJo1v+mWYDjuoBIwziXhZ23YQWE3+rYD3/RBerPyjkhecPNYCCJvP7 ptYA== Received: by 10.50.161.232 with SMTP id xv8mr21408746igb.22.1354143219259; Wed, 28 Nov 2012 14:53:39 -0800 (PST) Received: by 10.50.161.232 with SMTP id xv8mr21408735igb.22.1354143219139; Wed, 28 Nov 2012 14:53:39 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu ([2607:ea00:101:2001:a419:a7d1:f731:9187]) by mx.google.com with ESMTPS id x5sm5571105igc.14.2012.11.28.14.53.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 14:53:38 -0800 (PST) Message-ID: <50B695F6.7070908@umn.edu> Date: Wed, 28 Nov 2012 16:53: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: "John G. Scudder" References: <20121114180611.17620.93258.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnBDrZYiiJJ3rMZG5s793BD2nZgDQi5bimQDUe+8l5z/AafLj6CUNwVHo9ZNqvAZ7SNYjxIk6Z99jK/B6AIkoLMprd/VgiD5zkWsoammG1BcbpBLCow8fSdontCgcE61KA3gAz7 Cc: "idr@ietf. org" Subject: Re: [Idr] Requesting WG adoption and WGLC of 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: Wed, 28 Nov 2012 22:53:52 -0000 Support Both. On 11/14/12 12:16 , John G. Scudder wrote: > Hi, > > Nobody responded to my note of November 8 ("Deprecating path attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID"). Accordingly, I've submitted the below tiny Internet Draft. The substantive text of the draft is: ... > I would like to ask the WG to adopt the draft. Since the draft is so trivial, I would like to also request a WGLC, to run in parallel. > > Since many WG members will be on holiday for part of next week, let's have the call for adoption + WGLC end on December 3. Please send any comments before December 3. > > Also, regarding the out-of-the-ordinary expedited WGLC: If there's any disagreement whatsoever (with the content or wording of the draft, its adoption, or indeed the expedited procedure itself), let's have only the call for adoption end on December 3, and then we can do a normal WGLC when appropriate. > > Thanks, > > --John (wearing two hats) -- ================================================ 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 Wed Nov 28 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 A2BF421F88A0 for ; Wed, 28 Nov 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=[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 29th1V-54eYW for ; Wed, 28 Nov 2012 14:59: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 022AF21F875A for ; Wed, 28 Nov 2012 14:59:06 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 28 Nov 2012 16:58:37 -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 k14so64309436oag.1 for ; Wed, 28 Nov 2012 14:58: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=43rJxrkB2rO4fiUdw8naMDMpaLNXnqsvyj/4R8hX000=; b=UhF49mPhXxZWhMDjzk8fIPovFwgbga/L+7JRGVAS1AVxEknQ4LVsM7oYsF2GLKXTUe 7jSK4TpI2gEMwwAStoTI4JYTV3NXhCOPPcPxcFq849TTi2V8aoGcJewCy7G3ei4RAIPg 8aothLEazA3VtdeWd/TO+V/Hb2zUFlXnDnm9OOIPUGMWkz4tiLFdvX5q1F1d0qx8j207 lqXSsfqdcZ/5UPFl48k4z0+sAHK+uHAfpLdrHn9vlJp6uemH7ldT2X1e51NCf+dZIpSc xBAGOr0mPTk01Ye6U4zzJ5Pu8VktvyUMl53AesQuIL+bERcvake8Eob+5SS5Xf15Uw0M n74w== Received: by 10.50.94.166 with SMTP id dd6mr21171956igb.38.1354143516217; Wed, 28 Nov 2012 14:58:36 -0800 (PST) Received: by 10.50.94.166 with SMTP id dd6mr21171949igb.38.1354143516108; Wed, 28 Nov 2012 14:58:36 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu ([2607:ea00:101:2001:a419:a7d1:f731:9187]) by mx.google.com with ESMTPS id hg2sm5601361igc.3.2012.11.28.14.58.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 14:58:35 -0800 (PST) Message-ID: <50B6971F.502@umn.edu> Date: Wed, 28 Nov 2012 16:58:39 -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: John Scudder References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnw/yaRCd4TIcgSi2HixfkB2OBNYqRU20IhMYIzAzBIQtw38IcL6BeDvVhS4Xa93t7SLwvV6p+IR1JGkctxiLF9YSWNVha15fj7lOfWorEYDx65CTYIQsD2GaG0TtiZM/O5lu0g 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, 28 Nov 2012 22:59:06 -0000 Support By the way, speaking of December 12; Support Sandy relief too. :) http://www.121212concert.org/ On 11/28/12 15:26 , 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. -- ================================================ 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 Wed Nov 28 15:30: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 C7F8511E8097 for ; Wed, 28 Nov 2012 15:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 aRwCtt9v0cFi for ; Wed, 28 Nov 2012 15:30:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5B53E11E809A for ; Wed, 28 Nov 2012 15:30:20 -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 1Tdr59-0007Er-Fj; Wed, 28 Nov 2012 23:30:19 +0000 Date: Thu, 29 Nov 2012 08:30:18 +0900 Message-ID: From: Randy Bush To: John Scudder 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 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, 28 Nov 2012 23:30:21 -0000 > We have received a request for a working group last call on > draft-ietf-idr-as-private-reservation-00. i do not support this drafr. do we need to repeat the previous discussion? randy From rraszuk@gmail.com Wed Nov 28 15:50: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 E528111E80A4 for ; Wed, 28 Nov 2012 15:50:35 -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 hWII52JAs-5o for ; Wed, 28 Nov 2012 15:50:35 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9D711E809C for ; Wed, 28 Nov 2012 15:50:35 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so11149217qca.31 for ; Wed, 28 Nov 2012 15:50:34 -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=COmQySmbB4DzkFXjZ2Zn0+WhZutRCB4hiqIJ0LTYUB4=; b=ccsPtrRVGbGe0/kPE1yYQ27a0FyS6NiK4clBru6GEkOlUH/0bekaOydl250nLeuHCv iqlvwiMx8IrUd8YyVrcu/mRb31hgPuFm9UCRc88Zutw//CxVhqzyOLFHBwZtXeTG4vSg iEdoLgeBrzdQ6Sc65rEq/AaVnqjPnWpXuwGN3zsyCWvfu5TrSnH/DynXDFO1aQJoGmgV 43joYLZHmuTWWJ5mya417tLpRJb008MEMy+SHb2Fbyux8p2Nx9QCBUsl6mCrnjIfW9Nb exheLevIRdev2E2bgihx7tFSh2u/kZXBULF6PloHtHRldXh0QL7NaqKEO2rdIvYImpZc dTQg== MIME-Version: 1.0 Received: by 10.224.208.68 with SMTP id gb4mr22674883qab.99.1354146634827; Wed, 28 Nov 2012 15:50:34 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.49.106.234 with HTTP; Wed, 28 Nov 2012 15:50:34 -0800 (PST) In-Reply-To: References: Date: Thu, 29 Nov 2012 00:50:34 +0100 X-Google-Sender-Auth: VyfES9JWBxHeENVcJ6kmJyL7SR8 Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 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, 28 Nov 2012 23:50:36 -0000 Hello Randy and all, I admit that when we first discussed this proposal it was very unclear what the real objective is and I admit I was also personally quite unsure about it's value. However after discussing it directly with Petr in Vancouver and reading carefully his other draft (which unfortunately was posted after this one) which was http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-02 I do see a very valid need to allow much bigger space for private AS block to allow for constructing arbitrary private networks especially using EBGP as the dynamic routing protocol. Therefor I do support publishing this as RFC and getting IANA allocation for the extended AS 4 octet block. Best regards, R. > On Thu, Nov 29, 2012 at 12:30 AM, Randy Bush wrote: > >> We have received a request for a working group last call on >> draft-ietf-idr-as-private-reservation-00. > > i do not support this drafr. do we need to repeat the previous > discussion? > > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From gih@apnic.net Wed Nov 28 19:07: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 A579311E80BF for ; Wed, 28 Nov 2012 19:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SvBJTHOx3fMJ for ; Wed, 28 Nov 2012 19:07:07 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 824BF11E80A3 for ; Wed, 28 Nov 2012 19:07:07 -0800 (PST) Received: from [IPv6:2001:388:1000:110:38dd:f84e:9488:5278] (unknown [IPv6:2001:388:1000:110:38dd:f84e:9488:5278]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C22C7B6744; Thu, 29 Nov 2012 13:07:05 +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: Date: Thu, 29 Nov 2012 14:07:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> References: To: John Scudder X-Mailer: Apple Mail (2.1499) 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, 29 Nov 2012 03:07:12 -0000 On 29/11/2012, at 8:26 AM, 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 I am opposed to this draft - increasing the size of a unordered = non-unique identifier space is counter-productive. regards, Geoff From tony.li@tony.li Thu Nov 29 08:42: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 9E8A521F89E1 for ; Thu, 29 Nov 2012 08:42:14 -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 iLwpABbH3E4U for ; Thu, 29 Nov 2012 08:42:14 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7D21F89EE for ; Thu, 29 Nov 2012 08:42:14 -0800 (PST) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta06.emeryville.ca.mail.comcast.net with comcast id VUAS1k0050mlR8UA6UiE1c; Thu, 29 Nov 2012 16:42:14 +0000 Received: from [10.154.208.21] ([128.107.239.233]) by omta11.emeryville.ca.mail.comcast.net with comcast id VUg31k00S52qHCY8XUg537; Thu, 29 Nov 2012 16:40:12 +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, 29 Nov 2012 08:40:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: 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=1354207334; bh=gcoMe/IO32g/X1fCg1/qchQ/B67k04uRDdR3ZDfO55w=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=EU9JTfRZ4sbbYB7dE+hpYVIk8wJoV3OPajvz3+8xHpGPRyji9vdVK+Jr9mCIsjH3b LdpKO59xiWzg5k0VtzSWzjRURGr7EWtUyf2vBkUzdovuzGBTjuOiP1ouEp8xNaHYE6 mPdKNRRTfYWMMxSXdaeVdDG+N6vVwxo49mYjeu4X6CcJIJgIFBPqxqEDMdquh+PuZB OabQr9wt9BeQTkBNPVUBSg3KbE0WMksD2ecXMorYDJBeL9HCwvJMqmXOOR0j2y/UKr vbYQO/0LCILHK7xEDvv2Yu+tkqdDAgpG+Dcyi1ceyOPVPI3+2bumViUooKFRUVPTql DIFSaghsOevhw== 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, 29 Nov 2012 16:42:14 -0000 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, >=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 From warren@kumari.net Thu Nov 29 08: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 0DF5D21F8B5E for ; Thu, 29 Nov 2012 08:49: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 1cqyfa113CeE for ; Thu, 29 Nov 2012 08:49:36 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B35821F8B6E for ; Thu, 29 Nov 2012 08:49:34 -0800 (PST) Received: from [192.168.1.142] (unknown [66.84.81.119]) by vimes.kumari.net (Postfix) with ESMTPSA id 0528A1B40653; Thu, 29 Nov 2012 11:49:34 -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: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> Date: Thu, 29 Nov 2012 11:49:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1499) 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, 29 Nov 2012 16:49:37 -0000 On Nov 28, 2012, at 10:07 PM, Geoff Huston wrote: >=20 > On 29/11/2012, at 8:26 AM, John Scudder wrote: >=20 >> 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 >=20 > I am opposed to this draft - increasing the size of a unordered = non-unique identifier space is counter-productive. =85 and I support it -- some folk have a need for more than 1023 = "private" ASNs and *really really* don't want to do the "just reuse the = same one and then use something like the 'allows-in' and similar hacks". Yes, going to an RIR and requesting a few thousand global ASes is = possible, but to me seems inelegant. Close to 100,000 reserved ones feels overly large to me, but it does = line up nicely on a (decimal) boundary. W >=20 > regards, >=20 > Geoff >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --=20 Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 -- J.R.R. Tolkien From jared@puck.nether.net Thu Nov 29 08:53: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 A9C3821F8AEF for ; Thu, 29 Nov 2012 08:53: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=[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 UyTo4PdrUekl for ; Thu, 29 Nov 2012 08:53:36 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 119D721F8AED for ; Thu, 29 Nov 2012 08:53:36 -0800 (PST) Received: from [10.0.0.137] (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 qATGrWXS016893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Nov 2012 11:53:34 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Thu, 29 Nov 2012 11:53:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> References: To: Tony Li 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]); Thu, 29 Nov 2012 11:53:34 -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, 29 Nov 2012 16:53:36 -0000 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: >=20 > Support. >=20 > Editorial nit: I would find it MUCH more helpful if the constants were = also expressed in hex. >=20 > Tony >=20 >=20 > On Nov 28, 2012, at 1:26 PM, John Scudder wrote: >=20 >> 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Thu Nov 29 09:36: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 06A8921F8AC6 for ; Thu, 29 Nov 2012 09:36:25 -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 OWZuqgsB04I7 for ; Thu, 29 Nov 2012 09:36: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 5A68B21F8964 for ; Thu, 29 Nov 2012 09:36:24 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so16277329ieb.31 for ; Thu, 29 Nov 2012 09:36: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 :content-transfer-encoding; bh=BwzTgR+aknLeC/Jz4+KKmk/OHrm4P2XhfkmSifopjkM=; b=cv1RQCOGqVIotZpt5UJzTHAk1GOh4eI5bHdSPh2mfx6R4XxYPjPkYETsjT/EcdRRue 55SM2lhM5K4sG1vjCeMCfCa+peMMyTtOqbzI7NdeISVSJ/0RiqLigyXid/emrFwxxQmH 1NwXxjV2UGO2P8T/VYTbevCGZossVPWnv5Eg7tuA+rQJ2mSNCEY+d4Uv2xFS7Ojs2gGX EXOZSziHMLc7aC6iFEIOJQ0g+nHPh+EhJqzHhfOVz2NROb34hvT4v3PynuFeKj1D+FX9 lnlIjeXwy0qC5oC6FcuIuNg+PhIXSDJhpebCg7jyPJK+7ovAiBmvlyfs2E+oMdaDqZiE jSBw== MIME-Version: 1.0 Received: by 10.50.94.166 with SMTP id dd6mr23782076igb.38.1354210583986; Thu, 29 Nov 2012 09:36:23 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Thu, 29 Nov 2012 09:36:23 -0800 (PST) In-Reply-To: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> Date: Thu, 29 Nov 2012 18:36:23 +0100 X-Google-Sender-Auth: LdCHdXhBsogmDIhhggU9LF8nhXg Message-ID: From: Robert Raszuk To: idr wg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 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: Thu, 29 Nov 2012 17:36:25 -0000 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" 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 u= se. 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. 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. Regards, R. > On Thu, Nov 29, 2012 at 5:53 PM, Jared Mauch wrot= e: > > Greetings, > > Jon pointed me to this draft earlier today so please be kind (for the fir= st 5 minutes after this is delivered in your mailbox.). > > After reading the list history back a few months or so on this topic, I m= ust express the same reservation that Randy and Geoff have raised. > > I do not feel this is a problem space that needs to be addressed. Vendor= s 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 easi= ly by one party engaging with their local RIR for a nominal "cost of runnin= g BGP" threshold. The recurring annual cost is likely a budgetary "roundin= g error" and is not a barrier to entry IMHO. > > I have other concerns should this move forward that would impact operatio= ns. 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 a= lso 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 De= cember 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 jared@puck.nether.net Thu Nov 29 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 A717C21F8B47 for ; Thu, 29 Nov 2012 09:50:48 -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 d5GSbma-fjpf for ; Thu, 29 Nov 2012 09: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 B4C2721F8B40 for ; Thu, 29 Nov 2012 09:50:47 -0800 (PST) Received: from [10.0.0.137] (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 qATHojCl027766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Nov 2012 12:50:45 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Thu, 29 Nov 2012 12:50:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@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]); Thu, 29 Nov 2012 12:50:46 -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: Thu, 29 Nov 2012 17:50:49 -0000 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". >=20 > 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 ... >=20 > 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_note09186a0080093f= 27.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? 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. 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"). > 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" >=20 > On that basis I see no harm in allowing some bigger AS space for = personal use. >=20 > 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 >=20 > Regards, > R. >=20 >> On Thu, Nov 29, 2012 at 5:53 PM, Jared Mauch = wrote: >>=20 >> Greetings, >>=20 >> Jon pointed me to this draft earlier today so please be kind (for the = first 5 minutes after this is delivered in your mailbox.). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> I have other concerns should this move forward that would impact = operations. I will comment on them in private should folks desire. >>=20 >> I do not feel this draft can be supported. >>=20 >> - Jared >>=20 >>=20 >> On Nov 29, 2012, at 11:40 AM, Tony Li wrote: >>=20 >>>=20 >>> Support. >>>=20 >>> Editorial nit: I would find it MUCH more helpful if the constants = were also expressed in hex. >>>=20 >>> Tony >>>=20 >>>=20 >>> On Nov 28, 2012, at 1:26 PM, John Scudder wrote: >>>=20 >>>> 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 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From tony.li@tony.li Thu Nov 29 10:01: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 0F03D21F8AEA for ; Thu, 29 Nov 2012 10:01:39 -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 d1MJroqM5XRn for ; Thu, 29 Nov 2012 10:01:38 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 7482721F8AE5 for ; Thu, 29 Nov 2012 10:01:38 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta15.emeryville.ca.mail.comcast.net with comcast id VSHe1k0080EPchoAFW1dDZ; Thu, 29 Nov 2012 18:01:37 +0000 Received: from [IPv6:2001:420:301:1004:d4af:250c:f893:2bda] ([IPv6:2001:420:301:1004:d4af:250c:f893:2bda]) by omta01.emeryville.ca.mail.comcast.net with comcast id VW1c1k00w1iKM2L8MW1d23; Thu, 29 Nov 2012 18:01:37 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Date: Thu, 29 Nov 2012 10:01:35 -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> To: Jared Mauch X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354212097; bh=QlQXOiuR9l1k/DXLJ38rLMNoX8zVs1t0PtOs2z85eH0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=ojAOIIt8F5agUQGJUCsEs3WBTpM5rRjCIPKPlhNZuo87GcSKLRO84QgkOrIFKBOmS NT+bqXM6fZtoCukK5Fjmdt+Z8UgXJLhPufoE3JlN9DURRuwz0chpiTQlOMDmaVgW6t WkSUN+vGTApPc7HOfn/gKIMrbWpXI24TXsE6wn9uaz0S5BoJAoZGHPW6Jp12TtWwL2 u1SVINlLrtAU6V+CqKbJ4N7G0WyBry83DgHVRbRmnMvJMoK6E/IwPkn5oB3916gmfe bmW9wAIN6WuwTxJIwj0g19vDpJfRedfBYBo/6iy2tnKx8VDIyKNcEPJmjnLUzf2R1i kqSgPE97CSvdg== 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: Thu, 29 Nov 2012 18:01:39 -0000 On Nov 29, 2012, at 9:50 AM, Jared Mauch wrote: >> Internet folks will say "Do not trash our environment" >=20 > As an operator, I feel this is a fair thing for me to say. :) Indeed it is. =20 However, I think it's also fair to point out that allocating a chunk = from a large namespace and effectively taking out of the big I = environment doesn't do much to trash it. Other proposals have had MUCH more environmental impact. Tony From christopher.morrow@gmail.com Thu Nov 29 10: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 46ABC21F8B48 for ; Thu, 29 Nov 2012 10:19:37 -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 D8uAfSUHo1QJ for ; Thu, 29 Nov 2012 10:19: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 3116721F8BA6 for ; Thu, 29 Nov 2012 10:19:32 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so9391156eek.31 for ; Thu, 29 Nov 2012 10:19:31 -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=IHUpEA32Rnpb6c3lPovokyHFjV16Yt2KTmiigFCuMb4=; b=KHJ/3NoqisiKpDoecun3Xg16ESWAghCtAGkQrTPEQgt09m5XMxTpG3JNwPLIk3Byi1 cexmMOAugZOVApYaEMvjyKqW5+xVE7MLg4/eScIlcMnGxUF8fBe+fe1ZTyxtrqci8VhW WD/MFR9EYna+/H2yI4MLPSXnHVyA6XNBXR7snTWlXduYuOChyGSvXiVrqE1nnVsX7ZAg gbTRSIAi4T+NOz02ewQqdBHZKhDsCDAvuk8IqD1azSks0MS9f+Jq6Op2kQ9SbUOruH6P u6ons8f6OUmSXYkr+hQb7R+JdMvGXzgH/6iunT4905roVHvp4B/dJFjfJBidVoXpWhqD c5pA== MIME-Version: 1.0 Received: by 10.14.3.195 with SMTP id 43mr84613808eeh.36.1354213171208; Thu, 29 Nov 2012 10:19:31 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.96.5 with HTTP; Thu, 29 Nov 2012 10:19:30 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Date: Thu, 29 Nov 2012 13:19:30 -0500 X-Google-Sender-Auth: dn8dPNlzRY1wW8-4zI_qHzX9u8E Message-ID: From: Christopher Morrow To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 29 Nov 2012 18:19:37 -0000 On Thu, Nov 29, 2012 at 1:01 PM, Tony Li wrote: > > On Nov 29, 2012, at 9:50 AM, Jared Mauch wrote: > >>> Internet folks will say "Do not trash our environment" >> >> As an operator, I feel this is a fair thing for me to say. :) > > > Indeed it is. > > However, I think it's also fair to point out that allocating a chunk from a large namespace and effectively taking out of the big I environment doesn't do much to trash it. > because private asns don't leak? route-views>sho ip bgp regex _64..._ Network Next Hop Metric LocPrf Weight Path * 27.123.19.0/24 195.66.232.239 0 5459 38082 64549 ? * 41.76.104.0/21 196.7.106.245 0 0 2905 11845 64525 i * 41.90.0.0/16 114.31.199.1 0 0 4826 8966 33771 65535 64555 64555 33771 i * 194.85.40.15 0 3267 2603 8966 33771 65535 64555 64555 33771 i * 41.209.32.0/19 164.128.32.11 0 3303 174 9129 9129 9129 9129 {4558,15808,64520} i * 131.124.1.0/24 69.31.111.244 0 0 4436 4323 64778 i * 131.124.2.0/24 69.31.111.244 0 0 4436 4323 64778 i * 131.124.3.0/24 69.31.111.244 0 0 4436 4323 64778 i * 131.124.4.0/24 69.31.111.244 0 0 4436 4323 64778 i * 131.124.5.0/24 69.31.111.244 0 0 4436 4323 64778 i (hi twtc! filter-customer-much?) From gih@apnic.net Thu Nov 29 10: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 5C72821F8AF9 for ; Thu, 29 Nov 2012 10:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2+hw2TnTnz2c for ; Thu, 29 Nov 2012 10:21:07 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 6861621F8AE1 for ; Thu, 29 Nov 2012 10:21:07 -0800 (PST) Received: from 2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net (2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net [IPv6:2001:44b8:1121:1a00:3448:34ba:4195:613f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 76154B6745; Fri, 30 Nov 2012 04:21:05 +1000 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> Date: Fri, 30 Nov 2012 05:21:04 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1499) 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, 29 Nov 2012 18:21:08 -0000 On 30/11/2012, at 3:49 AM, Warren Kumari wrote: >=20 > On Nov 28, 2012, at 10:07 PM, Geoff Huston wrote: >=20 >>=20 >> On 29/11/2012, at 8:26 AM, John Scudder wrote: >>=20 >>> 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 >>=20 >> I am opposed to this draft - increasing the size of a unordered = non-unique identifier space is counter-productive. >=20 > =85 and I support it -- some folk have a need for more than 1023 = "private" ASNs and *really really* don't want to do the "just reuse the = same one and then use something like the 'allows-in' and similar hacks". >=20 > Yes, going to an RIR and requesting a few thousand global ASes is = possible, but to me seems inelegant. ??? >=20 > Close to 100,000 reserved ones feels overly large to me, but it does = line up nicely on a (decimal) boundary. But if there is a single need for 100,000 code points in single coherent = space then you have to ask how one could ensure uniqueness within the = deployment space, as you are now talking about a large number of = entities and a large coder point space, and according to your response, = the reason why there is a driving need duplicate an existing uniqueness = framework is because the current framework we have for ensuring = uniqueness of AS number code points is ... "inelegant"? Obviously I'm unconvinced by such as assertion, and remain opposed to = the further progress of this document. Geoff =20 From jared@puck.nether.net Thu Nov 29 10:29: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 7985821F89BA for ; Thu, 29 Nov 2012 10:29:51 -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 2GvYhvMFQjvi for ; Thu, 29 Nov 2012 10:29:50 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8195821F841B for ; Thu, 29 Nov 2012 10:29:50 -0800 (PST) Received: from [10.0.0.137] (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 qATITgkv006282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Nov 2012 13:29:43 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jared Mauch In-Reply-To: Date: Thu, 29 Nov 2012 13:29:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <165A232F-F07C-4AD1-9A08-55A6BD238656@puck.nether.net> References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> To: Geoff Huston 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]); Thu, 29 Nov 2012 13:29:43 -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, 29 Nov 2012 18:29:51 -0000 On Nov 29, 2012, at 1:21 PM, Geoff Huston wrote: > On 30/11/2012, at 3:49 AM, Warren Kumari wrote: >=20 >>=20 >> On Nov 28, 2012, at 10:07 PM, Geoff Huston wrote: >>=20 >>>=20 >>> On 29/11/2012, at 8:26 AM, John Scudder wrote: >>>=20 >>>> 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 >>>=20 >>> I am opposed to this draft - increasing the size of a unordered = non-unique identifier space is counter-productive. >>=20 >> =85 and I support it -- some folk have a need for more than 1023 = "private" ASNs and *really really* don't want to do the "just reuse the = same one and then use something like the 'allows-in' and similar hacks". >>=20 >> Yes, going to an RIR and requesting a few thousand global ASes is = possible, but to me seems inelegant. >=20 > ??? I think the issue he raises here is that to provide uniqueness, one = could ask for real ASNs, but folks may not or be unable to do this. If = they are not used on the big-I Internet, why should they come from that = pool. >=20 >>=20 >> Close to 100,000 reserved ones feels overly large to me, but it does = line up nicely on a (decimal) boundary. >=20 > But if there is a single need for 100,000 code points in single = coherent space then you have to ask how one could ensure uniqueness = within the deployment space, as you are now talking about a large number = of entities and a large coder point space, and according to your = response, the reason why there is a driving need duplicate an existing = uniqueness framework is because the current framework we have for = ensuring uniqueness of AS number code points is ... "inelegant"? I raised this issue privately with someone earlier today as well. = Collisions are likely to happen as someone will either take the min(private_as_space) and increment, or take max() and = decrement. It's impractical to take a random number from that space, = and even if so, does not prevent a collision. If you have a need for a = unique ASN to avoid this case, one should apply for one, even if used on = a private network. In arin region it seems it would be $500 one time + = $100/year. Likely around the cost of those 10G optics or the O&M on the = equipment being used so easily justified. > Obviously I'm unconvinced by such as assertion, and remain opposed to = the further progress of this document. I share this reservation and respectfully disagree with my friend Warren = on this topic. - Jared From tony.li@tony.li Thu Nov 29 10:57: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 A00CE21F8B66 for ; Thu, 29 Nov 2012 10:57:49 -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 ieWrMzVP6ETY for ; Thu, 29 Nov 2012 10:57:49 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E021F8B67 for ; Thu, 29 Nov 2012 10:57:49 -0800 (PST) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta02.emeryville.ca.mail.comcast.net with comcast id VWLg1k0010b6N64A2WxpSi; Thu, 29 Nov 2012 18:57:49 +0000 Received: from [10.155.35.198] ([128.107.239.234]) by omta03.emeryville.ca.mail.comcast.net with comcast id VWvd1k003547xYo8PWvftS; Thu, 29 Nov 2012 18:55:47 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 29 Nov 2012 10:55:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <574CC47E-4BF6-4749-8B44-CFA526ECDFD6@tony.li> References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.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=1354215469; bh=xONr1n+O8GG48/ql5c/A15y6kzqNtAcSMxspqKNuwOk=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=XYnBvsI2DNeNkFAs2Jv6HxnU1/D36PpdzSEdTRYssW+thAb3kF8THbpeuaU89bt1+ 7W+981JhqLC8PcHZs9T1nkjm6xIThCwBVRKNo6rowRbF2FUeGxdKBlZYKvxrzPtfyr suamnLjGgpi4swy4MsE3YKu403iAFDtoTN9tWjHuc+QQeUyP+1RGts6HoncoZ2sdNc rWZnWapaFEzBXTQHSfWc+cgr4MvS9PxmVnKos3GJUT7mITMb6M93nY9dipuNbW/IgF iwh6oIc0BZe2Ip1tKNs3FGXRLthT10JGpSDwCkoSDB3xWIPCidL+QnP1fqZ3afrt58 QlZ21+yY57jmg== 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, 29 Nov 2012 18:57:49 -0000 On Nov 29, 2012, at 10:21 AM, Geoff Huston wrote: > But if there is a single need for 100,000 code points in single = coherent space then you have to ask how one could ensure uniqueness = within the deployment space, as you are now talking about a large number = of entities and a large coder point space, and according to your = response, the reason why there is a driving need duplicate an existing = uniqueness framework is because the current framework we have for = ensuring uniqueness of AS number code points is ... "inelegant"? Obviously, the private use ASNs would have local uniqueness and = specified by the local administration. Not a big deal. More to the = point, the noise and fluff of administering this is not something that = you want foisted on the RIRs, especially when multiplied by the number = of sites using it. We've seen over and over again that the right way of creating = scalability is to create hierarchy. All this is doing is to continue = its instantiation. Tony From farmer@umn.edu Thu Nov 29 11:10: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 60E1821F8B27 for ; Thu, 29 Nov 2012 11:10:53 -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 RbAC8IFuKq-0 for ; Thu, 29 Nov 2012 11:10:45 -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 2994721F8B62 for ; Thu, 29 Nov 2012 11:10:45 -0800 (PST) Received: from mail-oa0-f70.google.com (mail-oa0-f70.google.com [209.85.219.70]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 29 Nov 2012 13:10:31 -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 k14so69011529oag.1 for ; Thu, 29 Nov 2012 11:10:30 -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=PHyysCxG+XmAl/4baSyYXzgoT1ZqIqkluD9pMRzonJQ=; b=UuR1sGqg3uTYLtMfgh1ijXxzDuCn7Wg948BxApQ3g4TvC8OR9hoU7hoctTj9yleglV IA5ZQ0BEBIPemQ4bkUiApo9d1x7iX29gr1fC7emstjWSQtmkgfCUCYxL6uYIYLOYY86A lbWjsj+0/BTohlfowWwMBGvucXkx2IErMvvRxuYx/Eo0TNu7NRFm/Qg00Oex0OxhoDdI TWmIXc1AIHIGRqNPOgyzjOCKxqeUnD9rmd0T5JuvIUOQC9Dd6yQ5ZBPHi/aoIqLBTEj3 V60E3py0PJ8Jv6CMOgePPfyghuppa5tLHSuquQnPDTvHcJzPjB6o6PYiWGxuanOqwrhQ 4Jgg== Received: by 10.50.6.169 with SMTP id c9mr24087015iga.24.1354216229476; Thu, 29 Nov 2012 11:10:29 -0800 (PST) Received: by 10.50.6.169 with SMTP id c9mr24086955iga.24.1354216228404; Thu, 29 Nov 2012 11:10:28 -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 vq4sm7927552igb.10.2012.11.29.11.10.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 11:10:27 -0800 (PST) Message-ID: <50B7B323.9040907@umn.edu> Date: Thu, 29 Nov 2012 13:10:27 -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: Jared Mauch References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> In-Reply-To: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmcXKqD07Tjei7LxMMKVd9VV7oCo/hciyRD/f23KCBI6yAxKXYr8U7GcPFBNf+dwrR19oSWfEm29sCc8JwacGskDnl71c0BWUyvyrYAmEEXLSQB9xGxgbx47hzHjjm9nQQCegM2 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: Thu, 29 Nov 2012 19:10:54 -0000 On 11/29/12 11:50 , Jared Mauch wrote: > Robert, > > On Nov 29, 2012, at 12:36 PM, Robert Raszuk wrote: ... >> 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. .... To this point, yes the RIR policies could be changed and I would support that. However, the RIR's current policies are based on technical recommendations of this community in RFC 1930, and can be summarized as essentially one ASN per org and large by comparison block of shared Private-Use ASNs, for internal use. Furthermore, I don't see the RIRs changing their policies without IDR updating its technical recommendations. This Draft simply extends the technical direction of RFC 1930 to provide a larger block of Privete-Use ASNs, now that 4-byte ASNs make that possible. By the way, that can't be done by the RIRs, this must be done by the IETF as technical allocations like this are in its domain. However, if you are saying that the technical recommendations of RFC 1930 are no longer valid or preferred; And, IDR would prefer that large unique blocks of ASNs be handed out to organizations solely for internal use, then IDR should provide updated technical recommendations to that effect for the RIR policy community to consider. In my view IDR either needs to do its job and expand technical allocation for the Private-Use ASNs or deprecate the technical recommendations of RFC 1930 in this regard. Providing new recommendations against the use of Private ASNs all together and that large blocks of ASNs should be allocated and registered solely for internal use within organizations by the RIRs. If IDR can't agree on one of those two alternatives, then IDR needs to stop extending BGP and develop a new protocol to handle all the new applications that are being bolted onto BGP. 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 Nov 29 11:10: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 A47F621F8B91 for ; Thu, 29 Nov 2012 11:10:58 -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 HPn8hce2IYq1 for ; Thu, 29 Nov 2012 11:10:54 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 50F3921F8B87 for ; Thu, 29 Nov 2012 11:10:53 -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 qATJAhE7013199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 14:10:43 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qATJAhSQ013198; Thu, 29 Nov 2012 14:10:43 -0500 Date: Thu, 29 Nov 2012 14:10:43 -0500 From: Jon Mitchell To: Christopher Morrow Message-ID: <20121129191043.GA9189@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: 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, 29 Nov 2012 14:10: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: Thu, 29 Nov 2012 19:10:58 -0000 As I've stated before, mis-configuration or improper use of private use ASNs doesn't seem to be highly correlated to the size of the range. If this were an issue, I guess, we would expect that a network would be leaking close to 1K ASNs today that then would expand to many thousands or millions after the draft is approved? 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. Jon On Thu, Nov 29, 2012 at 01:19:30PM -0500, Christopher Morrow wrote: > On Thu, Nov 29, 2012 at 1:01 PM, Tony Li wrote: > > > > On Nov 29, 2012, at 9:50 AM, Jared Mauch wrote: > > > >>> Internet folks will say "Do not trash our environment" > >> > >> As an operator, I feel this is a fair thing for me to say. :) > > > > > > Indeed it is. > > > > However, I think it's also fair to point out that allocating a chunk from a large namespace and effectively taking out of the big I environment doesn't do much to trash it. > > > > because private asns don't leak? > route-views>sho ip bgp regex _64..._ > > Network Next Hop Metric LocPrf Weight Path > * 27.123.19.0/24 195.66.232.239 0 5459 38082 64549 ? > * 41.76.104.0/21 196.7.106.245 0 0 2905 11845 64525 i > * 41.90.0.0/16 114.31.199.1 0 0 4826 8966 > 33771 65535 64555 64555 33771 i > * 194.85.40.15 0 3267 2603 > 8966 33771 65535 64555 64555 33771 i > * 41.209.32.0/19 164.128.32.11 0 3303 174 > 9129 9129 9129 9129 {4558,15808,64520} i > * 131.124.1.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.2.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.3.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.4.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.5.0/24 69.31.111.244 0 0 4436 4323 64778 i > > (hi twtc! filter-customer-much?) > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Thu Nov 29 11:22: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 CFCF521F8B82 for ; Thu, 29 Nov 2012 11:22:07 -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 wJkisZTk5LpJ for ; Thu, 29 Nov 2012 11:22:06 -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 C1DDA21F8B2E for ; Thu, 29 Nov 2012 11:22:06 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so12122286iaf.31 for ; Thu, 29 Nov 2012 11:22: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=H5+pxDp0akzla9hdvY9UY3OoK4ecAn0ag+SChVxpJ2U=; b=oVuMB4DHlNw65d4OHIe8FWOLmyersf+m4sT5SoUEJlWJ6dcbCTGUjcbXBUq5vxtl10 WjXcriHChSFm7bD3zV5tA0uIjGg+bB1TlQKBR1YUvXlsqtoLw9rxXtNNC0Y0xEdOWoxQ iXq+kDPdAavXU878aIwGU0M1jJnT8KBaUyeuJ8GsnSDoxVWw4VX+/AkANS4h2+MJX5qg O6ErcX6vtQnGqe0QD31i6WsAtqILsMv/ZlW4O7Vr10CLlu/c3gwmcTotVxH084e2FiiB 24aGtRNFTlPCNIG7kcHI3Dy6uDOPTifP/nAHAWJbVzrYxrlLDIzwmTWArIufNvLISBHk 8V8A== MIME-Version: 1.0 Received: by 10.43.113.65 with SMTP id ev1mr21085352icc.47.1354216926009; Thu, 29 Nov 2012 11:22:06 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Thu, 29 Nov 2012 11:22:05 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Date: Thu, 29 Nov 2012 20:22:05 +0100 X-Google-Sender-Auth: XKfA33JKfvcKJXpjIjYEvN2eahc Message-ID: From: Robert Raszuk To: Christopher Morrow 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: Thu, 29 Nov 2012 19:22:07 -0000 Chris, So what is exactly the concern here ? The fact that folks are trying to reserve large pool of AS numbers for their own use or that folks are afraid that this will be used in AFI/SAFI 1/1 and/or 2/1 and will end up visible in the Internet ? If really the concern is the latter maybe we should try to address the right concern (new instance of BGP and/or new SAFI) rather then resisting the actual idea of extended AS pool reservation ? Many thx, R. On Thu, Nov 29, 2012 at 7:19 PM, Christopher Morrow wrote: > On Thu, Nov 29, 2012 at 1:01 PM, Tony Li wrote: >> >> On Nov 29, 2012, at 9:50 AM, Jared Mauch wrote: >> >>>> Internet folks will say "Do not trash our environment" >>> >>> As an operator, I feel this is a fair thing for me to say. :) >> >> >> Indeed it is. >> >> However, I think it's also fair to point out that allocating a chunk from a large namespace and effectively taking out of the big I environment doesn't do much to trash it. >> > > because private asns don't leak? > route-views>sho ip bgp regex _64..._ > > Network Next Hop Metric LocPrf Weight Path > * 27.123.19.0/24 195.66.232.239 0 5459 38082 64549 ? > * 41.76.104.0/21 196.7.106.245 0 0 2905 11845 64525 i > * 41.90.0.0/16 114.31.199.1 0 0 4826 8966 > 33771 65535 64555 64555 33771 i > * 194.85.40.15 0 3267 2603 > 8966 33771 65535 64555 64555 33771 i > * 41.209.32.0/19 164.128.32.11 0 3303 174 > 9129 9129 9129 9129 {4558,15808,64520} i > * 131.124.1.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.2.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.3.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.4.0/24 69.31.111.244 0 0 4436 4323 64778 i > * 131.124.5.0/24 69.31.111.244 0 0 4436 4323 64778 i > > (hi twtc! filter-customer-much?) From brian.peter.dickson@gmail.com Thu Nov 29 11:27: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 A258B21F8BA9 for ; Thu, 29 Nov 2012 11:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 aIz6S89oJDYK for ; Thu, 29 Nov 2012 11:27:42 -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 BAD3B21F8BA7 for ; Thu, 29 Nov 2012 11:27:42 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so16369773oag.31 for ; Thu, 29 Nov 2012 11:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=VeNE96/Uw9HhJh5hicjDtwV2Z2pQdHbfLxLloOHkII0=; b=D9HPsbtGEToT5TDRwbqXsy7VEa3SKQLVxWFx0TbIUptnNbbvbwYNkq4zwRFbxnUuZ9 FkL8K9Y1Qf2MuEkWozQb5SE29vM8DkckJvyKxOkfIQjie432D11G49XklCApiEsoxDjP zrtZgHzPdAZ2WXekLZbQv2btVA7Kz2loCayQdl2FGkt5HbMpsTdalOFe6bDy/OFinsh6 y4rCYvIXDke85Qba0/MwJK7dWMAgs86KqZ5fuFZrzy9BeSjV+aaxoDPB2wAMUsNsBrsG 7tFIhT3kKccbDE9ebMLgIDdzMqSQZ4d0deol7lOUVLsPjjtj5QEiREXT62OSTDg6jeHP LECg== Received: by 10.60.19.133 with SMTP id f5mr2655910oee.105.1354217262152; Thu, 29 Nov 2012 11:27:42 -0800 (PST) Received: from [192.168.2.29] (ip68-100-137-155.dc.dc.cox.net. [68.100.137.155]) by mx.google.com with ESMTPS id aw4sm2071102oec.9.2012.11.29.11.27.40 (version=SSLv3 cipher=OTHER); Thu, 29 Nov 2012 11:27:41 -0800 (PST) References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@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: <866BC125-5820-45A6-A23B-19A0A3CC05DF@gmail.com> X-Mailer: iPad Mail (10A523) From: Brian Dickson Date: Thu, 29 Nov 2012 14:27:38 -0500 To: Christopher Morrow 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: Thu, 29 Nov 2012 19:27:43 -0000 Sent from my iPad On Nov 29, 2012, at 1:19 PM, Christopher Morrow wr= ote: > On Thu, Nov 29, 2012 at 1:01 PM, Tony Li wrote: >>=20 >> On Nov 29, 2012, at 9:50 AM, Jared Mauch wrote: >>=20 >>>> Internet folks will say "Do not trash our environment" >>>=20 >>> As an operator, I feel this is a fair thing for me to say. :) >>=20 >>=20 >> Indeed it is. >>=20 >> However, I think it's also fair to point out that allocating a chunk from= a large namespace and effectively taking out of the big I environment doesn= 't do much to trash it. >=20 > because private asns don't leak? > route-views>sho ip bgp regex _64..._ > > Network Next Hop Metric LocPrf Weight Path > * 27.123.19.0/24 195.66.232.239 0 5459 38082 64= 549 ? > * 41.76.104.0/21 196.7.106.245 0 0 2905 11845 64= 525 i > * 41.90.0.0/16 114.31.199.1 0 0 4826 8966 > 33771 65535 64555 64555 33771 i > * 194.85.40.15 0 3267 2603 > 8966 33771 65535 64555 64555 33771 i > * 41.209.32.0/19 164.128.32.11 0 3303 174 > 9129 9129 9129 9129 {4558,15808,64520} i > * 131.124.1.0/24 69.31.111.244 0 0 4436 4323 647= 78 i > * 131.124.2.0/24 69.31.111.244 0 0 4436 4323 647= 78 i > * 131.124.3.0/24 69.31.111.244 0 0 4436 4323 647= 78 i > * 131.124.4.0/24 69.31.111.244 0 0 4436 4323 647= 78 i > * 131.124.5.0/24 69.31.111.244 0 0 4436 4323 647= 78 i If the "private use" ASNs were NOT from a well-known range, you would detect= this how? This actually does a lot to demonstrate the usefulness of the old range, and= of having a new range larger in size. If 192.168.0.0/16 was the only RFC 1918 space, the value of 10.0.0.0/8 might= not be as clear. The analogy is pretty clear. Not only is there value in more space, there is value in distinct ranges. Having non-globally-unique space that is well known allows third parties to d= etect leaks, filter, and make permanent bogon filters. In case it is not obvious: Support (strongly). The "first amendment" argument analogy holds: it isn't necessary to agree (o= r use in this case) to support the right to speak (use). Brian= From gih@apnic.net Thu Nov 29 11:55: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 5509421F8C2B for ; Thu, 29 Nov 2012 11:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RoGy0APHAvxE for ; Thu, 29 Nov 2012 11:55:33 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90621F8C32 for ; Thu, 29 Nov 2012 11:55:15 -0800 (PST) Received: from 2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net (2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net [IPv6:2001:44b8:1121:1a00:3448:34ba:4195:613f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A5918B6745; Fri, 30 Nov 2012 05:55:13 +1000 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Geoff Huston In-Reply-To: <165A232F-F07C-4AD1-9A08-55A6BD238656@puck.nether.net> Date: Fri, 30 Nov 2012 06:55:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> <165A232F-F07C-4AD1-9A08-55A6BD238656@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1499) 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, 29 Nov 2012 19:55:34 -0000 On 30/11/2012, at 5:29 AM, Jared Mauch wrote: >=20 > On Nov 29, 2012, at 1:21 PM, Geoff Huston wrote: >=20 >> On 30/11/2012, at 3:49 AM, Warren Kumari wrote: >>=20 >>>=20 >>> On Nov 28, 2012, at 10:07 PM, Geoff Huston wrote: >>>=20 >>>>=20 >>>> On 29/11/2012, at 8:26 AM, John Scudder wrote: >>>>=20 >>>>> 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 >>>>=20 >>>> I am opposed to this draft - increasing the size of a unordered = non-unique identifier space is counter-productive. >>>=20 >>> =85 and I support it -- some folk have a need for more than 1023 = "private" ASNs and *really really* don't want to do the "just reuse the = same one and then use something like the 'allows-in' and similar hacks". >>>=20 >>> Yes, going to an RIR and requesting a few thousand global ASes is = possible, but to me seems inelegant. >>=20 >> ??? >=20 > I think the issue he raises here is that to provide uniqueness, one = could ask for real ASNs, but folks may not or be unable to do this. If = they are not used on the big-I Internet, why should they come from that = pool. >=20 I understand that this is a restatement of Warren's point, but you raise = an issue with the registries and the Internet. I can recall the origination of the registry system - it was not only = about the big-I Internet - it was about the allocation of unique code = points to folk who needed to rely upon uniqueness. I'd like to believe that the registry system still works in this way, = and should continue to work in this way. If you need uniqueness then the are registered in the global uniqueness = registry - then the context of use is of no importance - you can use = them in the big-I Internet - you can use them in Geoff's playland or = anywhere else for that matter - they are still unique. Creating more private use space does not address the need for uniqueness = in ASN code points in my view. Geoff From gih@apnic.net Thu Nov 29 12:04: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 313E221F8B8B for ; Thu, 29 Nov 2012 12:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WdHpCPzgo3s3 for ; Thu, 29 Nov 2012 12:04:02 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3149A21F8997 for ; Thu, 29 Nov 2012 12:04:02 -0800 (PST) Received: from 2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net (2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net [IPv6:2001:44b8:1121:1a00:3448:34ba:4195:613f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B8FC4B6745; Fri, 30 Nov 2012 06:03:59 +1000 (EST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: Geoff Huston In-Reply-To: <574CC47E-4BF6-4749-8B44-CFA526ECDFD6@tony.li> Date: Fri, 30 Nov 2012 07:03:58 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <135D3112-A4CB-4B88-AD4A-5A34706566C5@apnic.net> References: <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> <574CC47E-4BF6-4749-8B44-CFA526ECDFD6@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1499) 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, 29 Nov 2012 20:04:03 -0000 On 30/11/2012, at 5:55 AM, Tony Li wrote: >=20 > On Nov 29, 2012, at 10:21 AM, Geoff Huston wrote: >=20 >> But if there is a single need for 100,000 code points in single = coherent space then you have to ask how one could ensure uniqueness = within the deployment space, as you are now talking about a large number = of entities and a large coder point space, and according to your = response, the reason why there is a driving need duplicate an existing = uniqueness framework is because the current framework we have for = ensuring uniqueness of AS number code points is ... "inelegant"? >=20 >=20 > Obviously, the private use ASNs would have local uniqueness and = specified by the local administration. Not a big deal. aaahhh scoped uniqueness I seem to recall an IPv6 scoped address concept along these lines... = thats right ... site local. "Not a big deal"? In V6 this concept of scoped uniqueness with a local administration = caused massive heartache and was dropped. Are we going to repeat this = exercise again and again in different code point spaces? Or are we going = to try and understand some more basic architectural considerations that = are at play here that imply that the imposition of scope as a moderation = of the concept of uniqueness is often an arbitrary affair that = generates way more exceptions and consequent failures than there are = strictly conformant cases. > More to the point, the noise and fluff of administering this is not = something that you want foisted on the RIRs, especially when multiplied = by the number of sites using it. >=20 On the other hand, I believe that the RIR's have been foisted with that = role from day one. > We've seen over and over again that the right way of creating = scalability is to create hierarchy. All this is doing is to continue = its instantiation. I fail to appreciate this logic - creating a larger swamp space of = clashing private use ASN code points hardly seems to me to be consistent = with an objective of underpinning scalable uniqueness in the use of code = points in networking. And yes, I'm still opposed to the progress of this draft from WG Last = Call to the IESG. Geoff From rraszuk@gmail.com Thu Nov 29 12:14: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 ACB4621F8C0F for ; Thu, 29 Nov 2012 12:14:40 -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 S1foxx5HoqAW for ; Thu, 29 Nov 2012 12:14:30 -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 8C41721F8B8F for ; Thu, 29 Nov 2012 12:14:30 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so12169932iaf.31 for ; Thu, 29 Nov 2012 12:14: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=+Dl7CQ+4OFEtyJrELQKY3R26bM29ZM4A81iCoX0Hxls=; b=rUz7W7hgbcZKBA7SuuShWjjx7A9poBKHiflDuGinIkcpg81AUVyzQw3JoyB8wdkp81 D57cPaC/LWFUCCG3Ft/rYE2HTt6958c20Lge0buUbimx/TMJAP58lzytT4UXB3XuoIq+ 5uLhA8/LgRmHuOYbslfZf1wPsGtQNsPi0LDEIeTLi+NrvaqDMiCafaGQ/HmX93uWoBGl Y79wwky/cOhD0JmZtBMOe37ZDw3GasNBGx22oh2YbAmcMaV4M9mJneShj907dt7FmTi5 z7v+9+uQue+ncaCnT9nA+E89qoERhD80lR/iF1myozuMSgZiNOs2s/nUgIIXegm+Djta O61w== MIME-Version: 1.0 Received: by 10.50.170.66 with SMTP id ak2mr26921758igc.38.1354220069917; Thu, 29 Nov 2012 12:14:29 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Thu, 29 Nov 2012 12:14:29 -0800 (PST) In-Reply-To: <135D3112-A4CB-4B88-AD4A-5A34706566C5@apnic.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> Date: Thu, 29 Nov 2012 21:14:29 +0100 X-Google-Sender-Auth: EjVHPfQlDNZLqDvNLGFjZBHCTFU Message-ID: From: Robert Raszuk To: Geoff Huston Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf. org" , 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: Thu, 29 Nov 2012 20:14:40 -0000 Hi Geoff, So let me ask a very simple question in light of Brian's point .. Is it better for someone privately to just pick random 100K of ASes from 4 octet block and apply to his private needs or is it better if such pool is well known ? Who is going to stop Jon or Kevin or Sasha to do the former ? Internet-CIA ??? Cheers, R. From gih@apnic.net Thu Nov 29 12:24: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 EBCB421F8C32 for ; Thu, 29 Nov 2012 12:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1yLWwfMrO6v8 for ; Thu, 29 Nov 2012 12:24:21 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2B21F8C35 for ; Thu, 29 Nov 2012 12:24:17 -0800 (PST) Received: from 2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net (2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net [IPv6:2001:44b8:1121:1a00:3448:34ba:4195:613f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 62AD6B6745; Fri, 30 Nov 2012 06:24:15 +1000 (EST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Geoff Huston In-Reply-To: Date: Fri, 30 Nov 2012 07:24:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4145B9A4-56D2-4DEB-9583-F86F7E73BD77@apnic.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> To: Robert Raszuk X-Mailer: Apple Mail (2.1499) Cc: "idr@ietf. org" , 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: Thu, 29 Nov 2012 20:24:22 -0000 On 30/11/2012, at 7:14 AM, Robert Raszuk wrote: > Hi Geoff, >=20 > So let me ask a very simple question in light of Brian's point .. >=20 > Is it better for someone privately to just pick random 100K of ASes > from 4 octet block and apply to his private needs or is it better if > such pool is well known ? >=20 > Who is going to stop Jon or Kevin or Sasha to do the former ? = Internet-CIA ??? (I love false dichotomies!) Of course when presented with this kind of either/or argument then the obvious answer is "neither". If uniqueness is important then use a registry system that provides uniqueness of assigned/allocated code points.=20 If uniqueness is unimportant then use the same code point, because, = well,=20 uniqueness was not important was it. Did I say already that I was opposed to the progress of this draft from WG Last Call to the IESG?=20 Geoff =20= From rraszuk@gmail.com Thu Nov 29 12:29: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 9F7D021F8C18 for ; Thu, 29 Nov 2012 12:29:05 -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 wNeKGJNDBsfi for ; Thu, 29 Nov 2012 12:29: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 0AA3121F8C14 for ; Thu, 29 Nov 2012 12:29:04 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so16573839ieb.31 for ; Thu, 29 Nov 2012 12:29: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=zccZsV47rcVk+N9tjHgpir+izIUZ0qQkivPOPFUH6M8=; b=fkkOa8lXy4CWtTRq6nzIQYFm2tNFf4KEQmdXrgzIWbOYJRxtsek1lXXz4gqA5gjQj0 GnarC1SwrM96FtkFIEx/NIa169Lh7NNCTVkGxPCJ5l5D6dg2mj6m2ySrAgcmUPab94Y/ GlcFnZPkTY+KuTjr4KjIrgB4MY/YVG+EQxjr5cl/WmWz6bWi4Ps46b+OcJev6SqJQRPt Xp+7gRXH1v4WPxGg1Chjw/ppemwdaEXy+9jcAr16ocElL4HmDgGN+hlzJrlML45JWVMW NescTsP86gWKm/xpByAU/T8W3B5RCf05szd4AzsTsxSIkdKEQLnFDJBCJifowGIOD/FQ 9z+g== MIME-Version: 1.0 Received: by 10.50.57.133 with SMTP id i5mr23822606igq.67.1354220944670; Thu, 29 Nov 2012 12:29:04 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Thu, 29 Nov 2012 12:29:04 -0800 (PST) In-Reply-To: <4145B9A4-56D2-4DEB-9583-F86F7E73BD77@apnic.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> Date: Thu, 29 Nov 2012 21:29:04 +0100 X-Google-Sender-Auth: 3fw4jDZI1ntnMLJnJ7NVN0O2aX4 Message-ID: From: Robert Raszuk To: Geoff Huston Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf. org" , 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: Thu, 29 Nov 2012 20:29:05 -0000 Hi Geoff, It is not about uniqueness or not. It is about uniqueness within a scope .. here scope being private network. If that would not be useful we would not have 2 octet private AS range nor RFC1918 and I think from personal experience that the last two serve very well for what they were designed. Cheers, R. > On Thu, Nov 29, 2012 at 9:24 PM, Geoff Huston wrote: > > On 30/11/2012, at 7:14 AM, Robert Raszuk wrote: > >> Hi Geoff, >> >> So let me ask a very simple question in light of Brian's point .. >> >> Is it better for someone privately to just pick random 100K of ASes >> from 4 octet block and apply to his private needs or is it better if >> such pool is well known ? > >> >> Who is going to stop Jon or Kevin or Sasha to do the former ? Internet-CIA ??? > > > (I love false dichotomies!) > > Of course when presented with this kind of either/or argument then the > obvious answer is "neither". > > If uniqueness is important then use a registry system that provides > uniqueness of assigned/allocated code points. > > If uniqueness is unimportant then use the same code point, because, well, > uniqueness was not important was it. > > Did I say already that I was opposed to the progress of this draft from > WG Last Call to the IESG? > > Geoff > From jgs@juniper.net Thu Nov 29 12:34: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 EA4AD21F8C12 for ; Thu, 29 Nov 2012 12:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 EpLzN165v4C0 for ; Thu, 29 Nov 2012 12:34:32 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6397521F8C11 for ; Thu, 29 Nov 2012 12:34:32 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKULfG18kjnZkpKVmrBUG2cN2TkUpjIXII@postini.com; Thu, 29 Nov 2012 12:34:32 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, 29 Nov 2012 12:32:47 -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; Thu, 29 Nov 2012 12:32:47 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 29 Nov 2012 12:35:29 -0800 Received: from mail41-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Nov 2012 20:32:45 +0000 Received: from mail41-va3 (localhost [127.0.0.1]) by mail41-va3-R.bigfish.com (Postfix) with ESMTP id 626B53C02AC for ; Thu, 29 Nov 2012 20:32:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 1 X-BigFish: PS1(zz98dI9371Izz1de0h1202h1d1ah1d2ah1082kzz8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1155h) Received: from mail41-va3 (localhost.localdomain [127.0.0.1]) by mail41-va3 (MessageSwitch) id 1354221163196322_17768; Thu, 29 Nov 2012 20:32:43 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.235]) by mail41-va3.bigfish.com (Postfix) with ESMTP id 137676015F; Thu, 29 Nov 2012 20:32:43 +0000 (UTC) Received: from BN1PRD0512HT003.namprd05.prod.outlook.com (132.245.2.21) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Nov 2012 20:32:37 +0000 Received: from rakeshc-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 29 Nov 2012 20:32:36 +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: <4145B9A4-56D2-4DEB-9583-F86F7E73BD77@apnic.net> Date: Thu, 29 Nov 2012 15:32:32 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <09EBCED0-1234-4291-B03D-7BE68C572E48@juniper.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: Geoff Huston 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%TONY.LI$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%APNIC.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RASZUK.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "idr@ietf. org" , 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: Thu, 29 Nov 2012 20:34:34 -0000 On Nov 29, 2012, at 3:24 PM, Geoff Huston wrote: > If uniqueness is important then use a registry system that provides > uniqueness of assigned/allocated code points.=20 Uniqueness within a scope is important. Speaking of false dichotomies, = you seem to be suggesting that the only way to have uniqueness is by RIR = allocation. This is of course not the case, any (ahem) well-run = enterprise can manage their own number resources internally. Global uniqueness helps when you merge scopes, but that's a = well-understood issue. > If uniqueness is unimportant then use the same code point, because, = well,=20 > uniqueness was not important was it. Do you think we should revise RFC 1930 to withdraw the existing private = AS space? > Did I say already that I was opposed to the progress of this draft = from > WG Last Call to the IESG?=20 You did. Duly noted. It would be fine with me to take that part as read = from now on. --John= From randy@psg.com Thu Nov 29 14:55: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 6B36D21F8AD5 for ; Thu, 29 Nov 2012 14:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 hUS1T5UrXxSi for ; Thu, 29 Nov 2012 14:55:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F121F8AD6 for ; Thu, 29 Nov 2012 14:54: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 1TeCzz-000CZb-Au; Thu, 29 Nov 2012 22:54:27 +0000 Date: Fri, 30 Nov 2012 07:54:26 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: <09EBCED0-1234-4291-B03D-7BE68C572E48@juniper.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> <09EBCED0-1234-4291-B03D-7BE68C572E48@juniper.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, 29 Nov 2012 22:55:28 -0000 > Global uniqueness helps when you merge scopes, but that's a well- > understood issue. well-understood, mostly. a major charlie foxtrot in many real world mergers (business or technical). we've seen this over and over again in users of rfc1918 space. and the kludges to 2547 vpns to accommodate duplicated address space are not pleasant. randy From jgs@juniper.net Thu Nov 29 16:36: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 B40FF21F8AB2 for ; Thu, 29 Nov 2012 16:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=0.500, 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 0eUTEMCXt9PY for ; Thu, 29 Nov 2012 16:36:49 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1454521F8966 for ; Thu, 29 Nov 2012 16:36:49 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKULf/oLSD6AvcDRvsZ4v7/rhUzbcS0zsd@postini.com; Thu, 29 Nov 2012 16:36:49 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Nov 2012 16:32:22 -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; Thu, 29 Nov 2012 16:32:21 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 29 Nov 2012 16:35:04 -0800 Received: from mail137-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 30 Nov 2012 00:32:21 +0000 Received: from mail137-ch1 (localhost [127.0.0.1]) by mail137-ch1-R.bigfish.com (Postfix) with ESMTP id 04163400128 for ; Fri, 30 Nov 2012 00:32:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz4015Izz1de0h1202h1d1ah1d2ah1082kzz1033IL17326ah8275dh17598diz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1155h) Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1 (MessageSwitch) id 1354235538914809_16165; Fri, 30 Nov 2012 00:32:18 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail137-ch1.bigfish.com (Postfix) with ESMTP id CFA634A0043 for ; Fri, 30 Nov 2012 00:32:18 +0000 (UTC) Received: from BN1PRD0512HT003.namprd05.prod.outlook.com (132.245.2.21) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 30 Nov 2012 00:32:18 +0000 Received: from rakeshc-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 30 Nov 2012 00:32:17 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <31E256D9-95E6-422E-8C7A-06542DDB227F@juniper.net> Date: Thu, 29 Nov 2012 19:32:13 -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] IETF-85 minutes posted X-BeenThere: idr@ietf.org X-Mailman-Version: 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, 30 Nov 2012 00:36:49 -0000 Minutes from our last meeting are at = http://www.ietf.org/proceedings/85/minutes/minutes-85-idr Please send any corrections. Thanks, --John= From christopher.morrow@gmail.com Thu Nov 29 20:37: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 0573321E8039 for ; Thu, 29 Nov 2012 20:37:57 -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 zlemS+bn41W8 for ; Thu, 29 Nov 2012 20:37: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 0C32121E8037 for ; Thu, 29 Nov 2012 20:37:55 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so32985eek.31 for ; Thu, 29 Nov 2012 20:37:54 -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=NLW8tD2f9c5iR6Y1jTRUOEOtVD4xkRnGVcST74VB8m4=; b=vsNtPxnrNtMSGo4sE2WfAZeRzS1x+5QL37n1OpQ3yoWN8kZyAW3R5Zm6pBEVp+b3vU owH7Z7epSj7aGM3igfuQ356NCWhvvwdRMgMNSLXPKddQSnNBALp15eobmHfV9Lm8L0Gk 8Ve0XlDRTN0tHpNAOowvfjBnqsgvYJFhtm4TAuOO8R/8ceVIv1OBthV+CDbw5FiATD5R 4fmABsv5nO6dmmhpx2FO/NccTTgTUnLNrThbrLMmKks5dQReHC9+xwZeN5u4w9asIyvT 16LFPyFIEyZ977DF+A8XEt5MpuhJjqt16/728bsWCP72WnEXrATrzufDzRhL+ed81F/C pq7A== MIME-Version: 1.0 Received: by 10.14.194.4 with SMTP id l4mr40984267een.42.1354250274629; Thu, 29 Nov 2012 20:37:54 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.96.5 with HTTP; Thu, 29 Nov 2012 20:37:54 -0800 (PST) In-Reply-To: <20121129191043.GA9189@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> Date: Thu, 29 Nov 2012 23:37:54 -0500 X-Google-Sender-Auth: LeNKRG1USaUZiKkPZ46q-oxkrQc Message-ID: From: Christopher Morrow To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 30 Nov 2012 04:37:57 -0000 On Thu, Nov 29, 2012 at 2:10 PM, Jon Mitchell wrote: > > As I've stated before, mis-configuration or improper use of private use > ASNs doesn't seem to be highly correlated to the size of the range. If agreed. > this were an issue, I guess, we would expect that a network would be > leaking close to 1K ASNs today that then would expand to many thousands > or millions after the draft is approved? > > 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 save the one-time (maybe) change to as-path filters, sure. (not that that's really an issue) > internal use ASNs today are not likely to use this new range. > > Jon > > On Thu, Nov 29, 2012 at 01:19:30PM -0500, Christopher Morrow wrote: >> On Thu, Nov 29, 2012 at 1:01 PM, Tony Li wrote: >> > >> > On Nov 29, 2012, at 9:50 AM, Jared Mauch wrote: >> > >> >>> Internet folks will say "Do not trash our environment" >> >> >> >> As an operator, I feel this is a fair thing for me to say. :) >> > >> > >> > Indeed it is. >> > >> > However, I think it's also fair to point out that allocating a chunk from a large namespace and effectively taking out of the big I environment doesn't do much to trash it. >> > >> >> because private asns don't leak? >> route-views>sho ip bgp regex _64..._ >> >> Network Next Hop Metric LocPrf Weight Path >> * 27.123.19.0/24 195.66.232.239 0 5459 38082 64549 ? >> * 41.76.104.0/21 196.7.106.245 0 0 2905 11845 64525 i >> * 41.90.0.0/16 114.31.199.1 0 0 4826 8966 >> 33771 65535 64555 64555 33771 i >> * 194.85.40.15 0 3267 2603 >> 8966 33771 65535 64555 64555 33771 i >> * 41.209.32.0/19 164.128.32.11 0 3303 174 >> 9129 9129 9129 9129 {4558,15808,64520} i >> * 131.124.1.0/24 69.31.111.244 0 0 4436 4323 64778 i >> * 131.124.2.0/24 69.31.111.244 0 0 4436 4323 64778 i >> * 131.124.3.0/24 69.31.111.244 0 0 4436 4323 64778 i >> * 131.124.4.0/24 69.31.111.244 0 0 4436 4323 64778 i >> * 131.124.5.0/24 69.31.111.244 0 0 4436 4323 64778 i >> >> (hi twtc! filter-customer-much?) >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Thu Nov 29 20: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 D4C7721F8456 for ; Thu, 29 Nov 2012 20:46:28 -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 eRFUwmM0sRzq for ; Thu, 29 Nov 2012 20:46:28 -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 28A1C21F8453 for ; Thu, 29 Nov 2012 20:46:28 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so35300eek.31 for ; Thu, 29 Nov 2012 20:46:27 -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=dyzVJsppOEwsWdrWgJAHFAdDjeRt/xn3E8LTZaRd5Ek=; b=0cgcRLNcujSP7iTQd3MUvJviF341vFu+VEmWps+3QWlKN3s7I2rSttHIZBPiXIfOi9 erpxUkAkmtas+eDvdiaYzuYnc7O73XQm+HEvfu55+URYmmTFkGcpNu7cwGqeFmgbYMKw xqNRnC0HMb8dRrgEc9Jx7BDFT7tK+xsdTuvhyHhDefsSM8Lajmv6TyuFp6x8/fI1V5Pu yUqB3Yfr5OQ/Ln38rNkWy8GbAS+OZglo7UPJvTCzuK1lWACJUm7OhXlzqC8CZADcOyNK FRWytacogF/kr8RIDQQxz75lYxK9Xd0m8sdEZ9S9rnDjyJ2HGur4GH3rki2wOQYLDymx NBLA== MIME-Version: 1.0 Received: by 10.14.211.135 with SMTP id w7mr332124eeo.4.1354250787381; Thu, 29 Nov 2012 20:46:27 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.96.5 with HTTP; Thu, 29 Nov 2012 20:46:27 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Date: Thu, 29 Nov 2012 23:46:27 -0500 X-Google-Sender-Auth: FcA5MBHOCBMksQvfqyl9AIeWHi8 Message-ID: From: Christopher Morrow To: Robert Raszuk 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: Fri, 30 Nov 2012 04:46:28 -0000 On Thu, Nov 29, 2012 at 2:22 PM, Robert Raszuk wrote: > Chris, > > So what is exactly the concern here ? The fact that folks are trying > to reserve large pool of AS numbers for their own use or that folks > are afraid that this will be used in AFI/SAFI 1/1 and/or 2/1 and will > end up visible in the Internet ? my original issue, which I think jon actually does capture in his draft, is that there are exceptions in code today for 'special asn blocks', and testing/config-options/etc that goes along with that... Adding another 'special asn block' is piling onto an already not super idea, and extending the need for better testing/config-management/etc. I'm not sure the complexity is helpful. It's not clear to me that adding more private-asn space is helpful to the larger user base of BGP either. (should we be fixing corner cases for implementors?) -chris From christopher.morrow@gmail.com Thu Nov 29 20:54: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 3F95E21E803A for ; Thu, 29 Nov 2012 20:54:22 -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 N7d6xrbaUSpG for ; Thu, 29 Nov 2012 20:54:21 -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 2547221E8039 for ; Thu, 29 Nov 2012 20:54:20 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so39091eaa.31 for ; Thu, 29 Nov 2012 20:54: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=nvqFvuAxG02B+UhlO0y911VpJ6QaUMwdvLZmYanKZU4=; b=mmg/sjuvOxIxcWbozz/GewqmDMV19VAfrzJyYNzaJhMRXpE0uN3zXpwj2csdWylhAF t/os48+gk5SNmToL4B0RtkfJCcIfjWsLF/MMDapnvyiYqb81OBunFD5JrntjHlAV2ebQ 5xE5HI2cru+wIDWks33/oCi7+EtgqvUWOfCX002OaUqOEnXxO2cnbu73gKBDcfsWB5v4 8CW4KMNYPYyRe98oiJ8P+szEgCeKpHSvdAHu0aVJW8E6i+BRefHgPyOMa8nXZJ+WEgLG ff11Bw+7hztUcng4l+dK+vtwHTXxDUT7f+KljTCzg3bK6n4z08uKAxX5F0iP7n+NH/DG pfZA== MIME-Version: 1.0 Received: by 10.14.209.193 with SMTP id s41mr348438eeo.9.1354251260043; Thu, 29 Nov 2012 20:54:20 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.96.5 with HTTP; Thu, 29 Nov 2012 20:54:19 -0800 (PST) In-Reply-To: <866BC125-5820-45A6-A23B-19A0A3CC05DF@gmail.com> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <866BC125-5820-45A6-A23B-19A0A3CC05DF@gmail.com> Date: Thu, 29 Nov 2012 23:54:19 -0500 X-Google-Sender-Auth: 2GJPN1JC1bj7v4mdvDW4Aut7arM Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 30 Nov 2012 04:54:22 -0000 On Thu, Nov 29, 2012 at 2:27 PM, Brian Dickson wrote: > If the "private use" ASNs were NOT from a well-known range, you would detect this how? some other macro of integers perhaps? > > This actually does a lot to demonstrate the usefulness of the old range, and of having a new range larger in size. how does it help show a larger size range would be helpful? > > If 192.168.0.0/16 was the only RFC 1918 space, the value of 10.0.0.0/8 might not be as clear. > The analogy is pretty clear. > expand pls. > Not only is there value in more space, there is value in distinct ranges. a distinct range is of value, sure. how are more ranges helpful though? > Having non-globally-unique space that is well known allows third parties to detect leaks, filter, and make permanent bogon filters. > you mean it makes people carry crufty config for exceptions forever... sure. it also does show some obvious routing problems to the world, or does it? maybe it's not a routing problem but a 'forgot to cut/paste/replace my ASN for my customer ASN' ? it's not clear at all from the data on the wire, except that the reaction to: "I see 65535 in an as-path" is "that is bad". if I see: 198.41.0.0/24 as-path: 1 2 3 26415 65534 is that a leak or a missed configuration on a 26415 device? (forgot to put remove-private-asn on the upstream neighbor to 3). > In case it is not obvious: > > Support (strongly). mostly I'm ambivalent at this point. I'm not really in favor of adding more complexity here, especially when there is a regular remedy: "Hi ARIN, I need 300 asns for my next 300 deployments, all which are scheduled to happen in the next Y days, all of which have a unique routing policy." -chris From randy@psg.com Thu Nov 29 21:55: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 37E3121F893A for ; Thu, 29 Nov 2012 21:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 xlshDXulv7yb for ; Thu, 29 Nov 2012 21:55:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D041B21F88CF for ; Thu, 29 Nov 2012 21:55:40 -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 1TeJZb-000Gaq-JE; Fri, 30 Nov 2012 05:55:39 +0000 Date: Fri, 30 Nov 2012 14:55:37 +0900 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <866BC125-5820-45A6-A23B-19A0A3CC05DF@gmail.com> 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: Fri, 30 Nov 2012 05:55:41 -0000 > Having non-globally-unique space that is well known allows third > parties to detect leaks, filter, and make permanent bogon filters. boy have we not done well with that one. large projects and large costs to clean up 'permanent bogon filters'. randy From rraszuk@gmail.com Fri Nov 30 00:58: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 B146921F869A for ; Fri, 30 Nov 2012 00:58:31 -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 62taQGbYSd-V for ; Fri, 30 Nov 2012 00:58:31 -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 1414D21F84DC for ; Fri, 30 Nov 2012 00:58:31 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so215590iaz.31 for ; Fri, 30 Nov 2012 00:58: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=TmGGpXPc6YgNgf6GPau9u35LADlWWyaTLhLJgntYYZg=; b=dyEHNkSky6fBOyrg7QKtBJQgTI0LpUIMs0JoZSyNQfN58UH/PDT7fFTrKd/58SbESi RoJougqQabLrbr0cHBdkVLywO1W9YB/ZIgVSZQy3fIEsVl28fGR0Jj2uGylblRgOBDup 7SfySv46OoCOfohLhX10FKvszQtYJQUg3Ew2hxRd0fEs5PO+ZDN87f/tWyYsULvKBTgA hj0ZLQA7BpyZ59/TxdwgmTTrP0r1d2KONVb5XsTI6SqntqcbMzhCO4DKQLD09Dw0drTw GfHUYYO69TdM5oVzC3RQVIOpx5h6b5wxEGWeoT/Asoz/nsjDhiZuFDiEPnXB6+zWiTG2 npiA== MIME-Version: 1.0 Received: by 10.50.94.166 with SMTP id dd6mr434806igb.38.1354265910613; Fri, 30 Nov 2012 00:58:30 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.135.100 with HTTP; Fri, 30 Nov 2012 00:58:30 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Date: Fri, 30 Nov 2012 09:58:30 +0100 X-Google-Sender-Auth: 7KBoV3cGBIoAkkj-pQbJ8gh-iCM Message-ID: From: Robert Raszuk To: Christopher Morrow 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: Fri, 30 Nov 2012 08:58:31 -0000 Hello Chris, > I'm not sure the complexity is helpful. I am somehow puzzled on your "adding complexity to BGP implementation" issue reg this draft. MP-BGP extension opened a autobahn for making BGP implementations more complex. Number of existing BGP extensions and new ones coming soon do have huge impact to BGP implementations. Are you proposing to freeze BGP now and not allow any new extensions ? 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. Best, R. On Fri, Nov 30, 2012 at 5:46 AM, Christopher Morrow wrote: > On Thu, Nov 29, 2012 at 2:22 PM, Robert Raszuk wrote: >> Chris, >> >> So what is exactly the concern here ? The fact that folks are trying >> to reserve large pool of AS numbers for their own use or that folks >> are afraid that this will be used in AFI/SAFI 1/1 and/or 2/1 and will >> end up visible in the Internet ? > > my original issue, which I think jon actually does capture in his > draft, is that there are exceptions in code today for 'special asn > blocks', and testing/config-options/etc that goes along with that... > Adding another 'special asn block' is piling onto an already not super > idea, and extending the need for better testing/config-management/etc. > > I'm not sure the complexity is helpful. It's not clear to me that > adding more private-asn space is helpful to the larger user base of > BGP either. (should we be fixing corner cases for implementors?) > > -chris From christopher.morrow@gmail.com Fri Nov 30 07:36: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 A9DE121F8551 for ; Fri, 30 Nov 2012 07:36:37 -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 1nFJIwdWlvpk for ; Fri, 30 Nov 2012 07:36:37 -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 0227421F8557 for ; Fri, 30 Nov 2012 07:36:36 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so428850eek.31 for ; Fri, 30 Nov 2012 07:36: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=Rmc4NI413OnFiMqDIdZ3bn90Gn8ssTY8upsV69fo8ts=; b=l+c7tN/2K2z8vDz25Xsy8520vz+PcOVCraA5Wtzf7aHzsPQau5oox9HmP4UXqAOLa5 OQ5QuVLm68FB1B+cTIg7r3Pf3qNn3YY+dZmJYzb6MdFzlFW72PqF2wjMZ26YePvizs/f D7vSTOhwNBSvPvOrscuB6P909Bg6EWHXCfe8unTgJuj/D+Y4JGW1IuiuDrrhoAMwFtGl OxISTsAYIsXIBkFTK+EihQXvsfq0JE58J9im3vOj9MFJpqLXRDLVzRFudxoU2/wCaK10 d9xHcgwMKB9kkwJaq0L6n7N/6MDAdS3H7X+hS9SWmop1ohFybeWJlyBTrSJ7y58YgORq Vvfw== MIME-Version: 1.0 Received: by 10.14.194.4 with SMTP id l4mr5628051een.42.1354289796180; Fri, 30 Nov 2012 07:36:36 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.96.5 with HTTP; Fri, 30 Nov 2012 07:36:35 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> Date: Fri, 30 Nov 2012 10:36:35 -0500 X-Google-Sender-Auth: 9iztF2aQ8cXCr8s3FnxBD4CFbIU Message-ID: From: Christopher Morrow To: Robert Raszuk 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: Fri, 30 Nov 2012 15:36:37 -0000 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. by all means, once the floodgates are open, why not drive the valdez through the shoals. From tony.li@tony.li Fri Nov 30 07:53: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 81B4F21F8B54 for ; Fri, 30 Nov 2012 07: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 omJaiDHThmsJ for ; Fri, 30 Nov 2012 07:53:07 -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 8A98D21F8B48 for ; Fri, 30 Nov 2012 07:52:53 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id VqBZ1k00G1wfjNsA1rst2V; Fri, 30 Nov 2012 15:52:53 +0000 Received: from sjc-vpn7-1354.cisco.com ([128.107.239.233]) by omta23.emeryville.ca.mail.comcast.net with comcast id Vrqd1k00g52qHCY8jrqgog; Fri, 30 Nov 2012 15:50:51 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Fri, 30 Nov 2012 07:50:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354290773; bh=o1Ean2+CupMh/qL0IbGeBbUk0yqRCxugdZ68hVxhR74=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=pUBXZAaipXe8QiV3ejAzyg02PHUAGYIBFDPs3y1jpX8ztrR8ocdCwnCNCMsXp5iAF 4c60cNbqVnkW9lz/VMeknzN3tKmQobQ8zDoUH+8EF0n0QMFzfHZE8s2NMOffAAK8h4 p+PRYhQqNo3LJG3IOTgcYG9piRPzdosokS/p1ETSRnd5XAY/HN1YSgNmcc4ZFW2bmq OLLsN9qwm4XBKI/wuYaJCWzTc1DJFWlyHUB7B7p2EM88QqW13UY8pDzNazyuXB1xVA wvwAvy6OMf+aWs7adD6ZZpiJSoVpq7R09PALWIRzvRAN1XfZakbEKZsMc8Ml2dzOIq eT4M8pvYsVdlQ== 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: Fri, 30 Nov 2012 15:53:12 -0000 On Nov 30, 2012, at 7:36 AM, Christopher Morrow = wrote: > 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. Come now. This is not a reasonable comparison in so many ways. The = floodgates are not open and this hardly a large issue. The exception is already in the code for one range. The issue here is = simply adding another range. There is ample demand for doing this, it's simply not represented by the = SP community. Thus, I suspect that the code will change for commercial = reasons alone. The remaining question is whether you want it = standardized or not. Tony From christopher.morrow@gmail.com Fri Nov 30 08:07: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 5FD9C21F8909 for ; Fri, 30 Nov 2012 08:07:09 -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 NUda5k6t3MY1 for ; Fri, 30 Nov 2012 08:07:08 -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 1951621F86DB for ; Fri, 30 Nov 2012 08:07:07 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so450811eek.31 for ; Fri, 30 Nov 2012 08:07: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=ghhofsZxCfgciyHMm3o/pSxxyY7qTkg2NYSqLjHPmn4=; b=zkoNueXxTzJ6H1ix7e9JFDQfQGixSlTtuio/ir9ysneiOFMHHXlwrrFk+Rt971I8b+ oI1XzUdPxK3wXXiX+CkyjyfOXcWIx+cVHGdNSbHkoAPLW+DSVPGZtGSlLZVqGMlRin3J Sv/+JDFsn/gjRqSh7CBJOKGZL6a92BUBvaCM8DrstC/wMWtP0vJ+cZcxOCeXx2J2J1Mu oImILT6y2C0G+P1brppi/n8bECDLB4NHi4t7YZPdCFsFX0l/Uo5dDy0WmpFfsJH4Ir2G G+1ovG3BODvI/TP65fl5eI5HkzaEzvoE62euY2hAqDQGIi/7llzW9RiErnMGV1nybrtf /9Iw== MIME-Version: 1.0 Received: by 10.14.172.195 with SMTP id t43mr6114558eel.17.1354291625996; Fri, 30 Nov 2012 08:07:05 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.96.5 with HTTP; Fri, 30 Nov 2012 08:07:05 -0800 (PST) In-Reply-To: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@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> Date: Fri, 30 Nov 2012 11:07:05 -0500 X-Google-Sender-Auth: a5R9g-HL2MinMa9jL6_6qg2v0Ko Message-ID: From: Christopher Morrow To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 30 Nov 2012 16:07:09 -0000 On Fri, Nov 30, 2012 at 10:50 AM, Tony Li wrote: > The remaining question is whether you want it standardized or not. if it's to be done, it should be standardized, of course. and my vote is but one of many... if there's enough call (consensus) then it's fine that it proceeds. (I believe my work-colleagues are supporters of this proposal as well, it'd be nice for ed at least to speak up if he's listening) -chris From chandra.appanna@yahoo.com Fri Nov 30 09:34: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 442C421F8B25 for ; Fri, 30 Nov 2012 09:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 A+B3TAInNK28 for ; Fri, 30 Nov 2012 09:34:38 -0800 (PST) Received: from nm17-vm0.bullet.mail.bf1.yahoo.com (nm17-vm0.bullet.mail.bf1.yahoo.com [98.139.213.157]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60121F85A9 for ; Fri, 30 Nov 2012 09:34:38 -0800 (PST) Received: from [98.139.215.140] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 30 Nov 2012 17:34:38 -0000 Received: from [98.139.212.251] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 30 Nov 2012 17:34:37 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 30 Nov 2012 17:34:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 741255.92232.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 9810 invoked by uid 60001); 30 Nov 2012 17:34:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354296877; bh=YY2VtQlBWom1cO8IopcXDs5BLakK/q+4KdhUOgVO0rg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TaYVgKcb4jRYGaPeWG/90s3Pe4Ev9+e9VVJzw18nKpso/ahlFV2MbfEtpk+NX7TUUwSMgwI5CGcHAMELK92imVfArB+LkrrCCj9ufwL4LNEiZgVjIUPdALUihI2mGF+M9iAgF3Vqu0ACaYmHtWBogjMqDo2YPJvpwXAyUUBj0Fk= 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:In-Reply-To:MIME-Version:Content-Type; b=PCwg9zwi9pq978lJUd3w4XHaCMNX0lf5GE300AMXz+EmPFJxZyd2fLPOWxtRbOFSvTgFL1Un1lEIs2NFTrlFNlv9eZDFB7/+oG6kgbW2hSaA9LuyfmGAaP01QaBiJt742uuFI6d+TR/vPJQrmyt9vUuEDm5FPef/7nhtREg843o=; X-YMail-OSG: F6TK.R8VM1mR5zNVa16Zy8vZrMGTDFEypr6F78z5cMqcbCo 6VCrpq0CG_WmvQHzA9POs8HVkArV6eaknEyyA3S8l.DhBRpGki2EYkkhgp6_ MI7tnElxpyhkfu1YnCsQrIOWV1MrzHWRc3pseX5z0bI2FyJ8sOUJThO4nLkU r._6gLTDSXZtNn1gGytff5zeLT87.qsGpFP1SYXC9zuLO21BxVXOud.0hwE8 XNZJgj4qiEZSCdK9TVhQdx71wlIm1pkmGoqVuRyJU6Ka7wmvQ3S8cen3al7r pqxgpRtMCXX14FNb.1gZmmYOBm1aHzgv4VA4h7fuIdzia_zRRWUWQEjufu8p 5Jva3n6qKYTfCe9ZEb0xz2Ic9v_zdf7aMj0TY5gxKhDe2kvMPGnN2OrFU1py iQxGGYnTqSnTERGr4EnSUPpN9U_LoRaPOKg7QjbPTJxnvD5aa3wwCkB70I3p eBDrHlt2o6nXVGCixCIULRottRRYe79LVl4rC.Cw_0NLsYd4Z4OTyewfZE7D Gt2ua65pND1Fw3BbwC7EBe1LueQ4bwhhoZFXA5oCaNQOq9ARYqzJPVVY4Iqt s5RS.LTcIfrDOGg2uxxhesHOf_Wj61Q-- Received: from [4.53.128.218] by web162902.mail.bf1.yahoo.com via HTTP; Fri, 30 Nov 2012 09:34:37 PST X-Rocket-MIMEInfo: 001.001, RXNwIHNpbmNlIHRoaXMgaGFzIGdlbmVyYXRlZCBzbyBtdWNoIGRpc2N1c3Npb24sIEkgZmlndXJlCnRoZSBjaGFpcnMgbWlnaHQgd2FudCB0byBoZWFyIGZyb20gc29tZSBvZiB1cyB3aG8gYXJlIHJlYWRpbmcKYnV0IHNpbGVudCBzbyBmYXIuLgoKU3VwcG9ydC4KCkNoYW5kcmEuCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKb2huIFNjdWRkZXIgPGpnc0BqdW5pcGVyLm5ldD4KVG86ICJpZHJAaWV0Zi4gb3JnIiA8aWRyQGlldGYub3JnPiAKU2VudDogV2VkbmVzZGF5LCBOb3YBMAEBAQE- X-Mailer: YahooMailWebService/0.8.128.478 References: Message-ID: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> Date: Fri, 30 Nov 2012 09:34:37 -0800 (PST) From: Chandra Appanna To: John Scudder , "idr@ietf. org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1114306876-750799214-1354296877=:9381" 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: Fri, 30 Nov 2012 17:34:39 -0000 --1114306876-750799214-1354296877=:9381 Content-Type: text/plain; charset=us-ascii Esp since this has generated so much discussion, I figure the chairs might want to hear from some of us who are reading but silent so far.. Support. Chandra. ________________________________ From: John Scudder To: "idr@ietf. org" Sent: Wednesday, November 28, 2012 1:26 PM Subject: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 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 --1114306876-750799214-1354296877=:9381 Content-Type: text/html; charset=us-ascii
Esp since this has generated so much discussion, I figure
the chairs might want to hear from some of us who are reading
but silent so far..

Support.

Chandra.

From: John Scudder <jgs@juniper.net>
To: "idr@ietf. org" <idr@ietf.org>
Sent: Wednesday, November 28, 2012 1:26 PM
Subject: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

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


--1114306876-750799214-1354296877=:9381-- From willramses2@gmail.com Fri Nov 30 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 9A0CC21F89A1 for ; Fri, 30 Nov 2012 10:41:39 -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 F15V-ElE-hJz for ; Fri, 30 Nov 2012 10:41:39 -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 6BC7821F89A9 for ; Fri, 30 Nov 2012 10:41:38 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so853668oag.31 for ; Fri, 30 Nov 2012 10:41:38 -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 :content-type; bh=bS5KoLISOfgH6FMoAd1CaBdh8hPPtv6SSGehaE+xIvQ=; b=JcRn96JLdykEU8l6jLgSvBaSpRVIwkvc2zbMmslCOd69/d8OSHms9zNNNXaKLv67n5 Squ+ZT9+ZYq2rAe1DAYmFdD48LvX2J05u1s/biMsgv/EEqRtkud7ras7PSY+a7VjvVr+ yOCS6AvMzUBtAOoFAf9eKI4fRXH0ICF/8aj7E1SAH1NqlJLUkOK4QiDSwhCI+wdmLARc 7z5gBJTiyYvXARyyuR029H6U745yk0Si8AJn3eCOxFbIKhc3ni+90lM1uP5H4eqqY3QO hAy6M9DS/w+0WliTtDWU3IKG6NpPxf/If/m5Q+GjNf8lGEvbK5bIJE9fWxL6hZBW4kW2 ywjQ== MIME-Version: 1.0 Received: by 10.60.169.234 with SMTP id ah10mr1827310oec.12.1354300898051; Fri, 30 Nov 2012 10:41:38 -0800 (PST) Received: by 10.76.69.138 with HTTP; Fri, 30 Nov 2012 10:41:37 -0800 (PST) In-Reply-To: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> References: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> Date: Fri, 30 Nov 2012 10:41:37 -0800 Message-ID: From: Will White To: "idr@ietf. org" Content-Type: multipart/alternative; boundary=bcaec54d4d8ef287be04cfbabfdc 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, 30 Nov 2012 18:41:39 -0000 --bcaec54d4d8ef287be04cfbabfdc Content-Type: text/plain; charset=ISO-8859-1 Support --Will On Fri, Nov 30, 2012 at 9:34 AM, Chandra Appanna wrote: > Esp since this has generated so much discussion, I figure > the chairs might want to hear from some of us who are reading > but silent so far.. > > Support. > > Chandra. > > ------------------------------ > *From:* John Scudder > *To:* "idr@ietf. org" > *Sent:* Wednesday, November 28, 2012 1:26 PM > *Subject:* [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > 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 > > --bcaec54d4d8ef287be04cfbabfdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support


--Will



On Fri, Nov 30, 201= 2 at 9:34 AM, Chandra Appanna <chandra.appanna@yahoo.com> wrote:
Esp since this has gener= ated so much discussion, I figure
the chairs might want to hear from some of us who are reading
but silent= so far..

Support.

Chandra.

From: John Scudder <jgs@juniper.net>
To: "idr@ietf. org&quo= t; <idr@ietf.org&g= t;
Sent: Wednesday, Nov= ember 28, 2012 1:26 PM
Subject: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

Folks,

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

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

Thanks,

--John

[*] Unless the world ends on Dece= mber 12, in which case send them by December 12.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://ww= w.ietf.org/mailman/listinfo/idr



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


--bcaec54d4d8ef287be04cfbabfdc-- From jgs@juniper.net Fri Nov 30 11:25: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 BC2C921F8B04 for ; Fri, 30 Nov 2012 11:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.333, 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 m4NmP7dT0GaJ for ; Fri, 30 Nov 2012 11:25:06 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 26F4E21F89A7 for ; Fri, 30 Nov 2012 11:25:06 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKULkIETnnlBp0CT+2V+/6wHOALohYOcJ8@postini.com; Fri, 30 Nov 2012 11:25:06 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; Fri, 30 Nov 2012 11:23:03 -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, 30 Nov 2012 11:23:03 -0800 Received: from TX2EHSOBE010.bigfish.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Nov 2012 11:25:43 -0800 Received: from mail13-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 30 Nov 2012 19:23:02 +0000 Received: from mail13-tx2 (localhost [127.0.0.1]) by mail13-tx2-R.bigfish.com (Postfix) with ESMTP id F1C7120010F for ; Fri, 30 Nov 2012 19:23:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zz98dI9371I148cIzz1de0h1202h1d1ah1d2ah1082kzz8275bhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1155h) Received: from mail13-tx2 (localhost.localdomain [127.0.0.1]) by mail13-tx2 (MessageSwitch) id 1354303380524947_15769; Fri, 30 Nov 2012 19:23:00 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.253]) by mail13-tx2.bigfish.com (Postfix) with ESMTP id 77FC72400A2; Fri, 30 Nov 2012 19:23:00 +0000 (UTC) Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 30 Nov 2012 19:22:59 +0000 Received: from vmynam-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.193.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 30 Nov 2012 19:22:58 +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: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> Date: Fri, 30 Nov 2012 14:22:54 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1354296877.9381.YahooMailNeo@web162902.mail.bf1.yahoo.com> To: Chandra Appanna , "idr@ietf. org" 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%YAHOO.COM$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, 30 Nov 2012 19:25:06 -0000 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= From brian.peter.dickson@gmail.com Fri Nov 30 12:15: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 E595B21F8688 for ; Fri, 30 Nov 2012 12:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HMyf25S228cl for ; Fri, 30 Nov 2012 12:15:05 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9F21F8678 for ; Fri, 30 Nov 2012 12:15:05 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so427882bku.31 for ; Fri, 30 Nov 2012 12:15:04 -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=OqbJ2UzXNLUzvDxqSIfRoVBELnJFDiv5n3YwJmUgIJs=; b=qjJ98eUNJOc0DBym1lJapoxIEc5iNt/TiR4x9P6GFY+VK+unAo0PrcyBCW7fRV3SAI lW0AonAKRb3wkX0HUemo5OhsN3KENEL40ywdaoM9XcPxNSYQ/86KOfkjWwNAtxyo3QLA 9U5bl0kp+D6AxHp+O0hXUYKaJmPBg0fmsBXYukU4cbmzKfDaXvWCtEMFnotgyW13LeJG 3N6bE/LQ/AusNLLIjfSwOrYTwdkSKdvct4pz0WztmarbHW8BluPPx0kBbMUZsOujTdv0 QLECjGY47vtSd0RqfbGg+sk+GXnL4vxy9qTao0tb5VmzUdoWpMhKVsw8yBjrWmBMh0HF APSA== MIME-Version: 1.0 Received: by 10.204.9.11 with SMTP id j11mr786165bkj.53.1354306504431; Fri, 30 Nov 2012 12:15:04 -0800 (PST) Received: by 10.204.66.83 with HTTP; Fri, 30 Nov 2012 12:15:04 -0800 (PST) In-Reply-To: References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <866BC125-5820-45A6-A23B-19A0A3CC05DF@gmail.com> Date: Fri, 30 Nov 2012 15:15:04 -0500 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=00151758f4221d1a5804cfbc0e42 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: Fri, 30 Nov 2012 20:15:07 -0000 --00151758f4221d1a5804cfbc0e42 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 29, 2012 at 11:54 PM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > On Thu, Nov 29, 2012 at 2:27 PM, Brian Dickson > wrote: > > > If the "private use" ASNs were NOT from a well-known range, you would > detect this how? > > some other macro of integers perhaps? > The point I was trying to make was, with the PRIVATE range, the purpose & intent of the ASNs in THAT range is reasonably well defined. If a large number of ASNs are used, AND non-contiguous, whose intent is unclear or not specified (and may or may not be "private", as in, not intended for announcements towards the Public Internet), there is no general way for a third party to infer the intent. In fact, generally, intent cannot be inferred. On the other hand, if there is a new block where the one rule is, "Do NOT announce to the Internet", then the only inference rules are very clear. 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. > > > > > This actually does a lot to demonstrate the usefulness of the old range, > and of having a new range larger in size. > > how does it help show a larger size range would be helpful? > > > > > If 192.168.0.0/16 was the only RFC 1918 space, the value of 10.0.0.0/8might not be as clear. > > The analogy is pretty clear. > > > > expand pls. > > > Not only is there value in more space, there is value in distinct ranges. > > a distinct range is of value, sure. how are more ranges helpful though? > A larger contiguous block means anyone USING that block can impose structure on that block. Since the block is private, there are no restrictions on how someone partitioning their own instance might do so. Structure => tool-friendly Using tools is generally preferably to managing things manually, and if done well, reduces the likelihood of errors that lead to non-Internet ASNs showing up on the Internet. E.g. a hierarchical network architecture, which incorporates such private ASNs, e.g. pre-allocated in blocks (by continent, NFL city, router, etc.), is much simpler to understand (inside the network doing this), and scalable, and by having the private ASNs from a single well-known and re-used range, enables third parties to know that the ASNs are not public Internet ASNs. The new range of private ASNs not only works for filters, but also various OSS systems, e.g systems to monitor BGP announcements, which can alert when anomalous announcement activity is seen. > > > Having non-globally-unique space that is well known allows third parties > to detect leaks, filter, and make permanent bogon filters. > > > > you mean it makes people carry crufty config for exceptions forever... > sure. > it also does show some obvious routing problems to the world, or does > it? maybe it's not a routing problem but a 'forgot to > cut/paste/replace my ASN for my customer ASN' ? it's not clear at all > from the data on the wire, except that the reaction to: "I see 65535 > in an as-path" is "that is bad". > > if I see: > 198.41.0.0/24 as-path: 1 2 3 26415 65534 > > is that a leak or a missed configuration on a 26415 device? (forgot to > put remove-private-asn on the upstream neighbor to 3). > > It DOES NOT MATTER what the original intent was, or why you see the questionable ASN. What does matter, is that it does not belong, and can/should be ignored/blocked/whatever. The only time you SHOULD care (i.e. why it shows up), is if the ASN immediately to the left (of the private ASN) is your own, at which point you really should take direct action. The important thing is, YOU will (or at least should) have all the info you need to figure out why etc. Without such a well-defined range, there is not always a clear relationship between the cause and the effect, and the ideal corrective action. However, with a pre-defined range or set of ranges, you are actually very concise when you say, "I see 65xxx and that is bad". Nothing more is needed. Regardless of cause, the effect is "that is bad". At which point, however many ways there are to get rid of the bad, the correct course is, "make it go away". As long as there _is_ a way, things are good. Additionally, there are plenty of mechanisms for doing ASN re-writing, which are more general-purpose than just "remove-private-as". So, prior to hardcoded support for new ASN blocks, the necessary mechanisms to achieve the same functionality are ALREADY available. There is no need to tie it to router firmware, as such. (E.g. AS rewriting for ASN migration during merger/acquisition activity, etc.) > > In case it is not obvious: > > > > Support (strongly). > > mostly I'm ambivalent at this point. I'm not really in favor of adding > more complexity here, especially when there is a regular remedy: "Hi > ARIN, I need 300 asns for my next 300 deployments, all which are > scheduled to happen in the next Y days, all of which have a unique > routing policy." > > The proposal REMOVES complexity, by removing the non-public ASNs from the RIR-managed space. It simplifies the logic for non-Internet ASN usage. And for managing a mix of public and "other" usage, for an SP, managing two pools of ASNs is pretty straightforward. Especially if one of those does not require interaction with an RIR. Hopefully, this clarifies the questions Chris had, as well as illustrating some of the finer points made earlier. Brian --00151758f4221d1a5804cfbc0e42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 29, 2012 at 11:54 PM, Christ= opher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Nov 29, 2012 at 2:27 PM, Brian Dickson
<bria= n.peter.dickson@gmail.com> wrote:

> If the "private use" ASNs were NOT from a well-known range, = you would detect this how?

some other macro of integers perhaps?

=
The point I was trying to make was, with the PRIVATE range, the purpos= e & intent of the ASNs in THAT range is reasonably well defined.

If a large number of ASNs are used, AND non-contiguous, whose in= tent is unclear or not specified (and may or may not be "private"= , as in, not intended for announcements towards the Public Internet), there= is no general way for a third party to infer the intent. In fact, generall= y, intent cannot be inferred.

On the other hand, if there is a new block where the on= e rule is, "Do NOT announce to the Internet", then the only infer= ence rules are very clear.

If you see it on the Pu= blic Internet, it does not belong and can be ignored safely, and should not= be propagated to one's Internet peers/customers.

=A0

>
> This actually does a lot to demonstrate the usefulness of the old rang= e, and of having a new range larger in size.

how does it help show a larger size range would be helpful?

>
> If 192.168.0.0/16<= /a> was the only RFC 1918 space, the value of 10.0.0.0/8 might not be as clear.
> The analogy is pretty clear.
>

expand pls.

> Not only is there value in more space, there is value in distinct rang= es.

a distinct range is of value, sure. how are more ranges helpful thoug= h?

A larger contiguous block means anyo= ne USING that block can impose structure on that block.
Since the= block is private, there are no restrictions on how someone partitioning th= eir own instance might do so.

Structure =3D> tool-friendly

Using tools is generally preferably to managing things manually, and if d= one well, reduces the likelihood of errors that lead to non-Internet ASNs s= howing up on the Internet.

E.g. a hierarchical network architecture, which incorpo= rates such private ASNs, e.g. pre-allocated in blocks (by continent, NFL ci= ty, router, etc.), is much simpler to understand (inside the network doing = this), and scalable, and by having the private ASNs from a single well-know= n and re-used range, enables third parties to know that the ASNs are not pu= blic Internet ASNs.

The new range of private ASNs not only works for filter= s, but also various OSS systems, e.g systems to monitor BGP announcements, = which can alert when anomalous announcement activity is seen.

=A0

> Having non-globally-unique space that is well known allows third parti= es to detect leaks, filter, and make permanent bogon filters.
>

you mean it makes people carry crufty config for exceptions forever..= . sure.
it also does show some obvious routing problems to the world, or does
it? maybe it's not a routing problem but a 'forgot to
cut/paste/replace my ASN for my customer ASN' ? it's not clear at a= ll
from the data on the wire, except that the reaction to: "I see 65535 in an as-path" is "that is bad".

if I see:
=A0198.41.0.0/24 as-= path: 1 2 3 26415 65534

is that a leak or a missed configuration on a 26415 device? (forgot to
put remove-private-asn on the upstream neighbor to 3).


It DOES NOT MATTER what the= original intent was, or why you see the questionable ASN.

What does matter, is that it does not belong, and can/should be ig= nored/blocked/whatever.

The only time you SHOULD care (i.e. why it shows up), i= s if the ASN immediately to the left (of the private ASN) is your own, at w= hich point you really should take direct action. The important thing is, = =A0YOU will (or at least should) have all the info you need to figure out w= hy etc.

Without such a well-defined range, there is not always = a clear relationship between the cause and the effect, and the ideal correc= tive action.

However, with a pre-defined range or = set of ranges, you are actually very concise when you say, "I see 65xx= x and that is bad". Nothing more is needed.

Regardless of cause, the effect is "that is bad". At which p= oint, however many ways there are to get rid of the bad, the correct course= is, "make it go away". As long as there _is_ a way, things are g= ood.

Additionally, =A0there are plenty of mechanisms for doi= ng ASN re-writing, which are more general-purpose than just "remove-pr= ivate-as". So, prior to hardcoded support for new ASN blocks, the nece= ssary mechanisms to achieve the same functionality are ALREADY available. T= here is no need to tie it to router firmware, as such. (E.g. AS rewriting f= or ASN migration during merger/acquisition activity, etc.)
=A0
> In case it is not obvious:
>
> Support (strongly).

mostly I'm ambivalent at this point. I'm not really in favor = of adding
more complexity here, especially when there is a regular remedy: "Hi ARIN, I need 300 asns for my next 300 deployments, all which are
scheduled to happen in the next Y days, all of which have a unique
routing policy."


The proposal REMOVES complexity, by re= moving the non-public ASNs from the RIR-managed space.
It simplif= ies the logic for non-Internet ASN usage. And for managing a mix of public = and "other" usage, for an SP, managing two pools of ASNs is prett= y straightforward. Especially if one of those does not require interaction = with an RIR.=A0

Hopefully, this clarifies the questions Chris had= , as well as illustrating some of the finer points made earlier.

Brian
--00151758f4221d1a5804cfbc0e42-- From randy@psg.com Fri Nov 30 16:13: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 DD9C521F89A9 for ; Fri, 30 Nov 2012 16:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 SKkl8eJ0Wk9T for ; Fri, 30 Nov 2012 16:13:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5590221F8A2A for ; Fri, 30 Nov 2012 16:13: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 1Teahj-000Pfu-6B; Sat, 01 Dec 2012 00:13:11 +0000 Date: Sat, 01 Dec 2012 09:13:09 +0900 Message-ID: From: Randy Bush To: Tony Li In-Reply-To: <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@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> 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: Sat, 01 Dec 2012 00:13:16 -0000 > There is ample demand for doing this in the current world, there is demand for all sorts of things. 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. > There is ample demand for doing this, it's simply not represented by > the SP community. you will note a large number of SPs speaking against this proposal randy From brian.peter.dickson@gmail.com Fri Nov 30 16:34: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 CC1B221F86C2 for ; Fri, 30 Nov 2012 16:34:01 -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 4Ua6mmeTuG7m for ; Fri, 30 Nov 2012 16:34:00 -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 1C57621F8675 for ; Fri, 30 Nov 2012 16:33:59 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so467191eaa.31 for ; Fri, 30 Nov 2012 16:33:58 -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=5BljFijFktOzRq3sUeYQVQR7mhFEAtI1J+Df8HzUlK4=; b=t4aGpVctATNWGijI4AqFEgQ0HN1oGVcBfgM9cLN0p+yYAjt7PkqUhHjj/bQXD8Ickc VIVd0y83Y238xX8zq2yHmLyp3AIFzlyGUv7H3ZvyD12dAbh7uMu7thIO5HKofpmxQcL4 HcFFw0S2w/ERgCrUBhwUR4bFEKeXS33FMe/buH2Glzb7S7m+xXUrFsPwyueX4OJM/asD Rlwfl6BdNRTMZU3Tvd3k1NpAnF508njSKm+r7MXopgNGS/k570nttTsWuyTD9yTGije1 AUG1SLRE0divm8PzAtG8mHWhi+sX8I7iSPS7IMDmjuQaLB/AM8V1YC56kal4HcvF53ny CFAQ== MIME-Version: 1.0 Received: by 10.14.225.194 with SMTP id z42mr3214909eep.22.1354322038807; Fri, 30 Nov 2012 16:33:58 -0800 (PST) Received: by 10.223.145.133 with HTTP; Fri, 30 Nov 2012 16:33:58 -0800 (PST) In-Reply-To: <4145B9A4-56D2-4DEB-9583-F86F7E73BD77@apnic.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> Date: Fri, 30 Nov 2012 19:33:58 -0500 Message-ID: From: Brian Dickson To: Geoff Huston Content-Type: multipart/alternative; boundary=047d7b66f24b08ddba04cfbfac57 Cc: "idr@ietf. org" , 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: Sat, 01 Dec 2012 00:34:02 -0000 --047d7b66f24b08ddba04cfbfac57 Content-Type: text/plain; charset=ISO-8859-1 I'd like to use an example to illustrate the usefulness of a large number of code points which are not globally unique, but where the same code point cannot be re-used. (The identity of the network in question isn't terribly important, but if anyone wants to know, please contact me off-list.) One former set-up I worked on, involved simulating the global DFZ routing environment, including lots of BGP sessions, and the full complement of ASNs and prefixes. At the time, the only mechanism available was to set up the environment using the REAL prefixes and REAL ASNs, and to very carefully ensure that prefix filters, packet filters, and an air gap, all prevented any unintentional leakage from this, since clearly this would have been potentially catastrophic (to both the Internet and my career.) Clearly, setting up N peering sessions (for very large value of N) isn't really feasible using a single code point, or even a very small number of N (like the current available ~1000 private ASNs). On the other hand, having a second block of private ASNs would not only facilitate a 1:1 correlation to "real world" ASNs in private ranges, but also allow simulating connection and re-use of "old-range" private ASNs to public ASNs, by replacing the public ASNs with "new-range" private ASNs. The benefit of such a numbering scheme for ASNs would be that any leakage of announcements would have AS4_PATH values involving only private ASNs, allowing operators seeing these to quickly determine their non-legitimacy, and to easily filter them (if filtering were not already being done). And yes, this was an actual set-up involving BGP announcements with real ASNs and real prefixes. This is not a hypothetical, white-board scenario. (The environment even simulated packet latency and loss to the whole Internet of destinations, needed for the product/service in question.) Since this example only uses "vanilla" BGP, not any of the MP-BGP "abominations", it may be a better poster child for the proposal - and I think illustrates instances where re-use of a subset of code points would not work (BGP loop avoidance mechanisms being what they are.) Brian On Thu, Nov 29, 2012 at 3:24 PM, Geoff Huston wrote: > > On 30/11/2012, at 7:14 AM, Robert Raszuk wrote: > > > Hi Geoff, > > > > So let me ask a very simple question in light of Brian's point .. > > > > Is it better for someone privately to just pick random 100K of ASes > > from 4 octet block and apply to his private needs or is it better if > > such pool is well known ? > > > > > Who is going to stop Jon or Kevin or Sasha to do the former ? > Internet-CIA ??? > > > (I love false dichotomies!) > > Of course when presented with this kind of either/or argument then the > obvious answer is "neither". > > If uniqueness is important then use a registry system that provides > uniqueness of assigned/allocated code points. > > If uniqueness is unimportant then use the same code point, because, well, > uniqueness was not important was it. > > Did I say already that I was opposed to the progress of this draft from > WG Last Call to the IESG? > > Geoff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b66f24b08ddba04cfbfac57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to use an example to illustrate the usefulness of a large numb= er of code points which are not globally unique, but where the same code po= int cannot be re-used.

(The identity of the network in q= uestion isn't terribly important, but if anyone wants to know, please c= ontact me off-list.)

One former set-up I worked on, involved simulating the = global DFZ routing environment, including lots of BGP sessions, and the ful= l complement of ASNs and prefixes.

At the time, th= e only mechanism available was to set up the environment using the REAL pre= fixes and REAL ASNs, and to very carefully ensure that prefix filters, pack= et filters, and an air gap, all prevented any unintentional leakage from th= is, since clearly this would have been potentially catastrophic (to both th= e Internet and my career.)

Clearly, setting up N peering sessions (for very large = value of N) isn't really feasible using a single code point, or even a = very small number of N (like the current available ~1000 private ASNs).

On the other hand, having a second block of private ASN= s would not only facilitate a 1:1 correlation to "real world" ASN= s in private ranges, but also allow simulating connection and re-use of &qu= ot;old-range" private ASNs to public ASNs, by replacing the public ASN= s with "new-range" private ASNs.

The benefit of such a numbering scheme for ASNs would b= e that any leakage of announcements would have AS4_PATH values involving on= ly private ASNs, allowing operators seeing these to quickly determine their= non-legitimacy, and to easily filter them (if filtering were not already b= eing done).

And yes, this was an actual set-up involving BGP announ= cements with real ASNs and real prefixes. This is not a hypothetical, white= -board scenario. (The environment even simulated packet latency and loss to= the whole Internet of destinations, needed for the product/service in ques= tion.)

Since this example only uses "vanilla" BGP, n= ot any of the MP-BGP "abominations", it may be a better poster ch= ild for the proposal - and I think illustrates instances where re-use of a = subset of code points would not work (BGP loop avoidance mechanisms being w= hat they are.)

Brian

On Thu, = Nov 29, 2012 at 3:24 PM, Geoff Huston <gih@apnic.net> wrote:
=

On 30/11/2012, at 7:14 AM, Robert Raszuk <robert@raszuk.net> wrote:

> Hi Geoff,
>
> So let me ask a very simple question in light of Brian's point ..<= br> >
> Is it better for someone privately to just pick random 100K of ASes > from 4 octet block and apply to his private needs or is it better if > such pool is well known ?

>
> Who is going to stop Jon or Kevin or Sasha to do the former ? Internet= -CIA ???


(I love false dichotomies!)

Of course when presented with this kind of either/or argument then the
obvious answer is "neither".

If uniqueness is important then use a registry system that provides
uniqueness of assigned/allocated code points.

If uniqueness is unimportant then use the same code point, because, well, uniqueness was not important was it.

Did I say already that I was opposed to the progress of this draft from
WG Last Call to the IESG?

Geoff

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

--047d7b66f24b08ddba04cfbfac57-- From randy@psg.com Fri Nov 30 16:58: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 BBA7921F89E9 for ; Fri, 30 Nov 2012 16:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, 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 hQJ+bWh7WX9p for ; Fri, 30 Nov 2012 16:58:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 567C921F89A7 for ; Fri, 30 Nov 2012 16:58:38 -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 1TebPh-0000KW-4q; Sat, 01 Dec 2012 00:58:37 +0000 Date: Sat, 01 Dec 2012 09:58:35 +0900 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: 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> 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: Sat, 01 Dec 2012 00:58:38 -0000 > One former set-up I worked on, involved simulating the global DFZ > routing environment and i would like to do a simulation with 2^42 ASs. let's do an rfc expanding the AS space to 48 bits. :) for real world examples, could we please stick to the real internet? randy From tony.li@tony.li Fri Nov 30 17:03: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 DAA6F21F89A7 for ; Fri, 30 Nov 2012 17:03: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_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 aEZYkIVAOibo for ; Fri, 30 Nov 2012 17:03:01 -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 6A41121F884F for ; Fri, 30 Nov 2012 17:03:01 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta13.emeryville.ca.mail.comcast.net with comcast id VuVQ1k0081vN32cAD131Kc; Sat, 01 Dec 2012 01:03:01 +0000 Received: from [10.155.35.198] ([128.107.239.234]) by omta22.emeryville.ca.mail.comcast.net with comcast id W10l1k002547xYo8i10nkk; Sat, 01 Dec 2012 01:00:59 +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: Fri, 30 Nov 2012 17:00:44 -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> 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=1354323781; bh=ZEgR8S8hQQnwPZiOVXa15X5fL9s5baMyTbMCUhdQZiw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=AI2iW3sY4jGb43SwBDXxCrYlRm9kuHWk7RBvdfvsVLXMk7/8iKyq2YxqcDD+hGprJ 5SiESHuksH/hqhgyD3VsrI+kIIUv3qUWwLG6n7L86Bou3GILYeBBnJLeI803s4h4h0 NujwayAVUKNTLc5r2RRdgDA5KF2uvS2whasVXsdQ0jsPuLZ8zIM8AWw7cslekqG+dh MWtqDxpq7t5QdbFqwuBwGOZxwBq+aj2OAtJdXzyCz6NHw9vOJRvTHgVM8fGuTp04X1 iUF8CjFLudNMhp8wDowpgA2xCOlVaRvT/FlQT4+AxITAL7QT17Mo4XFMT33r4+ZHcI 2dZQs3CvIw3ww== 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: Sat, 01 Dec 2012 01:03:02 -0000 On Nov 30, 2012, at 4:13 PM, Randy Bush wrote: >> 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 Well, let's put it this way: 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. Yes, there are more than one of them = going this way, they are large and well-funded. It's going to happen. Now, again, we can block off a range of numbers, or data center folks = are going to end up squatting on public ASNs. And if that happens, we = will end up being asked to implement ASN NAT, at which point we can no = longer ensure global uniqueness. Can we please be practical? Tony From randy@psg.com Fri Nov 30 17:49: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 A94EB21F884F for ; Fri, 30 Nov 2012 17:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 w+wBtUqzmzuo for ; Fri, 30 Nov 2012 17:49:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3484321F8AA0 for ; Fri, 30 Nov 2012 17:49:20 -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 1TecCe-0000QG-5R; Sat, 01 Dec 2012 01:49:12 +0000 Date: Sat, 01 Dec 2012 10:49:11 +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> 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: Sat, 01 Dec 2012 01:49:20 -0000 > 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. update the draft to make these arguments, i will support it, and i suspect other dissidents will as well. randy From farmer@umn.edu Fri Nov 30 20:26: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 8FD8C21F87AB for ; Fri, 30 Nov 2012 20:26:41 -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 eFgpiA0+lYVw for ; Fri, 30 Nov 2012 20:26:41 -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 DF62421F881B for ; Fri, 30 Nov 2012 20:26:40 -0800 (PST) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 30 Nov 2012 22:26:30 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f198.google.com [209.85.214.198] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f198.google.com with SMTP id un3so5507903obb.1 for ; Fri, 30 Nov 2012 20:26:30 -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=qmoMRWWZobytAejChLHJ/EEQ4NfP7lAp6l64dd31js8=; b=OY+8vphMoDptUTi0PVdxN/fTt/jVlKnKL97VNBmtj68jhfW8gX8/Skle99hJRwC0In wsxMEbO+sl8adq7EVUdPt0qqRTEFCaDEuz2p8rVC6A4tMBVXlXMfM6+Mr0UpqwS1HQcd 8uI3d9CUGT4zbjb1DLukxt5bg82TXkfT6gj3nf//oFlOTEJEAr0ZtmaszIdFP/1++Eq/ vU5fbSU+qDqcZIrII2haAk27xXOGqgVNXJMZ6mVxzshXY7p+2d0nYYcPYLheYgIJrj7U +aDKqfjI2ZkfSYQEggNgUxEXlLJ7Qh7LJMFKTRa2yjQtc5uOXheQjMSI9y771e6fXMao FePw== Received: by 10.50.45.168 with SMTP id o8mr639079igm.50.1354335989810; Fri, 30 Nov 2012 20:26:29 -0800 (PST) Received: by 10.50.45.168 with SMTP id o8mr639073igm.50.1354335989732; Fri, 30 Nov 2012 20:26:29 -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 uj11sm1153333igb.15.2012.11.30.20.26.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 20:26:29 -0800 (PST) Message-ID: <50B986F2.5060405@umn.edu> Date: Fri, 30 Nov 2012 22:26:26 -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: Randy Bush References: <378E396E-3F4B-4ACC-83D1-C4931524FECD@puck.nether.net> <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <9DCD1872-F11D-4B08-9B0B-834C05D7D0FF@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkdmVxxqbyP8OrHCyxnNF0upz/niEtvfeFhIeTfI+8dIWEcqRTnmVFVk7tLssXDkSTthHaKq37Yf+/Wv1PU/ZwI3XqzrI9XgBigaLUAF6lMS4eeOSeLoicRUY7JNslgeSrAde1N 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: Sat, 01 Dec 2012 04:26:41 -0000 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. 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 that exemplify the changing BGP environment that should be added as well? 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 ================================================