Ack on the new version. Thanks Dino. Alberto
On Fri, Dec 15, 2017 at 12:12 PM, Dino Farinacci <farina...@gmail.com> wrote: > Enclosed is the latest revision of RFC6833bis-07. Thanks for closing the loop > Alberto. If you can ack the new changes, I’ll submit -07 this weekend. > >> On Dec 7, 2017, at 11:06 PM, Alberto Rodriguez-Natal >> <rodriguezna...@gmail.com> wrote: >> >> 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. > > No prob. See my responses. > >> >>>> 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. > > I added a brief definitions of each to be consistent with Map-Register and > Map-Notify definitions that are already there. > >> >>>> 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. > > I removed all occurrences of “globally routable” to “routable”. > >> >>>> 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. > > It is not optional. And this section of the draft defines the details. And > the section includes a MUST. > >> >> >>>> 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. > > I added a few sentences. > > Thanks, > Dino > > > > > > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
