[WG participant hat on.] Dino:
Hi! I agree that the behavior could be implementation-specific: just configure both sides. It would be valuable to document it. If it is an optional implementation configuration and there are no bits involved, the specification could even go in the current draft: An implementation MAY consider more specifics...more details... The xTRs and Map-Servers in the network MUST be explicitly configured if this optional functionality is used. This is an example of a possible deployment: [describe a case where a single message would be used -- doesn't have to be specific to ICAO's application]. A couple of paragraphs should do it. ;-) My 2c, Alvaro. On April 26, 2022 at 5:32:52 PM, Dino Farinacci ([email protected]) wrote: > Interesting, there might be use-cases for that. Maybe that is something we can work as an extension of the base PubSub, once the base spec is done? So from the discussion with the ICAO guys (Bela and Bernhard), they want a "more-specific" type processing of both Subscribe-Requests and Map-Registers. For example: (1) subcribe 10.1.1.1/32, 10.1.1.2/32, then unsubscribe for 10.1.1.0/24 which unscribes all the more-specifics to 10.1.1.0. (2) Map-Register 10.1.1.1/32, 10.1.1.2/32, then deregister for 10.1.1.0/24 which unscribes all the more-specifics to 10.1.1.0. We don't spec this out in either the pubsub or 6833bis and an implementation could do this with no new flag bits required, but if we wanted to standarize this a Map-Register and Map-Request would need a "process-all-more-specifics" flag bit. And, the aggregate that "undoes" all the more-specifics would have to use the same authentication key and signature used for all the specific registered. We are still discussing this privately. We took the discussion off the list, but I wanted to update everyone on the status of the discussion. Any comments? It is of my opinion, that this is a moderate protocol change but they need it so they can send one message rather than possibly more than one message with a list of specifics. And I am not sure we should update specs for this since an implementation can be configured on both the xTR side and the map-server side to do this functionality. Comments about documenting this? Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
