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 <last-call-bounces@xxxxxxxx> De la part de Magnus
> Westerlund via Datatracker
> Envoyé : mardi 24 janvier 2023 14:20
> À : tsv-art@xxxxxxxx
> Cc : draft-ietf-lisp-pubsub.all@xxxxxxxx; last-call@xxxxxxxx;
> lisp@xxxxxxxx
> 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 tsv-art@xxxxxxxx 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
