Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[George Michaelson]

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

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Nick Hilliard]

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

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[George Michaelson]

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

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Nick Hilliard]

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