North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: And Now for Something Completely Different (was Re: IPv6 news)

  • From: Mike Leber
  • Date: Sun Oct 16 06:24:37 2005

On Sun, 16 Oct 2005, Joe Maimon wrote:
> Mike Leber wrote:
> > On Sun, 16 Oct 2005, Joe Maimon wrote:
> > For example, if your goal was to have TCP-like sessions between
> > identifiers survive network events without globally propagating full
> > network topology information about your site (the gripe against classic
> > IPv4 BGP) you could have multiple locators associated with any single
> > identifier sort of like the same way you can have multiple A records for a
> > domain name.  
> Real world shows that that doesnt work very well. Multiple A records is 
> not usuable practicaly speaking for anything other than load balancing, 
> today.

You are missing the point.

Currently multihomed sites have multiple path entries in the routing table 
for a specific multihomed prefix.

Instead of having multiple paths, you would have multiple location records
in DNS.  (Which are A records and any possible reordering by round robbin
is not part of the actual path selection algorithm and which are
associated with indentifiers though a standard to be designed as part of
the new protocol.)

The process of how you select which one to use (and what knobs you have
for tuning) is a design decision, the same way it was with BGP and OSPF.

> > If the location layer session times out then it would try
> > the other locators listed (pick a method of selection) and if it suceeded
> > would resume the session transparent to the identifier layer. Design the
> > timeout and retransmit algorithm and parameters to achieve the convergence
> > times of your choice.
> > 
> DNS is a good example of something that was designed that way, but few 
> people rely on common implementations actualy performing it properly.

BGP and OSPF have timeouts and select other paths.  They give you the
convergence you have now in the event of router failure.  For example, a
BGP session with a peer accross a public exchange has to time out, your
interface is still up.  Yes, you have to engineer the protocol for the
convergence time you want.  Define the goal and figure out the algorithm
to achieve it.

> > You would need a new protocol stack on the hosts at both ends of
> > connections.  By common convention classic TCP hosts could be told to use
> > one of the locators (a transition hack, or just run the protocols in
> > parallel).  No change would be required to the network, and existing TCP
> > could continue to be supported (no flag day).
> Appears to me thats what shim6 is (cursory reading + nanog discussions)

Perhaps a shim6 advocate will explain the differences.

Does shim6 provide separate identifiers from locators?

Does shim6 require new protocol stacks on the hosts at both ends of a
session?  (If not then the source is not making its own path selection

> > Of course support of this new protocol would be limited to the clients and
> > servers that chose to implement it, however this is no less than the
> > change required for IPv6 which some hoped would solve the multihoming
> > problem (possibly defined as scalably supporting network topology change
> > without sessions being interrupted).
> Long story short, seperating endpoint/locator does nothing to allow 
> multiple paths to a single IP6 address/prefix to scale.

Um, this is equivalent to saying "it doesn't work because I say so".

How doesn't it work?  For example you could claim (and then try to defend
your claim):

* It can't possibly converge quick enough because the genius that went
into BGP and OSPF was lost and can never be found again.

* (ok seriously) It can't converge quick enough because the timeout would
have to be X and based on a guestimate of network topology entropy that
would result in Y percent more traffic as each host tries to reestablish
locator sessions.  (Well, then define what percentage of sessions you
think get interruped and support your claim.)

* You throw away real topology information and rely on latency (or
whatever), and using latency doesn't work because it doesn't allow traffic
engineering according to policy. (Who said you have to give everybody the
same set of locators?  Paul might say ewwww.  FWIW, if you want the
ability to tell different peers different answers like with BGP you will
need the ability to give different answers with the new protocol.)


+----------------- H U R R I C A N E - E L E C T R I C -----------------+
| Mike Leber           Direct Internet Connections   Voice 510 580 4100 |
| Hurricane Electric     Web Hosting  Colocation       Fax 510 580 4151 |
| [email protected]                              |