This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
- Previous message (by thread): [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
- Next message (by thread): [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
George Michaelson
ggm at apnic.net
Thu Sep 3 21:22:55 CEST 2015
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. -G On 3 September 2015 at 15:49, Nick Hilliard <nick at inex.ie> wrote: > 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 at inex.ie > > <mailto:nick at 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20150903/bf794b65/attachment.html>
- Previous message (by thread): [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
- Next message (by thread): [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]