Hey Dino, Sorry for the delay on this. Mostly agree with your responses, thanks for the edits!
There a few points that I would like to clarify. See below. >> For definitions of other terms -- notably Map-Request, Map-Reply, >> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >> >> • [AR] I think that the definitions for Map-Request and Map-Reply >> should be moved here, and probably we should include the definition >> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >> control-plane messages, not the other way around. > > They did. But the text you identified above was not changed. Changed now. I meant that Map-Request and Map-Reply are not defined here (or anywhere else that I can find) and they should. The closest things are Encapsulated Map-Request and Negative Map Reply. >> The RLOCs in the Map-Reply are globally routable IP addresses of all >> ETRs for the LISP site. >> >> • [AR] We should remove "globally" here. Maybe also add a >> "Generally" at the beginning since we might have LCAFs with AFI = 0 >> (LISP-VPN encoding of Home-IID for instance). > > Removed “globally”. I don’t understand your other “Generally” comment. My point was that in the LISP-VPN draft the Home-IID is encoded as an RLOC that it is not a routable address for the ETR. >> For example, a requester with two cached EID-Prefixes that are covered >> by a Map-Reply containing one less-specific prefix replaces the entry >> with the less-specific EID-Prefix. >> >> • [AR] Not sure if I follow here. Does this mean that a >> less-specific received in a Map-Reply will erase from the map-cache >> previously cached more-specifics that are covered by the >> less-specific? > > Yes, because if the Map-Reply returned a more-specific with the > less-specific, then it would be replaced so the less-specific replaces the > more-specifics that ARE NOT in the Map-Reply. I think that I would rephrase this behavior to make it optional then. There are implementations which just return the entry that the requested EID hits and don't return by default any more-specifics below. >> When more than one EID-Prefix is returned, all SHOULD use the same >> Time to Live value so they can all time out at the same time. When a >> more-specific EID-Prefix is received later, its Time to Live value in >> the Map-Reply record can be stored even when other less-specific >> entries exist. >> >> • [AR] We should explain in which cases a more-specific can be >> received later. > > I don’t follow. Each EID-record will contain a TTL for the length prefix that > is encoded. So the new Map-Reply TTL will be used for any length entry (and > in this case the more-specific). My concern was that we should provide some context on when an ITR may receive a more-specific prefix that overlaps with an existing less-specific prefix already in its map-cache. One example is the EID mobility draft, we can reference it here. Thanks! Alberto _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
