[Pals] Alvaro Retana's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-pals-ms-pw-protection-03: 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-pals-ms-pw-protection/



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

I appreciate all the background given, it makes the text very clear.

I have one question:  Is it that easy?  The substantive part of this
document is "the PW status signaling defined in RFC 6478 MUST be used…in
place of LDP-based status signaling".  Do all the parts of Sections 6 and
7 of RFC 6870 just translate to the alternate signaling?  For example
(this is the first thing that I found, nothing special about it), 6.2
(RFC6870) says that "a common Group ID in the PWid FEC element or a PW
Grouping ID TLV in the Generalized PWid FEC element, as defined in [2],
MAY be used to signal PWs in groups in order to minimize the number of
LDP status messages that MUST be sent."  I found the Status TLV in
RFC6478, but not these other ones — I may of course be missing the
references..


I have other minor comments:

1.  Just a nit..  It's interesting how (in the Introduction) when
presenting the optional mechanism the text says that it "MUST be
identically provisioned in the PE endpoints".  However, then talking
about the MTI mechanism (in Section 3. (Operational Considerations)), the
text "just" says that "operational care must be taken so that the
endpoint T-PEs are identically provisioned".  [To be fair, the same "low
key" text is later included in the Appendix referring to the optional
mechanism.]  The text itself is not a big deal to me..it just caught my
attention the difference in treatment when for either mechanism to work
both endpoints must be provisioned the same say.

2. Section 1. (Introduction)  Please expand PSN and put a reference in
for "PSN tunnel protection", or at least make it clear that the
protection you're referring to is what was described above (at least
that's my guess).

3. Section 2:  s/in the place of LDP-based/in place of LDP-based