Vince, Thanks for the response. My comments are in-line.
On Thu, Jun 23, 2011 at 6:15 PM, Vince Fuller <[email protected]> wrote: >> 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. OK - my concern is that a Map-Server may implement both types of actions - as a Map-Resolver and a Map-Server. ("A single device may implement one or both types of operation.") In Sec 4.4, it says that Map-Resolver may use "its local database of mapping entries (statically configured, cached, or learned from associated ETRs)". However, I saw no discussion of how a Map-Resolver might learn mappings from associated ETRs. I therefore assumed that "learned from associated ETRs" is via the Map-Register messages that an ETR would send. I don't know how an ETR would know whether its Map-Server is serving as a Map-Resolver as well, except via manual configuration. Therefore, I think it would be very useful to add explicitly "When an ETR sends a Map-Register message to a Map-Server, the ETR MUST include at least one locator, but need not include the full locator-set. These records, stored by a Map-Server, should be used for directing Map-Requests and SHOULD NOT be used in a Map-Resolver operation." in Sec 4.2 >> 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). Ok - makes sense. Thanks for the clarification. >> 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. Ok - I think I meant the Map-Resolver operation here. >> 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. "a Map-Server, which learns the authoritative ownership of EID-prefixes by ETRs from those ETRs and publishes those EID-prefixes in the database." Feel free to word-smith >> 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. Do you mean configured to proxy-reply? Is that the only case where you think a Map-Resolver should respond itself? Could you clearly state that? It seems like a Map-Resolver could have lots of things in its local database (cached, statically configured, etc.) as per Sec 4.4. >> 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. Here's the start of text to go towards the end of Sec. 4.2: "When an ETR sets the proxy-map-request bit in its Map-Register, the ETR MUST include complete locator-set(s) in the included record. The ETR MUST set the L-bit associated with at least one locator; this will be used by the Map-Server to verify reachability and to forward Map-Requests when proxying is not feasible. An ETR SHOULD be able to provide Map-Replies even when it has requested proxying. When an ETR's registration is removed by the Map-Server, of course no more proxying is done by the Map-Server. If a Map-Server can no longer reach the source RLOC from which the ETR sent the most recent Map-Register message, then the Map-Server should pause in proxying until reachability is restored. When a Map-Server sends a proxied Map-Reply in response to a Map-Request, as specified in [LISP], it clears the Authoritative bit in the message and clears the L bits associated with each locator. To properly set the R-bits associated with each locator, a Map-Server SHOULD determine if it has a current valid route to the specified RLOC and set the R-bit for that locator to 1 if so and 0 otherwise. To determine the Record TTL to be sent in a proxied Map-Reply, the Record TTL that is included in the Map-Register message should be decreased by the number of seconds since the last Map-Register message was received. This is to better support mechanisms such as Clock Sweep [LISP]" I do have two open questions around the correct behavior. i) Should the Record TTL just be set to what is sent instead of being decremented? If an ETR is doing Clock Sweep, shouldn't that ETR also send out updated Map-Register messages? ii) How should overlapping prefixes be handled? I.e. does an ETR send a Map-Register with all the EID-prefixes and then the Map-Server determines which need to be sent in response to a Map-Request? Should a Map-Server just send the whole record that was registered for any match within it? I can see the argument both ways and would, naturally, like to know your thoughts. >> 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. Thanks - the problem with not having this all embedded in memory already. >> 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. Ok - seems a bit heavy-weight to me, but it does work for that. If you wanted to add that first sentence in, I'd cheer :-) Thanks, Alia >> >> 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
