Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
Purely as a point of information, I think its worth remembering that 32 bit ASN cannot be used in currently specified BGP4 in communities, because its a 32 bit field defined as two 16 bit halves. I believe there is work afoot in IETF to fix this. I don't have concrete details. Therefore there *is* a quality in 16 bit ASN which may be divorced from its association with specific V4 or V6 resources and which makes it a desirable thing, in itself, for some people: If you are in the business of doing TE in BGP with communities, you can't do it with 32 bit ASN. You have to use other mechanisms. On that basis, Should you permit transfers of ASN, you might wish to permit transfers of ASN independently of any associated routable IP address space: people who already have space but need a 16 bit ASN may wish to acquire one. I'm not an asset holder in the RIPE region, and I am staff at another RIR, so I stress this is purely informational. I'm not trying to directly advocate for or against ASN transfers. -George On 3 September 2015 at 14:38, Nick Hilliard <nick@inex.ie> wrote:
On 03/09/2015 18:09, Sascha Luck [ml] wrote:
Mind, if yelling loudly is how you get policy made in the RIPE community, rest assured I can yell VERY loudly. I can, in fact, even automate the yelling if need be.
please don't: rfc7282 works much better.
Nick
This has come up several times before. There is support for asn32s in bgp extended communities: you need the "Transitive Four-Octet AS-Specific Extended Community" values from here: http://www.iana.org/assignments/bgp-extended-communities ... and you need to hope that this is supported on your router software. And everyone else's that you plan to talk to. This can work in some situations where you have tight control over the entire management plane of everywhere you plan to export these communities to, but the internet at large is going to have a lot more difficulty with it. As you point out, you can only support 16b:32b or 32b:16b style communities with the current community mechanism, not 32b:32b communities. The latter will require implementation of draft-ietf-idr-wide-bgp-communities. So if you have any requirement for 32b:32b communities, you're out of luck. Nick On 03/09/2015 18:59, George Michaelson wrote:
Purely as a point of information, I think its worth remembering that 32 bit ASN cannot be used in currently specified BGP4 in communities, because its a 32 bit field defined as two 16 bit halves. I believe there is work afoot in IETF to fix this. I don't have concrete details.
Therefore there *is* a quality in 16 bit ASN which may be divorced from its association with specific V4 or V6 resources and which makes it a desirable thing, in itself, for some people: If you are in the business of doing TE in BGP with communities, you can't do it with 32 bit ASN. You have to use other mechanisms.
On that basis, Should you permit transfers of ASN, you might wish to permit transfers of ASN independently of any associated routable IP address space: people who already have space but need a 16 bit ASN may wish to acquire one.
I'm not an asset holder in the RIPE region, and I am staff at another RIR, so I stress this is purely informational. I'm not trying to directly advocate for or against ASN transfers.
-George
On 3 September 2015 at 14:38, Nick Hilliard <nick@inex.ie <mailto:nick@inex.ie>> wrote:
On 03/09/2015 18:09, Sascha Luck [ml] wrote: > Mind, if yelling loudly is how you get policy made in the RIPE > community, rest assured I can yell VERY loudly. I can, in fact, > even automate the yelling if need be.
please don't: rfc7282 works much better.
Nick
participants (2)
-
George Michaelson -
Nick Hilliard