[rrg] FYI: Architectural Implications of Locator/ID Separation - draft-meyer-loc-id-implications

[David Meyer]

	Bill,

	Before diving in here, a few people mentioned that I
	should have put the following in front of my last post
	(to Robin) instead of at the end:

	  Based on your comments, it seems to me that you didn't
	  understand that the purpose of the draft was to more
	  deeply understand the architectural implications of
	  Loc/ID split, not to advocate for or against any
	  particular proposal. 

	That said:

> What I proposed in TRRP, and I *think* what Robin proposed in Ivip, is
> that the choice to switch between locators should be driven by a
> heuristic system external to the protocol itself.
>
> The destination system uses this external heuristic to choose its
> locators, and the source system blindly follows the destination
> system's instruction. If the path between the source and destination
> locators is dead, it's up to the destination to figure this out (using
> the external heuristic system) and alter its locator to one that
> works.
> 
> Examples of such a heuristic include:
> 
> 1. I think my Internet link is bunged up, so I press the "switch
> locators" button and that alters my map entry.

	What does "alters my map entry" mean? Who does it, on
	what time scale, who has visibility into data and when,
	what bits get sent where, etc. You get the picture. 

	What we need to see detail, precisely because that is
	where the problems arise. From that perspective, "alters
	my map entry" is almost (if not completely) content free.
	
> 2. A monitoring system at my network border polls external public
> probe sites and watches for retransmission in the TCP sessions which
> pass by it. If the failure rate exceeds the programmed threshold, it
> decides my Internet link is bunged up and alters my map entry to favor
> a different locator.

	Really? You want to put the dependency that routers (or
	something) must snoop the data plane for TCP state to
	make connectivity work? Notwithstanding the wisdom of
	introducing that dependency, what if traffic is
	unidirectional (or otherwise asymmetric), UDP, or ...
	And what if its multiple 10GE fire hoses blasting data at
	you? 

	I won't even start down the security/privacy path with
	that one.

> 3. A globe-spanning Akamai-like system of testpoints builds a complex
> map of Internet path states. Combined with some basic information
> about the state of my connections to my ISPs, it can compute what will
> usually be a good current locator selection for me. I subscribe to
> this service.

	If you can't reach the endpoints (good or bad), none of 3.
	matters; not I think that making the network layer depend
	on this kind infrastructure, and not to mention the
	circular dependency that could arise. 

	But again, these high level descriptions of how something
	that is largely unspecified (notably the "heuristic system
	external to the protocol itself") doesn't help me
	understand (i). what mechanism you are proposing,
	(ii). what its properties are, and (iii). if it even
	works.  

	OTOH, what would be helpful would be for you and/or Robin
	to describe  *the mechanism and how it works, in detail*
	that you are proposing, then show how it solves the
	simple example problem in Section 3 (Figure 1) for the
	draft. 

> This approach addresses the locator liveness problem by substituting a
> heuristic for an algorithm. It accepts that while the result will
> usually be good enough it won't always be perfect and may rarely
> require intervention.

	I guess I'm not understanding, primarily it seems since
	you haven't given any detail about how this would
	actually work. 

	My point is that  statements like "substituting a
	heuristic for an algorithm" don't really enighten us as
	to the solutions (or their properties) that you are
	proposing.  

	Please give details so we can understand.

	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/20081222/c7691217/attachment.sig>