After double checking with the diff and with Dino, it seems that the first two points have been addressed already. Please find the rest below and feel free to comment.
Alberto >> Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the >> inner-header destination address equals the outer-header destination >> address used to trigger a Map-Reply by a decapsulating ETR. >> >> [AR] Is anyone using data-probes? I’d like to suggest removing this text. > > (3) response. > > Early on in the LISP design, service providers thought this was useful. We > have carefully doctored the text to make it security safe, but it does avoid > packet loss when setting up a first-time round-trip packet exchange. The > initiator’s packet causes the mapping database lookup, but the return packet > does not need a lookup. > > There might be specialized applications that may make use of it. > >> Since the LISP architecture uses a caching scheme to retrieve and >> store EID-to-RLOC mappings, the only way an ITR can get a more >> up-to-date mapping is to re-request the mapping. >> >> [AR] We could relax this constrain and/or reference PubSub here. > > Response (2). > > Want the WG to decide if this individual submission should be referenced. I > think the pubsub design is simple and can work but we have little > implementation experience with it thusfar. > >> When adding a new Locator record in lexicographic order to the end of >> a Locator-Set, it is easy to update mappings. We assume that new >> mappings will maintain the same Locator ordering as the old mapping >> but will just have new Locators appended to the end of the list. So, >> some ITRs can have a new mapping while other ITRs have only an old >> mapping that is used until they time out. When an ITR has only an old >> mapping but detects bits set in the Locator-Status-Bits that >> correspond to Locators beyond the list it has cached, it simply >> ignores them. >> >> [AR] Probably we could complement this paragraph with something like >> "It is RECOMMENDED to notify the ITRs that they should update their >> Map-Caches, e.g. via an SMR.” > > Response (3). > > We say this in other sections about updating mappings. In this paragraph, > there is a primary focus on locator-status-bits. > >> When a Locator record is removed from a Locator-Set, ITRs that have >> the mapping cached will not use the removed Locator because the xTRs >> will set the Locator-Status-Bit to 0. >> >> [AR] Since LSB are not mandatory and not used in many deployments we >> should recommend notifying the affected ITRs via SMRs or PubSub. > > Response (3). > > The WG should discuss this. If you want to keep the locator-set in tact in > the ITR, using LSBs is a faster way to convey to not use a subset of the set. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
