shim6 @ NANOG (forwarded note from John Payne)

Wed Mar 1 18:55:48 UTC 2006

On 1-Mar-2006, at 13:32, Kevin Day wrote:

>>> We have peering arrangements with about 120 ASNs. How do we mix  
>>> BGP IPv6 peering and Shim6 for transit?
>>
>> You advertise all your PA netblocks to all your peers.
>
> Ok, I was a bit too vague there...
>
> How do we ensure that peering connections are always used instead  
> of transit connections?
>
> Currently for outbound, we can localpref peer-learned routes over  
> everything else. How do all of our servers on our end know that  
> routes learned from a BGP session on our own routers are desirable?

If a client has a set of locators, some of which are reachable via  
peering connections and some of which are reachable via transit  
connections, you want to be able to bias the locator selection such  
that (perhaps, e.g.) peering locators are always preferred to those  
which involve transit providers.

Although simple performance benefits might cause hosts to make that  
decision on their own, you don't want to leave the decision up to the  
hosts, since if they get it wrong it will cost you money.

This seems inordinately reasonable. Did I summarise correctly?

> [...]
>
> But, policies shouldn't be written depending on tools that don't  
> exist yet, which is basically what's happening now.

Actually, I think policies are conservative because there's a lack of  
solid, technical argument for loosening them. If (for example) there  
was consensus between operators and shim6 architects that the  
requirements of hosting providers are definitively not met by shim6,  
for technical/architectural reasons, then it'd be far easier to  
convince RIR memberships and boards that policy modifications should  
be made to accommodate operators like you.

> [...]
>
> Even if 100% of the IPv4 networks moved to IPv6 today, we'd still  
> have a smaller table size in 6 than 4. Growth would be slower (ISPs  
> and NSPs wouldn't continually be adding more networks as they grew,  
> initial allocations should be enough for just about everyone).

The trouble with this is that for every argument that says "PI for  
all will be fine" there's a corresponding argument that says "PI for  
all will not scale".

> Without totally upending my network, I need:
>
> 1) PI space
> 2) The ability to deaggregate that PI space where truly needed. (or  
> the ability to request multiple PI blocks, but I don't see how that  
> helps matters)
> 3) BGP announcements to the world

For sure, the simplest and cheapest thing for you would be to obtain  
PI space and continue as you have been doing with v4. The  
implications of that are not necessarily simple nor cheap for others,  
however, if you're one of $BIGNUM people doing it.

> -- Kevin
> (wondering how many people are muttering 'kook' right now)

:-)

Joe