Hi Dino, Please see inline some clarifications, FWIW.
Cheers, Med > -----Message d'origine----- > De : Dino Farinacci [mailto:[email protected]] > Envoyé : jeudi 5 octobre 2017 01:04 > À : BOUCADAIR Mohamed IMT/OLN > Cc : [email protected] list; Stefano Secci; JACQUENET Christian IMT/OLN > Objet : Re: [lisp] Addition to RFC6833bis for xTR-ID in Map-Request > message > > > Hi Dino, all, > > > > I do strongly support that pub/sub feature is also possible in LISP. > > Thanks for the response Med. I think it can be introduced quite easily > with the right machinery. > > > Overloading Map-Request is one way to proceed, but there is also an > alternate approach to define a dedicate method for the > subscription/notification purposes (e.g., > https://tools.ietf.org/html/draft-boucadair-lisp-subscribe-05). > > I read your original draft and I just finished reading your -05 draft. > Here are my concerns with your design: > > (1) Your draft covers a lot more issues then just getting notifications > for RLOC-set changes (pubsub functionality). So the scope needs to be > narrowed IMO. > > (2) You indicate for Map-Resolver redirect to use a Map-Subscribe message. > That doesn’t sound like a pubsub capability. [Med] I may not look like a pubsub capability, but this is a consequence of requiring the Map-Resolvers to maintain state for notification purposes. Maintaining those state may include some extra load on those servers. The redirect functionally allows to redirect ITRs to an alternate server that will service them. This is done automatically at the mapping system side. > > (3) The Map-Subscribe has all the same fields (and in different order) > than a Map-Request, that means a new parser and code needs to be written > and debugged when existing implementations could easily process a new S- > bit in a Map-Request message. [Med] New code will be required anyway for supporting the new functionality. > > (4) An ITR would have to send two message when its data-plane gets a cache > miss. [Med] No. It will send only the subscribe message with I-bit set. This single message will be sufficient to immediately retrieve all the mappings that are matching the filters in the Map-Resolver for this particular ITR. This optimization is not supported with the modifier Map-Request. A Map-Request to get a Map-Reply to populate its map-cache and a > Map-Subscribe to request for notifications. [Med] No. Please see above. And then it would have to > process a Map-Subscribe-Ack and Map-Reply separately. > > (5) As for (4) what if the Map-Subscribe-Ack comes back but the Map-Reply > is lost? [Med] I guess you are referring to the case where I-bit is set in the Map-Subscribe. A way to detect lost Map-Reply is to convey in the Map-Subscribe-Ack the number of entries that will be retrieved. The ITR can check based on that information. The ITR has subscription state but can’t do any forwarding. What > if the Map-Reply is returned and the Map-Subscribe-Ack is lost, then the > ITR has forwarding state but no notification state. [Med] The ITR will retransmit Map-Subscribe in this case. What if the RLOC-set > changes during the retransmission of the Map-Subscribe-Ack? [Med] Implicit Map-Replies will be sent immediately to the ITR. > > (6) You put the Map-Subscribe functionality in the Map-Resolver. Well when > an RLOC-set changes for a registered entry in a Map-Server how does it > know which Map-Resolver to inform about the change? [Med] The draft puts it in the Map-Resolver, but having a dedicated method allows for more flexibility to define for example servers that will manage subscription and notifications. And Map-Resolvers > today do not cache mapping entries. So there are a lot of mechanical > issues you have not worked out. [Med] This is valid for all sub/pub proposals, IMHO. > > (7) I belive the spec is mis-named in a major way. You are talking about > ITR bulk transfer and cache re-population when an ITR reboots. This spec > has nothing to do with pubsub. [Med] Bulk transfer is not defined in this draft. It is a useful functionality to allow for the retrieval of many mapping using TCP. The ITR informs the subscription server whether it support bulk transfer or not. Based on that criteria, notifications will be sent using individual Map-Reply messages or using the bulk transfer procedure. > > Now as for draft-rodrigueznatal-lisp-pubsub-00 design: > > (1) The reason putting subscription requests in the Map-Request is because > both cache population and requesting for notifications come together and > are ack’ed together. > > (2) The reason for subscription requests in the Map-Request is so > subscriptions can go to the map-servers. The nodes that first know when an > RLOC-set changes. So we can do fast converging notifications. > > (3) Using Map-Requests allows map-resolvers and ddt-nodes to NOT change. > That has huge deployment advantagese. With this design only ITRs that want > the functionality and map-servers that provide the functionality need to > change. And both new and old ITRs/map-servers can interoperate. > > (4) Using Map-Replies for acknowledgements allows for both cache > population and subscription-acks to be signed by the map-server. That is, > they can be authenticated. > > (5) The implementation can be done fairly easily and we can deploy > quickly. This has been confirmed by at least 3 developers. > > So back to the simple change for RFC6833bis. Irrespective of pubsub, > knowing the xTR-ID on Map-Requests have advantages to identify the ITR > when it moves around (when the RLOCs change). > > If there are no other objections, I’d like to publish this the change > tomorrow? > > Dino > > > > > I suggest that the WG examines both approaches. > > > > Cheers, > > Med _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
