Hi Thomas,
Thanks a lot for your detailed review and your suggestions. We've incorporated all of those changes and they will reflect in the next update of the document.
Please check inline below for some responses.
On Fri, Sep 9, 2022 at 6:27 PM Thomas Fossati via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Thomas Fossati
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-lsr-ospf-reverse-metric-??
Reviewer: Thomas Fossati
Review Date: 2022-09-09
IETF LC End Date: 2022-09-20
IESG Telechat date: Not scheduled for a telechat
Summary:
This is a clear and easy to read document, thank you authors for the
great job.
I only have a couple of very minor issues / clarifications. The tail of
my review consists of a bunch of typographic nits and one suggestion for
how to align the Contributors section to most recent interpretations of
the RFC Style Guide (RFC7322).
KT> Thanks for catching that. The goal was to actually acknowledge Jay. We will remove the contributors section and use the acknowledgement section instead.
Major issues: none
Minor issues:
* It looks that the H and O flags are mutually exclusive? If so, I
think the fact should be made explicit. (This applies to both the
reverse and reverse TE metrics.)
KT> Yes, they are de facto mutually exclusive - i.e., when the O flag is set, the offset is added to the existing metric and therefore guaranteed to be not lower than the existing metric. Therefore, when the O flag is set, the H flag can be ignored and we will add this explicitly in the text.
* "If authentication is being used [...] then the Cryptographic
Authentication TLV [RFC5613] SHOULD also be used to protect the
contents of the LLS block." Please explain why this is not a MUST,
i.e., under which conditions it is OK to not authenticate the LLS
block.
KT> RFC5613 indeed covers this already and so it is a MUST ... "when authentication is used".
Thanks,
Ketan
Nits/editorial comments:
Section 1., paragraph 1:
OLD:
Thus the configuration on R1 influences the traffic that it forwards
NEW:
Thus, the configuration on R1 influences the traffic that it
forwards
Section 2.1., paragraph 2:
OLD:
when a large number of CE routers connect to a PE router, an
NEW:
when many CE routers connect to a PE router, an
Section 2.1., paragraph 3:
OLD:
router to advertise the maximum metric for that link and also to
[...]
returns to using its provisioned metric for the link and also stops
NEW:
router to advertise the maximum metric for that link and to
[...]
returns to using its provisioned metric for the link and stops
Section 2.2., paragraph 2:
OLD:
reverse metric to some or all of the R1-RN routers. When the R1-RN
NEW:
reverse metric to some or all the R1-RN routers. When the R1-RN
Section 3., paragraph 1:
OLD:
This ensures that the RM signaling is scoped ONLY to each specific
[...]
Metric TLV in its Hello packets on the link as long as it needs its
[...]
NEW:
This ensures that the RM signaling is scoped only to each specific
[...]
Metric TLV in its Hello packets on the link for as long as it needs
its [...]
Section 6., paragraph 4:
OLD:
instability in the network due to churn in their metric due to
signaling of RM:
NEW:
instability in the network due to churn in their metric caused by
signaling of RM:
Section 6., paragraph 7:
OLD:
RM metric signaling based on the RM metric signaling initiated by
some other router.
NEW:
RM metric signaling based on the RM metric signaling initiated by
some other routers.
Section 6., paragraph 10:
OLD:
(also refer to Section 7 for details on enablement of RM). The
rules [...]
NEW:
(refer to Section 7 for details on enablement of RM). The rules
[...]
Section 7., paragraph 5:
OLD:
For the use case in Section 2.1, it is RECOMMENDED that the network
operator limit the period of enablement of the reverse metric
NEW:
For the use case in Section 2.1, it is RECOMMENDED that the network
operator limits the period of enablement of the reverse metric
Section 9., paragraph 1:
OLD:
This document allocates code points from Link Local Signalling TLV
Identifiers registry for the TLVs introduced by it as below.
NEW:
This document allocates code points from the Link Local Signalling
TLV Identifiers registry for the introduced TLVs.
Regarding the Contributors section, I think BCP is to make it similar to
the Authors section, e.g.:
Section 11., paragraph 1:
OLD:
Thanks to Jay Karthik for his contributions to the use cases and the
review of the solution.
NEW:
Jay Karthik
Cisco Systems, Inc.
Email: jakarthi@xxxxxxxxx
Jay contributed to the use cases and the review of the solution.
If you are using kramdown-rfc you can add this snippet after your
"author" block
contributor:
- name: Jay Karthik
email: jakarthi@xxxxxxxxx
contribution: Jay contributed to the use cases and the review of the solution.
Otherwise (xml2rfc):
<contact initials="J." surname="Karthik" fullname="Jay Karthik">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>jakarthi@xxxxxxxxx</email>
</address>
</contact>
<t>
Jay contributed to the use cases and the review of the solution.
</t>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
