[mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-tp-shared-ring-protection-05: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mpls-tp-shared-ring-protection-05: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/



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

Two technical comments that I think are important to address but do not
warrant a discuss:

1) section 5.2: "As shown in Figure 14, when no protection switching is
active on the
   ring, each node MUST send RPS requests with No Request (NR) to its
   two adjacent nodes periodically."
What does periodically mean here? Can you maybe give a number or even a
normative statement like "and MUST NOT send more often than every X
seconds" to avoid unnecessary congestion...?

2) section 5.1.1: "A ring node which is not the
   destination of the received RPS message MUST forward it to the next
   node along the ring immediately."
Why would you forward these? I thought you only send messages to your
neighbors? Maybe I missed this but is there a use case for this scenario?
Otherwise it might be safer to not forward to avoid that messages with a
wrong destination node ID circle around forever. If you forward maybe you
also need a hop-count to decrease or at least say that messages that are
received and have the own node ID as source node ID MUST be dropped...?

Further, as mentioned by Ben for a couple of case, some of the uses of
normative language in section 5 seems not to be appropriate as they don't
specify a concrete implementation action. Please check carefully and
change some to lower case instead, e.g.
"The MSRP protection operation MUST be controlled with the help of the
   Ring Protection Switch protocol (RPS). "
"The RPS protocol MUST carry the ring status information and RPS
   requests,.." (this sounds like a requirement on the protocol design
but when you implement the protocol as specified there is no way to not
do it, so this MUST is unnecessary)
"Each node on the ring MUST be uniquely identified by assigning it a
   node ID." (also requirement-like; the MUST in the next sentence is the
important one)
"When a node detects a failure and determines
   that protection switching is required, it MUST send the appropriate
   RPS request in both directions to the destination node."
"MSRP mechanism SHOULD support multiple protection switches in the
   ring, resulting in the ring being segmented into two or more
separate
   segments. "
"The first three RPS protocol messages carrying new RPS request SHOULD
   be transmitted as fast as possible." (Again the later SHOULD is the
more important one)
There may be more…