shim6 @ NANOG (forwarded note from John Payne)

Wed Mar 1 17:40:38 UTC 2006

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

> --- Joe Abley <jabley at isc.org> 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
>> re-homing
>> 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
>> peers.
>
> And maintain 120 different context tables on each
> host?

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.

Joe