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