headers
Andy Davidson | 21 Dec 20:18

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


On 26 Oct 2009, at 21:45, Internet-Drafts <at> 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 ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Shakir | 22 Dec 14:02

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


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

> 
> On 26 Oct 2009, at 21:45, Internet-Drafts <at> 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.

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane