Hi Med, Overall, the spec leverages the mechanisms in both RFC9301 and RFC9303. I don't know if you checked those when performing your review.
MW: Yes, I looked at those, and as you cite some of it I can explain why I think this isn’t sufficient for this specification. > -----Message d'origine----- > De : last-call <[email protected]> De la part de Magnus > Westerlund via Datatracker > Envoyé : mardi 24 janvier 2023 14:20 > À : [email protected] > Cc : [email protected]; [email protected]; > [email protected] > Objet : [Last-Call] Tsvart last call review of draft-ietf-lisp- > pubsub-10 > > Reviewer: Magnus Westerlund > Review result: Not Ready > > This document has been reviewed as part of the transport area > review team's ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, > but are copied to the document's authors and WG to allow them to > address any issues raised and also to the IETF discussion list for > information. > > When done at the time of IETF Last Call, the authors should > consider this review as part of the last-call comments they > receive. Please always CC [email protected] if you reply to or > forward this review. > > My review comments are: > > > C. When a Map-Notify is to be sent there are no discussion in > regards to > congestion control of the transmission of the Map-Notify. [Med] CC is already covered in 9301. We are not repeating what is already specified in Section 5.7 of 9301: A Map-Server sends an unsolicited Map-Notify message (one that is not used as an acknowledgment to a Map-Register message) only in conformance with Section 3.1 ("Congestion Control Guidelines") of [RFC8085] and Section 3.3 ("Reliability Guidelines") of [RFC8085]. A Map-Notify is retransmitted until a Map-Notify-Ack is received by the Map-Server with the same nonce used in the Map-Notify message. An implementation SHOULD retransmit up to 3 times at 3-second retransmission intervals, after which time the retransmission interval is exponentially backed off (base of 2, that is, the next backoff timeout interval is doubled) for another 3 retransmission attempts. Map-Notify-Ack messages are only transmitted upon the reception of an unsolicited Map-Notify; Map-Notify-Ack messages are not retransmitted. MW: Yes, the issue is that in the context of subscriber service, I think it is relevant to discuss how to ensure that the server does not try to overload its own outgoing paths as N subscribers to a particular mapping will result in N outgoing message when that mapping is updated. That N messages can’t in general be sent all immediately as it will result in a large spike, for large enough values of N overloading. That needs some discussion. And as I discussed in my review the retransmission timer being fixed at 3 seconds will need to be taken into account. Because if one pace so that the pacing of the N Map-Notify so that it will take more than 3 seconds then the retansmissions will also start result in additional load when they occur. "unsolicited Map-Notify" is what draft-ietf-lisp-pubsub is about. Section 5.7 of 9301: The fields of the Map-Notify are copied from the corresponding Map- Register to acknowledge its correct processing. In the Map-Notify, the 'Authentication Data' field is recomputed using the corresponding per-message key and according to the procedure defined in the previous section. The Map-Notify message can also be used in an unsolicited manner. This topic is out of scope for this document. See [LISP-PUBSUB] for details. As the > Map-Notify appear to be unicast IP/UDP packets being sent one per > subscriber at the time an updated mapping is registered with the > map-server all these messages will be generated. There need to be > some rate limiting for this transmission to prevent congestion > near the map-server. If sufficient number of subs are in place > also the retransmission will have to be rate limited as not all > Map-Notify messages will have been sent when its time to start to > perform retransmissions. Yes, I understood that this is what is referenced. My point is that the pubsub mechanism creates new issues as it both build up states and when the Map-Notify messages are triggered the whole state needs to be considered in doing reasonable things. Cheers Magnus
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
