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 12:42:03 2006

On 1-Mar-2006, at 11:55, David Barak wrote:

--- Joe Abley <[email protected]> wrote:
I'm just one guy, one ASN, and one content/hosting
network. But I
can tell you that to switch to using shim6 instead
of BGP speaking
would be a complete overhaul of how we do things.
You are not alone in fearing change.
It isn't fearing change to ask the question "it's not
broken today, why should I fix it?"
What's broken today is that there's no mechanism available for people who don't qualify for v6 PI space to multi-home. That's what shim6 is trying to fix.

It seems reasonable to say that in some cases shim6
transitions will be faster than the equivalent
routing transition in
v4; in other cases it will be shorter. Depends on
the network, and
how enthusiastically you flap, perhaps.
A - X - Y - B
  \ |  \ | /
    W  - Z

A and B are hosts, W-Z are ISPs

On what basis would you say that in the event of a
network outage in Y, communication between A and B
will be faster than the routing transition?
That's an example of a simple topology where the routing system might be expected to reconverge rapidly.

However, it's not hard to find examples in today's v4 Internet where reconvergence following a re-homing event can take 30 to 60 seconds to occur. In the case where such an event includes some interface flapping, it's not that uncommon to see paths suppressed due to dampening for 20-30 minutes.

I would expect (in some future, hypothetical implementation of shim6) that the default failure detection timers to start rotating through the locator set far sooner than 30-60 seconds.

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
And maintain 120 different context tables on each
No; maintain one address per PA netblock on each host.

You avoid it completely, and use PA space in every
POP. You can still
announce PA space from other POPs to peers, if you
want to retain
your tunnels.
Wait a second - doesn't that deaggregation bring back
the "lots of small routes" business which the whole v6
hierarchical addressing model was supposed to fix?  If
we're in the world of deaggregates anyway, why not
just ditch the addressing model instead of accepting
its limitations in this way?
There's a vast difference in impact on the state held in the core between deaggregating towards direct peers, and deaggregating towards transit providers and having the deaggregated swamp propagated globally.