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.
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. 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. 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
