[rrg] Locator Path Liveness concerns

[David Meyer]

	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.

	Ok, two loose usages on my part here: First, by
	"available",  I meant published in DNS (contrast
	"reachable"). Second, DNS may not be accurate. Maybe
	third, "complete" might be too strong. 

	So point taken.

	I don't think, however, that this alters my argument.

> 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. 
	Yes, but I'm missing the point. You seem to be saying
	that if things are working, then things are working.

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

	Agreed.


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

	Right, but one point about "routing". In most (most)
	cases, routing is carrying a prefix that is shorter than
	/32 (or /128 if you like). So what routing tells you is
	that someone has in the recent past advertised a prefix
	covering a destination host's address; it doesn't tell
	you whether that destination is up or otherwise
	reachable. 

> 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

	Sure.

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

	Again, it is the details of "if a viable one exists" that
	is my point. 

> [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_.

	Sure, but AFAICT this doesn't solve the locator path
	liveness problem ("if a viable one exists...").

	Good discussion, thnx.

	Dave

	
		
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : <http://www.irtf.org/pipermail/rrg/attachments/20081209/c9aa06ac/attachment-0001.sig>