Hi Dino, Please see inline.
Cheers, Med > -----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. > 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 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. ==================== 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. > > I have an implementation of this and when I brought this up a couple of > years ago, I offered you to try it out. > > But if one doesn’t want to go the checkpoint file route or have a protocol > mechanism, the “lookup-type” functionality would be useful. Albert, Vina, > and I have talked about creating a new LCAF type that is essentially > “Lookup-Type LCAF” which requests “all-more-specific”, “more-specific”, > “exact-match” lookup types. > > Comments? > > Dino > > > On Oct 18, 2017, at 1:09 AM, [email protected] wrote: > > > > Hi Dino, > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Dino Farinacci [mailto:[email protected]] > >> Envoyé : lundi 16 octobre 2017 15:08 > >> À : BOUCADAIR Mohamed IMT/OLN > >> Cc : [email protected] list > >> Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00 > >> > >>> RFC6830 or your Internet Draft? > >>> [Med] I’m referring to RFC6830 which says the following : > >>> > >>> Record Count: This is the number of records in this Map-Request > >>> message. A record is comprised of the portion of the packet that > >>> is labeled 'Rec' above and occurs the number of times equal to > >>> Record Count. For this version of the protocol, a receiver MUST > >>> accept and process Map-Requests that contain one or more records, > >>> but a sender MUST only send Map-Requests containing one record. > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> Support for requesting multiple EIDs in a single Map-Request^ > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> message will be specified in a future version of the protocol.^ > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> > >>> Yes, I do think it is time to specify that behavior in the bis > document. > >>> > >>> Section 3 of draft-boucadair-lisp-multiple-records is an example of > what > >> can be considered in the bis document. > >> > >> IMO the description is not sufficient to tell an implementation what to > >> code. It is under specified. I’d love to consider removing the above > but > >> it needs specific/detailed text describing why and when multiple > records > >> are used in Map-Requests. > > > > [Med] As I said earlier, that text is only an example of a starting > point. We can also start from what your implementation is already doing. > > > >> > >>> I’ll have a look at it. But what part of section 3? All the packet > >> format descriptions are already in RFC6830. > >>> [Med] The format needs to be updated for replies. > >> > >> Not true. Map-Replies have multiple EID records. And I use them every > day. > >> ;-) > >> > >>> It is documented no where that a Map-Resolvers caching mappings. And > if > >> you are proposing that you need a lot more text to describe how > mappings > >> are kept up to date in the Map-Resolver. This is a major architectural > >> change and really not sure you know the implications of it. > >>> [Med] That single sentence is hiding the case where a single request > >> from an xTR may be forked into multiple ones because target EIDs are > not > >> managed by the same servers. What is important in the text you quoted > is > >> that the xTR should be prepared to receive multiple replies for a > single > >> request. Two cases are to be considered: > >>> - Multiple records for the same EID that cannot be included in a > >> single resply > >>> - Multiple replies; each for a given EID > >> > >> And how does the ITR know to wait for multiple replies? > > > > [Med] This the role of M-bit in the response. That bit is an indication > to wait for more replies associated with a single request. draft- > boucadair-lisp-multiple-records states the following: > > > > In order to inform an ITR that subsequent Map-Reply messages will > > follow (or not) , a dedicated flag bit is defined for this purpose: > > it is called the M-bit (more-map-reply bit). > > > > How does it know > >> when all of them come in? This is more protocol machinery that needs to > be > >> spec’ed out. And I have not seen any of it in your bulk spec. > > > > [Med] Putting aside the use of TCP, the bulk specification defines a > dedicated bit for this: > > > > o Set the M-bit for all Map-Bulk-Reply messages, except for the last > > one. > > > >> > >> Dino > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
