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

[David Meyer]

	Bill,

>> Start by reading http://bill.herrin.us/network/trrp.html.
>> Don't just scan it. Read it. It's six pages long; it won't
>> kill you. 

	Thanks for the hint. You are right, it is a short
	document, and I'm still alive (by most accounts :-)).  

	That said, I just want to deal with the architectural
	issue that I'm interested here: locator liveness. I have
	a bunch of other questions, but I just stuck them at the
	end of this message because they don't directly deal with
	this particular issue. 

	In any event, you say:	

	  "The ITR finds an Egress Tunnel Router (ETR) for the
	  destination IP address via a DNS lookup."

	and later 

	  "The ITR should look up the route entry when it first
	  sees a packet for the destination. If possible, it
	  should hold packets for the destination in a buffer
	  until a route is found. " 

	(For this discussion, I'm ignoring issues around
	buffering packets while waiting for a mapping, what
	scalability constraints are put on the DNS, the effects
	of having the mapping data be opqaue to the mapping
	system, configuration of p2mp GRE tunnels, ...; see below
	for questions around these things). 

	So what you describe is the well-known, standard
	map-and-encap behavior. A packet hits the ITR, the ITR
	looks up the mapping (existing mapping, DNS, APT, ALT,
	static, or whatever), encaps the packet, sends it to the
	destination ETR. Now, at this point if you have to asses
	reachability somehow, or you can create a persistent
	failure by latching on the wrong "route" (or "routes"; a
	route here is analogous to what folks are calling RLOCs
	in other contexts). 

	Of course, the host can always back off to another EID,
	but if the ITR thinks a "route" (RLOC) that is associated
	with that EID (however that happens) is reachable when it
	isn't and continues to encapsulate packets to that
	"route", then you have a persistant failure. 

	The upshot is that TRRP has the same locator liveness
	problem I've been describing. I'm not at all surprised by
	this, as I am under the impression that this is a general
	property of the Loc/ID split architecture, and not any
	particular proposal. 

	Dave

