<div dir="ltr">Right. I mussed up some details. The substance remains: if you are exposed to economics which depends on the use of communities for TE, and cannot influence external agents you do BGP with to support extended communities, then you may decide you need a 16bit ASN, and so they have inherent value to you, distinct from any other resources potentially in transfer. You aren't looking to acquire active IPv4, or IPv6, you are looking to acquire a 16 bit ASN as a thing in itself. <div><br></div><div>-G</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 September 2015 at 15:49, Nick Hilliard <span dir="ltr"><<a href="mailto:nick@inex.ie" target="_blank">nick@inex.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This has come up several times before.  There is support for asn32s in bgp<br>
extended communities: you need the "Transitive Four-Octet AS-Specific<br>
Extended Community" values from here:<br>
<br>
<a href="http://www.iana.org/assignments/bgp-extended-communities" rel="noreferrer" target="_blank">http://www.iana.org/assignments/bgp-extended-communities</a><br>
<br>
... and you need to hope that this is supported on your router software.<br>
And everyone else's that you plan to talk to.<br>
<br>
This can work in some situations where you have tight control over the<br>
entire management plane of everywhere you plan to export these communities<br>
to, but the internet at large is going to have a lot more difficulty with it.<br>
<br>
As you point out, you can only support 16b:32b or 32b:16b style communities<br>
with the current community mechanism, not 32b:32b communities.  The latter<br>
will require implementation of draft-ietf-idr-wide-bgp-communities.<br>
<br>
So if you have any requirement for 32b:32b communities, you're out of luck.<br>
<span class="HOEnZb"><font color="#888888"><br>
Nick<br>
</font></span><span class="im HOEnZb"><br>
On 03/09/2015 18:59, George Michaelson wrote:<br>
> Purely as a point of information, I think its worth remembering that 32 bit<br>
> ASN cannot be used in currently specified BGP4 in communities, because its<br>
> a 32 bit field defined as two 16 bit halves. I believe there is work afoot<br>
> in IETF to fix this. I don't have concrete details.<br>
><br>
> Therefore there *is* a quality in 16 bit ASN which may be divorced from its<br>
> association with specific V4 or V6 resources and which makes it a desirable<br>
> thing, in itself, for some people: If you are in the business of doing TE<br>
> in BGP with communities, you can't do it with 32 bit ASN. You have to use<br>
> other mechanisms.<br>
><br>
> On that basis, Should you permit transfers of ASN, you might wish to permit<br>
> transfers of ASN independently of any associated routable IP address space:<br>
> people who already have space but need a 16 bit ASN may wish to acquire one.<br>
><br>
> I'm not an asset holder in the RIPE region, and I am staff at another RIR,<br>
> so I stress this is purely informational. I'm not trying to directly<br>
> advocate for or against ASN transfers.<br>
><br>
> -George<br>
><br>
> On 3 September 2015 at 14:38, Nick Hilliard <<a href="mailto:nick@inex.ie">nick@inex.ie</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:nick@inex.ie">nick@inex.ie</a>>> wrote:<br>
><br>
>     On 03/09/2015 18:09, Sascha Luck [ml] wrote:<br>
>     > Mind, if yelling loudly is how you get policy made in the RIPE<br>
>     > community, rest assured I can yell VERY loudly. I can, in fact,<br>
>     > even automate the yelling if need be.<br>
><br>
>     please don't:  rfc7282 works much better.<br>
><br>
>     Nick<br>
><br>
<br>
</div></div></blockquote></div><br></div>