From andy@nosignal.org Mon Dec 21 11:18:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBADE28C153 for ; Mon, 21 Dec 2009 11:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeEEMlG68o6s for ; Mon, 21 Dec 2009 11:18:22 -0800 (PST) Received: from chilli.nosignal.org (chilli.nosignal.org [91.194.68.1]) by core3.amsl.com (Postfix) with ESMTP id D36873A6834 for ; Mon, 21 Dec 2009 11:18:21 -0800 (PST) Received: from [78.33.75.33] (helo=[10.1.1.2]) by chilli.nosignal.org with esmtpa (Exim 4.69) (envelope-from ) id 1NMnlZ-0006Ha-52 for idr@ietf.org; Mon, 21 Dec 2009 19:18:03 +0000 Message-Id: <2181DDB4-07AB-4B41-A137-C07525BDF2AA@nosignal.org> From: Andy Davidson To: idr@ietf.org In-Reply-To: <20091026214502.0D1B83A684C@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Dec 2009 19:18:00 +0000 References: <20091026214502.0D1B83A684C@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: Re: [Idr] I-D Action:draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:18:23 -0000 On 26 Oct 2009, at 21:45, Internet-Drafts@ietf.org wrote: > Maintaining the current best practices with communities, ISPs and > enterprises that are assigned a 4-octet AS number may want the BGP > UPDATE messages they receive from their customers or peers to include > a 4-octet AS specific extended community. This document defines a > new sub-type within the four-octet AS specific extended community to > facilitate this practice. Hi, all The previous version of this draft (26th January) can no longer be found at the -00.txt URL, and I was hoping to compare the versions. Section 3 - should we really make recommendations about how operators should behave if extended communities are not supported ? If we do, would we want to recommend the use of AS_TRANS as an encoder (current proposal) rather than part of the private-asn number space ? At multilateral peering services, commonly found at many internet exchange points, sometimes communities of the form n:y are used, where n (Global administrator) is the AS number of the IXP route-server, and y (Local administrator) is a MLP participant's as-number. Clearly there is not enough space in this extended community proposal to encode two 4 byte numbers. There may be other examples of occasions where the Local Administrator is an AS number which therefore must be four bytes long. Do we have options here ? -- Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com NetSumo Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC From rjs@eng.gxn.net Tue Dec 22 05:03:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043EA3A6A05 for ; Tue, 22 Dec 2009 05:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLE8LO+8yGi8 for ; Tue, 22 Dec 2009 05:03:17 -0800 (PST) Received: from mocha.rob.sh (mocha.rob.sh [193.239.32.250]) by core3.amsl.com (Postfix) with ESMTP id 4DDF73A6A58 for ; Tue, 22 Dec 2009 05:02:46 -0800 (PST) Received: from [195.224.160.13] (helo=stj-jshutler.internal.hosteurope.com) by mocha.rob.sh with esmtpa (Exim 4.66) (envelope-from ) id KV21K5-0002PU-CX; Tue, 22 Dec 2009 13:02:29 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <2181DDB4-07AB-4B41-A137-C07525BDF2AA@nosignal.org> Date: Tue, 22 Dec 2009 13:02:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <96B28794-5F5E-44B4-90FD-ADF9379C7D33@eng.gxn.net> References: <20091026214502.0D1B83A684C@core3.amsl.com> <2181DDB4-07AB-4B41-A137-C07525BDF2AA@nosignal.org> To: Andy Davidson X-Mailer: Apple Mail (2.1077) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action:draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 13:03:19 -0000 On 21 Dec 2009, at 19:18, Andy Davidson wrote: >=20 > On 26 Oct 2009, at 21:45, Internet-Drafts@ietf.org wrote: >=20 >> Maintaining the current best practices with communities, ISPs and >> enterprises that are assigned a 4-octet AS number may want the BGP >> UPDATE messages they receive from their customers or peers to include >> a 4-octet AS specific extended community. This document defines a >> new sub-type within the four-octet AS specific extended community to >> facilitate this practice. >=20 > Hi, all >=20 > The previous version of this draft (26th January) can no longer be = found at the -00.txt URL, and I was hoping to compare the versions. Hi Andy, It was my understanding that the /id/ directory on ietf.org holds only = the latest version of a draft -- there's a historical copy at = http://tools.ietf.org/id/draft-ietf-idr-as4octet-extcomm-generic-subtype-0= 0.txt :-) > Section 3 - should we really make recommendations about how operators = should behave if extended communities are not supported ? If we do, = would we want to recommend the use of AS_TRANS as an encoder (current = proposal) rather than part of the private-asn number space ? I'm not sure that I read this in the same way as you, my interpretation = was that this is merely a behaviour that could be implemented, rather = than a particular recommendation? After all, once this value is replaced = with AS_TRANS or a private AS number, then whatever meaning it really = had has been lost. My view here is that there is scope to suggest an approach to validate = the statement that one could use 2-byte ASNs to bridge a gap where the = 4-byte extcomm is not supported. The 'value' of community attributes = tends to be found either on a directly connected peer relationship, or = over a transit boundary - in each case, isn't it really the two sets of = operators that should choose a 'best practice' way forward? > At multilateral peering services, commonly found at many internet = exchange points, sometimes communities of the form n:y are used, where n = (Global administrator) is the AS number of the IXP route-server, and y = (Local administrator) is a MLP participant's as-number. Clearly there = is not enough space in this extended community proposal to encode two 4 = byte numbers. There may be other examples of occasions where the Local = Administrator is an AS number which therefore must be four bytes long. >=20 > Do we have options here ? I'm not sure that we do - other than re-examining the specification that = is made in rfc4360 [0] - given that the RFC states that BGP extended = communities are 8-octet quantities, where 1 or 2 octets are utilised as = a Type field, then we can't really easily encode two 4-byte ASNs into = these field as you note.=20 Whilst I can see the value that having two ASes encoded in this type of = community has for MLP usage, I'm not sure that this practice wasn't just = defined due to the fact that existing 2-byte ASNs fit 'nicely' into this = value - there is after-all some scope for other community schema to be = defined. Given that this proposal still defines 2-octets for local administrative = usage, and supports the 'standard' manner of ensuring no namespace = clashing, then I am unsure that there's much scope for redefining this = draft to support this specific operational concern. Kind regards, Rob [0]: http://tools.ietf.org/html/rfc4360 --=20 Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html