Vince, Thanks for the responses - comments in-line.
On Thu, Jun 23, 2011 at 5:46 PM, Vince Fuller <[email protected]> wrote: > On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote: >> This is a very well written and clear document. I think it is in good >> shape. >> >> I do have a few questions: >> >> a) In Sec. 4.1, >> "This "first hop" ALT Router uses EID-prefix routing information >> learned from other ALT Routers via BGP to guide the packet to the >> ETR which "owns" the prefix." >> >> If an ETR provides more than 1 RLOC for an EID-prefix or multiple ETRs >> provide different RLOCs, how does the ALT Router decide which to use >> to guide the packet to the ETR? Does the ALT Router determine >> that the ETR is reachable? >> >> Perhaps this is a question better asked of draft-ietf-lisp-ms, but I >> do not see it addressed there either and the guiding of the >> unencapsulated Map-Request appears to be left to the ALT >> infrastructure. > > I don't understand this question. The forwarding table on an ALT router is > composed of EID prefixes with next hops over tunnels to other ALT routers. > RLOCs are not used when forwarding ALT Datagrams. If an ETR connects to > the ALT (which is rarely done; ETRs usually register their prefixes with > Map Servers rather than participating in the ALT directly), then it does > so with tunnels to other ALT routers. An ALT Datagram destined to that > ETR (i.e. one which has a destination IP address that matches the EID > prefix advertised into the ALT by the ETR) will be forwarded to a tunnel > endpoint address on that ETR, not to an ETR RLOC. Thanks - this was my confusion. I got the question from the [MS] draft and clearly dropped a bit of context. >> b) How can an ETR tell if the outer header Source Address of an ALT >> datagram is an RLOC or an EID? I do see that using an EID is not >> supported by initial LISP+ALT implementations (this could be pulled >> early in the draft where the idea is first proposed), but I also don't >> see a mechanism to do the disambiguation. > > The ETR does not attempt to determine whether the outer header source > address is an RLOC or an EID; when it sends a Map-Reply to that address, > it simply forwards it using the contents of its forwarding table. If the > original source address was an EID and the ETR is connected to the ALT > (again, this is a rare, degenerate case; ITRs and ETRs do not normally > connect directly to the ALT), then the Map-Reply will be sent back over > the ALT, which is not recommended and may or may not acheive the desired > result. This question was in reference to the last paragraph in Sec 3: "The term "ALT Datagram" is short-hand for a Map-Request or Data Probe to be sent into or forwarded on the ALT. Note that while the outer header Source Address of an ALT Datagram is currently expected to be an RLOC, there may be situations (e.g. for experimentation with caching in intermediate ALT nodes) where an EID would be used to force a Map-Reply to be routed back through the ALT. " I think the base of the question is whether the ETR can just know if a given bit-pattern is an EID by seeing if it is in the mapping database. This comes back to the general question that I've been discussing with Joel, Dino & Noel on the list. If the ETR can't tell whether a source address is an EID - and therefore to be routed back to ALT - or an RLOC - and therefore to be routed across the current internet, then there is a problem. IF the assumption is that a given bit-pattern cannot refer to different sites/endhosts by one use being a RLOC and the other an EID, then I think this concern is partially addressed - but that assumption NEEDS to be written down into the base LISP draft. As I understand it, an ETR (not co-located with an ITR) would not have direct access to the mapping database & may not even support sending Map-Requests. This implies that the ETR would need to send any Map-Replies out via an ITR that would do this look-up?? Is this the expected behavior? I'd prefer to see a short explicit description of rules and behavior around this. Certainly, the need for the ETR to route its Map-Replies via an ITR was not clear. The main confusion, of course, is differing assumptions about what different name-spaces mean in practice. >> c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide >> that it does not wish to store such more-specific information, it has >> the option of discarding it as long as a shorter, covering EID-prefix >> exists." I found this confusing and it seems to violate the prefix >> rules in [LISP], as well as they were described. > > If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more- > specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic > would be LISP-encapsulated and sent to one of the RLOCs for the covering > map cache. This is no different than the way a shorter prefix can be used > for IP forwarding to any more-specifics of that prefix. I have pulled my response into a separate email. As far as I can tell, this behavior would cause the ETR to drop traffic. I understand that the context of the section is TE - but do not see that context resolving the problem. >> d) In [LISP] sec 5.5., there is discussion of using Instance IDs to >> disambiguate. "When multiple organizations inside of a LISP site are >> using private addresses [RFC1918] as EID-prefixes, their address >> spaces MUST remain segregated due to possible address duplication. An >> Instance ID in the address encoding can aid in making the entire AFI >> based address unique. See IANA Considerations Section 14.1 for >> details for possible address encodings." >> >> I am not suggesting adding explicit support for this at this point, but >> adding a caveat that supporting this is for future study & experimentation >> would provide clarity. > > The use of instance IDs is outside of the scope of the ALT document. OK - it is hard to tell what parts in the base spec are must-implement and what are the fragments of an undeveloped idea. Thanks, Alia >> f) Typo in 2nd to last paragraph on p.20: >> "This is, by no means, and exhaustive list." >> ^^^ >> an > > Thanks. Fixed in the -07 draft, which will be published shortly. > > --Vince > (on behalf of the other co-authors) > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
