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

["Eric Vyncke (evyncke)" <[e-mail]>]

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/mWukquyGiXnsMwxxvCwhTY2K1HM/ <https://mailarchive.ietf.org/arch/msg/lisp/mWukquyGiXnsMwxxvCwhTY2K1HM/>. 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).

> 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. 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 ?