> 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. (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. (4) An ITR would have to send two message when its data-plane gets a cache miss. A Map-Request to get a Map-Reply to populate its map-cache and a Map-Subscribe to request for notifications. 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? 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. What if the RLOC-set changes during the retransmission of the Map-Subscribe-Ack? (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? And Map-Resolvers today do not cache mapping entries. So there are a lot of mechanical issues you have not worked out. (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. 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
