See responses below. I cut out text that I didn’t need to respond to. > [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.
You can load-split by using several sets of anycast map-resolvers. So you have two levels of spread. >> (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. But you require it in all LISP nodes. Do you agree the draft-rodrigueznatal-lisp-pubsub-00 is a simpler and more effective way to introduce pubsub functionality. FYI for others on the list, we have asked Med and Christian to be co-authors on draft-rodrigueznatal-lisp-pubsub-00. It would be good for you two to deploy pubsub to verify the design. Do you have time to do this? There should be two implementations available soon. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
