> -----Message d'origine----- >> De : Dino Farinacci [mailto:[email protected]] >> Envoyé : jeudi 19 octobre 2017 15:21 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : [email protected] list >> Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00 >> >> What if we provided you with a more efficient feature. That is: >> >> (1) The ITR sends a Map-Request for 0.0.0.0/0. >> (2) But rather than the mapping system return a RLOC-set for 0.0.0.0/0 >> (which may or may not be registered), it returns all more specifics? >> (3) The ITR would request a lookup-type of “return *all* more specifics” >> versus an longest or exact match lookup. >> > > [Med] I like this one, but I'd like also to let the ITR encloses specific > EIDs in the same request.
Yes, that would be supported based on the existing text. This mechanism would have the lookup type per EID-record. So you could put 2 EIDs in a Map-Request where one would be a “return all more specifics” and the other “exact match”. >> Here is my justification. And I made this comment to you a couple of years >> ago. If an ITR is going to provide a list of EIDs to lookup when it >> restarts, one has to ask how does it know which EIDs to request. If it has >> a list, that means there was some implementation capability to write a >> checkpoint or stateful file of entries. So when an ITR restarts, it has >> that list. > > [Med] What we have investigated is to configure the ITR upon reboot with > popular prefixes (without even requiring persistent storage of the EIDs > list). We had designed a YANG module which is meant to populate a policy > table on the So there is a feature in LISP where you can put “send-map-request” action entries in the map-cache. And when the ITR boots you can go ask for them. > ITR so that popular EIDs can be retrieved immediately after state > loss/reboot. The purpose was to avoid the first packet loss issue. An excerpt > of the tree model is provided below. Like I said before, if the ITR implementation would cache in a checkpoint file the entries that have been used, you have your list when you reboot. That is another mechanism. > ==================== > module: ietf-ms-policy-table > +--rw ms-pt-config > | +--rw description? string > | +--rw rfc6724-enable? boolean > | +--rw ms-pt-list > | +--rw ms-pt-entry* [id] > | +--rw id uint32 > | +--rw Name? string > | +--rw Description? string > | +--rw eid eid-id > | +--rw map-resolver inet:ip-address > | +--rw priority? uint32 > | +--rw status? enumeration > | +--rw validity-date? yang:date-and-time > ====== > >> >> Well, if it builds this checkpoint file, it could also store the RLOC-set, >> so it would have all the mappings, maybe out of date, but it could query >> the mapping system when the demand sees the need. > > [Med] Actually, we wanted to avoid waiting for a packet to show up for > creating mappings for popular EIDs in a LISP domain. Right, it is a “request to push”. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
