> Correct, what is of interest is to have some sense of the likelihood of the > mapping received changing and allow the ITR to check again. We are looking at > the NMR as one way to indicate back to the ITR the nature
Sounds like one way is using draft-rodrigueznatal-lisp-pubsub-00. Then the ITR doesn’t have to poll. > of the mapping. Because the ITR can differentiate clearly between an NMR and > a Positive MR, it can choose I am not convinced it needs to treat the mappings differently. You probably want the logic simple in the ITRs. That is, lookup a destination in the map-cache and encapsulate (and nothting more). > to treat the mappings differently. For example (maybe this is implementation > specific) the cache-TTL assigned to the mapping received in an NMR may be in > the order of minutes, vs. a mapping from a positive MR having a TTL in the > order of hours.. That is something that the replier can control. Maybe you have a third-party that ligs non-EIDs, and when the length of the negative prefix changes, then a new mapping is registered, or you change the RLOC set of the existing mapping. In either case, pubsub will cause a map-server to Map-Notify the ITRs that are interested. >> I would not call these negative map-replies though. By definition, from the >> spec, a negative map-reply is a map-reply with an RLOC-count of 0. > > What I am after is a map reply with the characteristics of an NMR (short TTL, > dynamically calculated covering prefix for non-EID destination), but an > RLOC-count > 0. If there is a way to encode this with a Positive MR, then we > are covered. ODL ;-) Like I referneced above. > >> What many implemenationsn do is when they get a map-reply with an RLOC set >> of 0, they then decide, via configuration to encapsulate to a list of xTRs. >> Those xTRs are PETRs (by definition of the implementation). > > We are trying to avoid the “decide, via configuration, to encapsulate to a > list of xTRs”, but still have the ITR give the map-cache a short TTL. Completely understand. A good goal to go after. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
