[Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting DISCUSS because I believe that the behavior specified in this
document is not clear enough.  I think these points should be easy to address.

(1) The main behavior in this document (using the reverse metric) is covered in
the following sentences:

§6:
   A router receiving a Hello packet from its neighbor that contains the
   Reverse Metric TLV on a link SHOULD use the RM value to derive the
   metric for the link to the advertising router in its Router-LSA...

   ...
   The neighbor SHOULD use the reverse TE metric value...

§7:
   Implementations SHOULD NOT accept the RM from its neighbors by default
   and SHOULD provide a configuration option to enable the acceptance of
   the RM from neighbors on specific links.

For all cases, why is this behavior recommended and not required?  When is it
ok to not use the RM, or to accept it by default?

(2) §6:

   A router stops including the Reverse Metric TLV in its Hello packets
   when it needs its neighbors to go back to using their own provisioned
   metric values.  When this happens, a router that had modified its
   metric in response to receiving a Reverse Metric TLV from its
   neighbor should revert to using its provisioned metric value.

No normative language is used here -- should there be a SHOULD/MUST there?

Even if "should revert" is used, the behavior is unclear and could be
interpreted as not required.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) I support Martin's DISCUSS.

(1) The calculation of the RM is out of scope, according to this text from §6:

   The mechanisms used to determine the value to be used for the
   RM is specific to the implementation and use case and is outside the
   scope of this document.

However, there are 3 occurrences in the same section that indicate requirements
when determining the RM:

   *  The RM value that is signaled by a router to its neighbor MUST NOT
      be derived from...

   *  The RM value that is signaled by a router MUST NOT be derived from...

   ...a router MUST never start, stop, or change its RM metric signaling
   based on...

All 3 instances try to avoid a circular dependency on other RMs, which is good.
 But normatively requiring that behavior (instead of making suggestions or
pointing out the danger) contradicts declaring the mechanism used to derive the
RM out of scope.

(2) §6 allows the inclusion of multiple instances of the Reverse Metric TLV
(for different topologies).  What should a receiver do if multiple instances
are received for the same MTID?