----

	A few comments on your document (and thanks for pushing
	on me to read it).

	- In "General statement of the solution:"

          " An AS-interior default route leads from the BGP
	  routers to the ITR."

	   Is this saying that there is a default in the
	   site's iBGP or IGP that tells it how to get to the
	   exit points for the site? If so, is this just an
	   implementation detail or a requirement?

	  "The ITR finds an Egress Tunnel Router (ETR) for the
	  destination IP address via a DNS lookup."

	    What destination address? The destination address in
	    the packet emitted by the host? So I saw this:

	     "The ITR should look up the route entry when it
	     first sees a packet for the destination. If
	     possible, it should hold packets for the destination
	     in a buffer until a route is found. "

	   So this is standard map-and-encap behavior (mod
	   holding the packet). I see that you inverse address
	   query for a TXT record associated with the IP address
	   in the destination address in the packet that 
	   the host emitted (this TXT record encodes information
	   about the RLOCs of the ETRs, if you will). Yes? 

	   So at this point if you have to asses reachability
	   somehow, or you can create a persistent failure by
	   latching on the wrong "route" (or "routes"). The host
	   has no visibility into this, so whatever it does is
	   more or less irrelevant. Now, in theory you could
	   snoop data traffic (note GSE can't do this), so you
	   might be able to determine liveness w/o probing, at
	   least for symmetrical (TCP) flows. 

	   The upshot is that TRRP has the same locator liveness
	   problem I've been describing. I'm not at all surprised
	   by this, as I'm under the impression that this is a
	   general property of the Loc/ID split architecture, and
	   not any particular proposal (BTW, it'd be great if
	   someone could show otherwise).

	- "The ITR then tunnels the packet via GRE to the "best"
	   ETR."

	    So the ITR got a set of ETR addresses from the
	    DNS (TXT records) in the previous step, each of which
	    is a candidate site for where it might send the
	    (encapsulated?) packet. Correct?

	    In addition, the ITR gets this list when it inverse
	    address queries for whatever was in the destination
	    of the packet that the host emitted (this is how I
	    understand your use of the DNS). It encapsulates this
	    packet over GRE to the destination found in the TXT
	    record (with some processing of the options in the
	    TXT record). Correct? 

	    If so, how does the ITR know which ETRs its going to
	    talk to (in order to set up the GRE tunnels)? Or does
	    the ITR not set up s GRE tunnel between the ITR and
	    ETR? Or did you mean some kind of dynamic GRE (i.e.,
	    just uses GRE encap, or ?). 

	    I see from this example that its the ETR that sets up
	    a p2mp tunnel:

		Cisco IOS configuration example:

		interface Tunnel0
		  description TRRP Egress Tunnel Router
		  no ip address
		  tunnel source FastEthernet0/0
		  tunnel mode gre multipoint
		  tunnel key 1

	   makes it seem lile the ETR will need to know where all
	   the other ITRs that might want to talk to it are. How
	   does that work?


	- "The ETR, which must have an IP address within space
	   announced via BGP, knows a local-scope route to the 
	   destination IP address and delivers the packet. "

	   That makes sense. The IGP (or possibly iBGP) knows how
	   to how to route packets within the domain (that's the
	   point of the IGP, AFAIK). Anyway, that makes sense.

	- "Longer route prefixes are then withdrawn from BGP
	   until a comfortable BGP table size is attained."  

	   I couldn't get that to follow from what you said, or
	   how it works.

	- Other notes:

	(i).	dig couldn't find a nameserver for either
	        v4.trrp.arpa or v6.trrp.arpa, or
		v4.trrp.in-addr.arpa or v6.trrp.in-addr.arpa 
	
	(ii).	The term "route" is somehow overloaded in your
		document. In particular, when you're talking
		about the TXT record encoding, you overview the
		encoding as 'pp,ii,route pp,ii,route ..." and in
		the encoding you have stuff like 

		  00 = always prefer this route
		  40 = prefer this route
		  80 = normal
		  b0 = avoid this route
		  ff = use this route only as a last resort

		These are really the decapsulation point for the
		source packet that's about to be encapped. Its
		not really a route (or doesn't seem to be to me);
		you really don't care what path the packet takes
		(within reason), you just care that the packet
		can tet to the "route" to be decapsulated. Yes?

	(iii).	Host unreachables

		You say that the ETR needs to unreachables do to 
		the insecurity of ICMP. You suggest sending ICMP
		echo-request. This is another form of searching
		(with data probes) for locator liveness. In
		addition, if the destination is unreachable, you
		take it down for 5 minutes (mod you see traffic
		for it). That's a failure mode we don't have in
		the internet today; if the host is unreachable
		due to, say, a routing anomaly, it becomes
		reachable when routing converges. You're scheme
		doesn't. Note here that I'm just observing the
		properties of the mechanism you propose and
		comparing that to what we see today.


	(iv).	BGP with the "Holey Route Authority"

		You say:

		  A central route authority keeps track of all
		  holey routes and peers them with all ASes which
		  implement an ITR. Each such AS implements a
		  route-map to force those prefixes to head the
		  same direction as the default route.

		All I can say is that hasn't worked to date.

	(v).	Preemptive Change Notification (PCN)

		You say (PCN Type 1): 

		  PCN Type 1: Notification of change by the DNS
		  server The authoritative DNS Route server
		  remembers all IP addresses which requested each
		  Route entry during the entry's TTL. Immediately
		  upon the Route entry's change, the Route Server
		  sends a UDP message to port XX of the
		  requestor. The first byte of the message is
		  0x01. The remaining bytes are the DNS query
		  which should immediately expire. 

		Can you comment on the scaling propeties of this?

	I'll stop here.

	Anyway, I hope this gets us going a bit.

	Thanks,

	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/20081223/402a39c2/attachment-0001.sig>