Re: [lisp] Rtgdir last call review of draft-ietf-lisp-pubsub-10

["Alberto Rodriguez-Natal (natal)" <[e-mail]>]

Hi Mike,

Thanks for the review! Your recommendations are noted, and they will be applied to the next iteration.

Thanks!
Alberto

From: Mike McBride via Datatracker <[e-mail]>
Date: Tuesday, January 24, 2023 at 5:57 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Rtgdir last call review of draft-ietf-lisp-pubsub-10
Reviewer: Mike McBride
Review result: Has Nits

These are my recommendations:

Section 4:

Change this:
      xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128
      bit xTR-ID and a 64-bit Site-ID fields are present at the end of
      the Map-Request message.
To this:
      xTR-ID bit (I-bit): This bit is set to 1 to indicate that 128
      bit xTR-ID and 64-bit Site-ID fields are present at the end of
      the Map-Request message.

Change this:
      If the I-bit is set but the Site-ID and/or
      xTR-ID are not included, a receiver can detect the error because
      after processing that last EID-record, there are no bytes left
      from processing the message.
To this:
      If the I-bit is set, but the Site-ID and/or
      xTR-ID are not included, a receiver can detect the error because,
      after processing that last EID-record, there are no bytes left
      from processing the message.

Section 5:

Change this:
   The xTR subscribes for changes for a given EID-Prefix by sending a
   Map-Request to the Mapping System with the N-bit set on the EID-Record
To this:
   The xTR subscribes for changes, to a given EID-Prefix, by sending a
   Map-Request to the Mapping System with the N-bit set on the EID-Record

Change this:
   The xTR processes this Map-Notify as described in
   Section 5.7 of [RFC9301] with the following considerations.  The xTR
   MUST use the Map-Notify to populate its Map-Cache with the returned
   EID-Prefix and RLOC-set.
To this:
   I'm expecting a ":" after considerations and then a list of those
   considerations, but just see a new sentence. Perhaps make it one sentence:
   The xTR processes this Map-Notify, as described in Section 5.7 of [RFC9301],
   and MUST use the Map-Notify to populate its Map-Cache with the returned
   EID-Prefix and RLOC-set.

Change this:
   The following specifies the procedure to remove a subscription.
To this:
   I'm expecting a ":" after subscription. Perhaps either add the ":" or remove
   the sentence.

Section 6:

Change this:
   The complete mechanism works as follows.
To this:
   I'm expecting a ":" after follows. Either add the ":" or remove the sentence.

Change this:
   The xTR processes the received Map-Notify as specified in Section 5.7
   of [RFC9301], with the following considerations.
To this:
   I'm expecting a ":" after considerations. Either add the ":" or remove the
   sentence.

Section 7.1:

Change this:
   Since Map-Notifies from the Map-Server to the ITR need to be...
To this:
   Since Map-Notifies from the Map-Server to the ITR needs to be...

Change this:
   Otherwise, if the Map-Server has to reply with a Map-Notify (e.g. due
   to subscription accepted) to a received Map-Request, the following
   extra steps take place.
To this:
   ...extra steps take place:

Change this:
   Note that if the Map-Server replies with a Map-Notify, none of the
   regular LISP-SEC steps regarding Map-Reply described in Section 5.7
   of [RFC9303] takes place)
To this:
   Note that if the Map-Server replies with a Map-Notify, none of the
   regular LISP-SEC steps regarding Map-Reply, described in Section 5.7
   of [RFC9303], takes place.

Section 8.2:

Change this:
   Section 8.1 of [RFC9301] suggests two TTL values for Negative Map-
   Replies,
To this:
   Section 8.1 of [RFC9301] suggests two TTL values for Negative Map-
   Replies:

Section 8.3:

Change this:
   Deployment experience reveals that data-driven SMRs and PubSub mechanisms
   complement each other well and combined provide a fast and resilient
   network infrastructure in the presence of mobility events.
To this:
   Deployment experience reveals that data-driven SMRs and PubSub mechanisms
   complement each other and provide a fast and resilient
   network infrastructure in the presence of mobility events.

Change this:
   Concretely, in scenarios with significant traffic coming from outside
   of the LISP network, the experience showed that enabling PubSub in
   the border routers, significantly improves mobility latency overall,
   even if edge xTRs do not implement PubSub and traffic exchanged
   between EID-Prefixes at the edge xTRs still converges based on data-
   driven events and SMR-triggered updates.
To this:
   In scenarios with significant traffic coming from outside
   of the LISP network, the experience showed that enabling PubSub in
   the border routers significantly improves mobility latency overall.
   Even if edge xTRs do not implement PubSub, and traffic is exchanged
   between EID-Prefixes at the edge, xTRs still converge based on data-
   driven events and SMR-triggered updates.

Section 8.5:

Change this:
   Interestingly, with PubSub at least the Map-Cache is updated with the
   correct RLOC information, even when it is not being used or waiting to
   expire, which helps debugging.
To this:
   With PubSub, the Map-Cache is updated with the correct RLOC
   information, even when it is not being used or waiting to expire,
   and this helps with debugging.