Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires
draft-ietf-pals-ms-pw-protection-04

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

Just total nit-level stuff here: unexpanded abbreviations that should be expanded.  Note to responsible AD: "OAM" should certainly be flagged in the RFC Editor's abbreviation list as not requiring expansion, and it's not so flagged.

-- Introduction --
PE, MPLS-TP, L2TP

-- Section 2 --
CE, AC (in fig 1)

-- Appendix A --
SDH, OTN, G-ACh