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
