Subject: Re: [Idr] I-D Action:draft-ietf-idr-as4octet-extcomm-generic-subtype-01.txt

From: Andy Davidson <[email-masked]>
Date: Mon, 21 Dec 2009 19:18:00 +0000

On 26 Oct 2009, at 21:45, [email-masked] 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: Rob Shakir <[email-masked]>
Date: Tue, 22 Dec 2009 13:02:25 +0000

On 21 Dec 2009, at 19:18, Andy Davidson wrote:

> 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-00.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.
> 

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. 

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

-- 
Rob Shakir                      <[email-masked]>
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