North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: shim6 @ NANOG (forwarded note from John Payne)

  • From: Joe Abley
  • Date: Wed Mar 01 13:56:55 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