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 <noreply@xxxxxxxx>
Date: Tuesday, January 24, 2023 at 5:57 AM
To: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>
Cc: draft-ietf-lisp-pubsub.all@xxxxxxxx <draft-ietf-lisp-pubsub.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, lisp@xxxxxxxx <lisp@xxxxxxxx>
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.
|
