[ixpmanager] route server template/32bit ASNs

[Stefan Kaltenbrunner]

On 08/06/2015 03:44 PM, Nick Hilliard wrote:
> On 06/08/2015 14:13, Stefan Kaltenbrunner wrote:
>> On 08/06/2015 03:03 PM, Nick Hilliard wrote:
>>> 1. static mapping doesn't scale
>>
>> I agree there but for our usecase we probably dont need that level of
>> scaling for the forseeable future...
> 
> 
>>> 3. INEX did some models based on this a couple of years ago and decided
>>> that it wouldn't work
>>
>> could you elaborate on "wouldn't work"? if it works for AMS-IX (disclaimer:
>> I only read their docs so far and talked to some active users of the
>> feature there) - it should work for most IXPs...
> 
> Check out pages 31-32 of:
> 
> http://ripe59.ripe.net/presentations/hilliard-irrtoolset.pdf
> 
> These two tables show the difference between published actual BGP sessions
> and peering relationships as described in IRRDB policies.  You can see that
> there is virtually no relationship between the two.
> 
> There would be a lot of work to get table #2 in the same shape as #1.

hmm not sure I understand the ultimate connection here, what AMS-IX does
is using "import-via: / export-via:" from IETF draft-ietf-grow-rpsl-via-01.
>From a pure route server perspective using that kind approach seems
fairly elegant to me - handles ASN32 and gives members wanting to use it
very fine-grained control.


> 
>>> 2. is potentially interesting but is limited by the fact that not all
>>> routers support draft-ietf-idr-as4octet-extcomm-generic-subtype, and many
>>> only support a small number of fixed types of extended community.  This
>>> means that interoperability is a problem.
>>
>> hmm - I dont assume there is some sort of list available on who does and
>> who does not?
> 
> AFAIK, only de-cix supports draft-ietf-idr-as4octet-extcomm-generic-subtype
> on their route servers.
> 
>>> There are no good solutions to this problem at the moment.  INEX advises
>>> route server users to use ASN16s, but that can mean renumbering ASNs.
>>
>> yeah - we are talking a small IXP starting up here that has a large number
>> of "first IXP we are connected" participants with ASN32 on one side (and
>> having to renumber would be way too much work for them) and a number of
>> fairly large ISPs that need that kind of control because of downstream
>> agreements with some of the participants.
> 
> We have similar issues.  Agreed that renumbering ASNs is a pain, but ISPs
> who use ASN32s should bear in mind that they will also be unable to use
> exportable BGP communities on their networks.  This will cause them scaling
> problems in future.

yeah I fully agree - but I also assume that for a large percentage of
the small ISPs we are currently talking to that wont be an issue they
care about atm, yet it is a "problem" for IXP because it makes some of
the larger players relucant to peer with the routeserver.


Stefan