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

From: "Alvaro Retana" <[email-masked]>
Date: Mon, 19 Oct 2015 11:30:44 -0700

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 20 Oct 2015 06:26:08 +0100

Alvaro,

Thanks for your comments. To answer your question:

First of all, is it that easy? The answer is yes, there is at least one
working and deployed implementation of which I'm aware. You are correct,
there are optional parts of 6870 that use non-status signaling, but if you
just use the status signaling-based procedures in 6870, all is fine. I can
make this more explicit if you like, please let me know.

On minor comment 1, we didn't mean to be "low key" about provisioning, we
can make that "must" a "MUST" if you like.

Minor comments 2 and 3 - will do.

Cheers,
Andy

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 20 Oct 2015 13:05:10 +0000

On 10/20/15, 1:26 AM, "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>> wrote:

Andy:

Hi!

First of all, is it that easy? The answer is yes, there is at least one working and deployed implementation of which I'm aware. You are correct, there are optional parts of 6870 that use non-status signaling, but if you just use the status signaling-based procedures in 6870, all is fine. I can make this more explicit if you like, please let me know.

I see..the subtlety is that you're specifically calling out just the status signaling.  Being more explicit would have helped me - I'll leave any change up to you.

Thanks!

Alvaro.