shim6 @ NANOG (forwarded note from John Payne)
jabley at isc.org
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)
More information about the NANOG