Re: [lisp] [Last-Call] Tsvart last call review of draft-ietf-lisp-pubsub-10

[Magnus Westerlund <[e-mail]>]

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 <[e-mail]> De la part de Magnus
> Westerlund via Datatracker
> Envoyé : mardi 24 janvier 2023 14:20
> À : [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> 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 [e-mail] 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