Hi Dino, Please see inline.
Cheers, Med De : Dino Farinacci [mailto:[email protected]] Envoyé : mardi 10 octobre 2017 19:22 À : BOUCADAIR Mohamed IMT/OLN Cc : [email protected] list Objet : Re: [lisp] Comments to draft-boucadair-lisp-multiple-records-00 Hi Dino, Thank you for the comment. There is a provision in RFC6830 to support multiple RLCOs/EIDS but without specifying the behavior. Right, I already said that. As you know, that RFC is crystal clear about that. 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. 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. And you have this in section 3 which is semantically incorrect: [cid:[email protected]] 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 Map-Resolvers ONLY cache referral entries documented in the LISP-DDT RFC. Also note, what if a Map-Request has both 10.1.1.1/32 and 10.1.0.0/16 encoded as EID records. And if the mapping system has registered 10.0.0.0/8, then does the Map-Reply contain two records to satisfy 10.1.1.1/32 AND 10.1.0.0/16, or just one EID record. And if so, how does the requestor know that the one reply record is associated with both request records or one doesn’t apply (or is not found in the mapping system). As you can see there is a lot of text that would need to be written. Which I think is too late for RFC6833bis. That is why I asked you for text. I wanted to see how coarse versus detail your text would be and then have the WG judge if it should go in. [Med] This is fair. Then there is the practical aspect. What are you trying to accomplish with multiple EID-records in a Map-Request. Let’s start there. [Med] In addition to what motivated “RFC6830 already supports multiple EID-records in both Map-Requests and Map-Replies”, we are focusing on the following cases: - Fast recovery of popular EIDs in case of failures. One or very few requests will trigger the mapping retrieval. - Optimized subscription/notification exchanges Dino Thank you. Cheers, Med -----Message d'origine----- De : lisp [mailto:[email protected]] De la part de Dino Farinacci Envoyé : lundi 9 octobre 2017 18:56 À : [email protected]<mailto:[email protected]> list Objet : [lisp] Comments to draft-boucadair-lisp-multiple-records-00 Med/Christian, RFC6830 already supports multiple EID-records in both Map- Requests and Map-Replies (as well as Map-Notify messages). If you think it is not specified sufficiently, now is the time to add a better explanation to RFC6833bis. Dino _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
