Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-pubsub-13: (with COMMENT)

[[e-mail]]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Eric Vyncke (evyncke) <[e-mail]>
> Envoyé : jeudi 16 février 2023 15:15
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: Éric Vyncke's No Objection on draft-ietf-lisp-pubsub-
> 13: (with COMMENT)
> 
> Bonjour Med,
> 
> Big thanks for your quick reply. Some text was elided.
> 
> See in-line for EV>
> 
> On 16/02/2023, 10:10, "[e-mail]
> <mailto:[e-mail]>"
> <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
> ...
> 
> 
> > -----Message d'origine-----
> > De : Éric Vyncke via Datatracker <[e-mail]
> > <mailto:[e-mail]>> Envoyé : jeudi 16 février 2023 09:43
> À :
> > The IESG <[e-mail] <mailto:[e-mail]>>
> >
> 
> > ### Updating RFC 9301 ?
> >
> > Like Erik Kline, I wonder whether this I-D should formally
> update RFC
> > 9301. Or is the IANA registry addition enough ?
> >
> 
> 
> [Med] I asked in the past for an update header for the draft but
> the WG call is to be conservative but consistent in all LISP
> specs. Please refer to the summary at:
> https://mailarchive.ietf.org/arch/msg/lisp/mWukquyGiXnsMwxxvCwhTY2
> K1HM/
> <https://mailarchive.ietf.org/arch/msg/lisp/mWukquyGiXnsMwxxvCwhTY
> 2K1HM/>. We are following that conclusion.
> 
> EV> indeed, the "update" meta-data is overloaded. If the LISP WG
> and the rest of the IESG is comfortable to publish the document
> without a formal "Update" meta-data, I am all fine (hence a
> COMMENT and not a DISCUSS), especially as there is a IANA registry
> for those bits.
> 
> > ### Section 5 and intended status
> >
> > ```
> > The exact details to characterize such policies are deployment
> and
> > implementation specific. Likewise, this document does not
> specify
> > which
> > notifications take precedence when these policies are enforced.
> > ```
> >
> > This is indeed my biggest concern about this mechanism as it can
> > trigger a
> > flood of Map-Notify when a EIP mapping changes. PubSub is nice
> > when there is
> > one publisher and many potential subscribers but in this
> specific
> > case it is
> > several publishers to several subscribers with many
> subscriptions.
> >
> [Med] The key requirement is the following:
> 
> Servers SHOULD be configured with policies to control the maximum
> number of subscriptions and also the pace of Map-Notify messages.
> 
> Like with any rate limit recommendation, I don't think we can
> mandate by design a specific way to enforce it or how a server can
> control the number of state it maintains.
> 
> EV> I keep wondering whether a local rate limiting can be done for
> a global issue (i.e., there are multiple publishers).
> 

[Med] There are many but there is only one that will handle notifications for a given xTR: 

   The Map-Request is forwarded to the appropriate Map-Server through
   the Mapping System.  This document does not assume that a Map-Server
   is pre-assigned to handle the subscription state for a given xTR.
   The Map-Server that receives the Map-Request will be the Map-Server
   responsible for notifying that specific xTR about future mapping
   changes for the subscribed mapping records.

That Map-Server can follow whatever local policy to access/discard a subscription independent of the status of other Map-Servers.


> > An experimental status would be more comforting.
> >
> > ### Missed notification
> >
> > If for any reason a Map-Notify is missed (e.g., publisher is
> > overloaded), then
> > what is the fall-back ? When a Map-Request gets no response,
> then
> > the
> > Map-Request can be resent by the xTR but in the case of Map-
> Notify
> > ? There is
> > some text in section 5, but only from the point of view of the
> > publisher.
> >
> 
> 
> [Med] Not sure to get the point, Éric. Can you please clarify your
> concern? Thanks.
> 
> EV> Sorry if I was unclear. Here is what I mean in more words: in
> the case of a publish/Map-Notify message is missed/dropped (for
> whatever reason), it is up to the publisher to resend it to the
> subscriber in the absence of a ACK (which of course forces the
> publisher to keep many states/timers) per section 5.

[Med] Yes.

 But, what
> happens if this step is not done or the re-publish also fails ?
> This would mean a mis-routed packet probably (I am not an expert
> in LISP) then packet loss. Is there a 2nd level safety net in this
> case ?

[Med] The Map-Server will proceed as follows: 

   If after following Section 5.7 of [RFC9301] regarding
   retransmission of Map-Notify messages, the Map-Server has not
   received back the Map-Notify-Ack, it can try to send the Map-Notify
   to a different ITR-RLOC for that xTR-ID.  If the Map-Server tries all
   the ITR-RLOCs without receiving a response, it may stop trying to
   send the Map-Notify.

If there is no retransmission or the retransmission fails, the subscriber will maintain stale mappings till the next update or a Map-Request update.


_________________________________________________________________________________________________________________________

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.