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

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

* "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.

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@cisco.com
 
    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@cisco.com
    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@cisco.com</email>
    </address>
  </contact>
  <t>
    Jay contributed to the use cases and the review of the solution.
  </t>