Hi Magnus,
Thanks for the review.
Overall, the spec leverages the mechanisms in both RFC9301 and RFC9303. I don't know if you checked those when performing your review.
Let's start first with the transport-specific comment. Please see inline.
Cheers,
Med
> -----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.
"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.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
