> a) When an ETR sends a Map-Register to a Map Server, does the ETR have
> to include all the RLOCs associated with the EID-prefix and
> specifically even those not associated with that particular ETR? From
> what I understood from the draft, the RLOCs are used to either forward
> Map-Requests to the ETR as indicated in Sec. 3
> "Intermediate ALT routers forward Map-Requests to the Map-Server
> that advertises a particular EID-prefix and the Map-Server forwards
> them to the owning ETR, which responds with Map-Reply messages."
>
> or, as specified in Sec 4.4, to directly provide the RLOCs in a Map-Reply:
> "Upon receipt of an Encapsulated Map-Request, a Map-Resolver de-
> capsulates the enclosed message then searches for the requested EID
> in its local database of mapping entries (statically configured,
> cached, or learned from associated ETRs). If it finds a matching
> entry, it returns a non-authoritative LISP Map-Reply with the known
> mapping."
>
> I don't see any language that explicitly defines what set of RLOCs
> should be included.
The full list of RLOCs is returned in a Map-Reply from an ETR to an ITR.
An ETR is not required to supply the full set of RLOCs when it registers
with a Map-Server; the ETR need only need provide those RLOCs that it wishes
the MS to use when forwarding a Map-Request to the ETR.
> b) What does a Map-Server do when it gets Map-Register messages from
> different ETRs for the same EID-prefix? This seems to me to be a
> likely case where for resiliency there could be 2 ETRs and each would
> register with two Map-Servers. Even if all the RLOCs are supposed to
> be included, what happens when there is a chance and one ETR is
> (temporarily) out of sync with the other?
Each ETR for a particular EID-prefix is expected to register with all of
the Map-Servers that publish that prefix into the mapping database. When
a Map-Server receives an Encapsulated Map-Request for that prefix, it sends
to one of the registered ETRs. The exact process that it uses for distributing
the Map-Request load among multiple registered ETRs is not specified but
round robin would be a reasonable choice. If one ETR has out-of-date
information relative to the others, then yes, temporary inconsistencies
may result, just as is the case with any other distributed database (i.e.
multi-homed sites connected via BGP).
> c) If an ETR is supposed to send all the RLOCs associated with an
> EID-prefix in a Map-Register message, then how is the R-bit for each
> locator record specified by the Map-Server? Does the Map-Server
> confirm reachability to each of the RLOCs specified before sending any
> Map-Replies?
I will have to defer to Dino to answer this detail.
> d) The Map-Server is described in the Introduction as:
> "a Map-Server, which learns authoritative EID-to-RLOC mappings from
> an ETR and publish them in the database."
> I found this confusing, since the mapping service seems to me to be
> about determining which ETR (or proxy) to ask for the EID-to-RLOC
> mapping and is providing an lookup service to get to the ETR and not
> necessarily the full RLOC mapping.
Please suggest alternative text.
> e) For clarification, why does a Map-Resolver return a Map-Reply for
> EID-prefixes in its local database? I could see doing that if the ETR
> had requested proxying, but if not - why is there a potential
> difference in what is returned for a local Map-Request versus a remote
> one? As I understand it, in the remote case, the Map-Request is
> unencapsulated (as per Sec 4.4 (1)) and is therefore handed to the ETR.
A single device may act as both a Map-Server and a Map-Resolver. In such
a situation, a Map-Resolver will consult its local database to see if it
is also configured as a Map-Server for the EID-prefix being requested.
> f) Further, the appropriate behavior of a Map-Resolver when proxying
> is requested is NOT specified anywhere.
Please provide suggested text to describe this behavior.
> g) On p.6, a negative LISP Map-Reply is sent, but the details of the
> action selected is not defined anywhere. I assume that the draft
> means to specify as natively forward, but as written I did not find it
> clear (perhaps because I didn't have the Map-Reply packet format
> memorized).
I will reword this section to reference the action codes defined in the
LISP base document.
> h) What is the purpose of frequently (1/min) resending the
> Map-Register message? It is only verifying that the ETR still owns
> the EID-prefix? If it is verifying liveness - why is that ETR special
> compared to others whose RLOCs are also given. Why not depend on the
> underlying routing to be sure of liveness?
It is a simple keepalive mechanism between an MS and an ETR to ensure that
not only is the ETR reachable but that it both responsive and wants the MS
to continue to publish its EID prefixes in the mapping database. Underlying
routing would not accomplish this.
>
> i) typo on p.8 item (1), 3rd line: "mapaping" -> "mapping"
>
> j) typo in 2nd paragraph, last sentence in Sec 4.1:
> "Using the Map-Resolver greatly reduces both the complexity of the
> ITR implementation the costs associated with its operation."
> ^^
> and
Thanks, fixed in -09.
--Vince
(for the other co-authors)
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
