[rrg] Locator Path Liveness concerns

[David Conrad]

Dave,

On Dec 9, 2008, at 7:46 AM, David Meyer wrote:
> 	In today's world, hosts have pretty much complete
> 	information about which <source,destination> pairs are
> 	available.

Not to do my Bill Manning imitation, but I suspect this isn't fully  
accurate.  We have a set of assertions about destinations that may or  
may not be accurate at any given point in time, constrained by BGP  
propagation delays, IGP convergence, DNS cache expiration, DNS  
authoritative updates, etc.

In the steady state, I would agree with your statement.  However, in  
the steady state, it doesn't matter all that much.  Where stuff gets  
interesting is when you've got (lots of) transitions.  Much (all?) of  
the concern regarding locator path liveness in is detecting these  
transitions and providing sufficient information to active path  
components to make alternative decisions in some reasonable amount of  
time.  My impression is that one of the drivers behind concerns about  
routing system scaling is, in fact, the worry that the time to  
converge on an alternative will become unreasonable.

> 	In  map-and-encap schemes, the host doesn't know how many
> 	"ways" there are to reach a remote ID (i.e., how many
> 	RLOCs there are, or if they are reachable), so it can't
> 	implement a strategy test reachability to the
> 	correspondent (note that even TCP timeout doesn't help
> 	here, unless there the host  finds another EID that maps
> 	to a different RLOC set).

Right, since the host is 'protected' from knowledge of the underlying  
topology.  Looking at this simplistically, assume you have a locator  
routing system that looks like today's routing system and a mapping  
system that fetches statically configured EID to (one or more) RLOC  
mappings.  At any point within the source locator to destination  
locator path, routers make decisions based on the destination locator  
according to information propagated via BGP.  If a BGP update  
indicates that the destination locator is no longer available, the  
router doing the forwarding has two choices:

1) drop the packet on the floor and wait for someone upstream (e.g.,  
the originating ITR) to notice (perhaps after being prodded) and stop  
using the bad destination locator
2) pop the encapsulation (keeping the source locator), re-do the  
lookup of the destination EID to discover all possible locators, use  
information at that router to pick a new destination locator and, if a  
viable one exists, re-encapsulate using the new destination locator  
and the original source locator.

[waiting while the screams of horror and outrage at choice 2 die down.]

My impression is that efforts on LOC/ID separation have been focused  
on the first choice (for valid reasons), however the second choice  
more closely mirrors the behavior of the existing routing system in  
which every router can make routing decisions based on the destination  
_identifier_.

Regards,
-drc