RE: network controls are necessary

["Tony Li" <Tony.Li@procket.com>]

Bill,


|   > |   Maybe a site could withdraw the identifier->locator 
|   mapping when a
|   > |   link is known to have lost connectivity, but that 
|   clearly limits
|   > |   what can be done to cache identifier-locator mappings..
|   > 
|   > Oy.  I think the thought was that the routing system 
|   would detect the
|   > loss of connectivity via the locator and would send an 
|   ICMP unreachable,
|   > which would then trigger a switch to an alternate locator.
|   
|   I thought of that sort of mechanism but immediately 
|   dismissed it; it's
|   got a track record of failing miserably in the as-built Internet[1].
|   I'm skeptical that this would be effective without some sort of
|   black-hole detection (rotating to a new locator after a couple RTO's
|   of silence?).
|   
|   [1] Path MTU discovery.  Try surfing the web with a <1500 MTU
|   bottleneck in the path some time.  PPPoE implementations 
|   which rewrite
|   TCP MSS options don't count.


Path MTU is a case where the network needs to signal back to the host and
the host needs to respond to the signal.  Part of the reason that this
isn't solid is that many host implementations don't respond correctly.

The case that we're talking about is the reverse: the host detects the
problem and then signals its SBR.  Yes, this would require black hole
detection on the part of the host.  It would then signal to its SBR to
force a locator change.  I cannot think of a single mechanism
today that would be analogous to this.  

Does that help?

Tony