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: David Barak
  • Date: Wed Mar 01 11:56:46 2006
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=klvgZQiMx4vkop61CBQqj/X2BsJ08kvOpBY4V3tp+i/S4c1a3xV0jDznOOhT9imjcXnykNZeQstwReQhilnDLBCj2fu6BiImutvtCuyNTdpZdNWGk9fi4SL5PcSOTu4ZXkp/lVxFpMU+OuPTUjqaGbvfxL8KY+kudXDqw1oNbcw= ;


--- 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?"

> This is the kind of feedback that the shim6
> architects need. There is  
> talk at present of whether the protocol needs to be
> able to  
> accommodate a site-policy middlebox function to
> enforce site policy  
> in the event that host behaviour needs to be
> controlled. The scope of  
> that policy mediation function depends strongly on
> people like you  
> saying "at a high level, this is the kind of
> decision I am not happy  
> with the hosts making".

Resounding YES - I specifically DON'T want end-hosts
to be able to make these decisions, but need to be
able to multihome.

 
> > We deal with long lived TCP sessions (hours/days).
> I don't see how  
> > routing updates can happen that won't result in a
> disconnect/ 
> > reconnect, which isn't acceptable.
> 
> One of the primary objectives of shim6 is to provide
> session  
> survivability over re-homing events. Since routing
> protocols are not  
> used to manage re-homing, the speed at which a
> session can recover  
> from a topological event depends on the operation of
> the shim6  
> protocol between client and server.
> 
> 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?



> 
> The experience of people who provide services
> involving long-held TCP  
> sessions is exactly the kind of thing that the shim6
> architects need  
> to hear about.
> 
> > 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?  ouch.  I'm guessing that server vendors are
going to be quite happy with this.

> 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?

-David

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com