> 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. > 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? 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. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
