Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection
RFC 8185

Note: This ballot was opened for revision 05 and is now closed.

Deborah Brungard Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Ben Campbell) No Objection

Comment (2017-03-01 for -05)
No email
send info
Just a couple of editorial comments:

- Abstract: The parenthetical phrase " (management plane based)" makes the sentence structure more confusing that if the phrase were simply removed.

- Section 1: A few abbreviations that were expanded in the abstract should be expanded again in the body.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2017-02-28 for -05)
No email
send info
- The secdir review [1] raised some good points that
I believe the authors have agreed to address, but
that's yet to happen.

[1] https://mailarchive.ietf.org/arch/search/?email_list=secdir&gbt=1&index=hE2TffVz-by4u001aSosi8JK6WI

(Joel Jaeggli) No Objection

(Suresh Krishnan) No Objection

(Mirja K├╝hlewind) No Objection

Comment (2017-03-01 for -05)
No email
send info
Sorry one more editorial comment:

- In section 3.1 it would be good to further clarify what's meant by 'local request or a remote request', especially when and who is doing the remote request?

Minor mostly editorial comments:

1) When I first saw "DHC Code Point" in figure 2, I was slightly confused because this doesn't show in the rest of the doc anymore. Maybe rename to 'DHC channel type' or use the same term in the text or directly put the value in there that will be assigned by IANA.

2) 3.1.:"After the transmission of the three messages, the
   dual-homing PE MUST send the most recently transmitted Dual-Node
   Switching TLV periodically to the other dual-homing PE on a continual
   basis using the DHC message."
   This is only if the protection is active, right?

3) 3.2.:"Whenever a change of service PW status is detected by a dual-homing
   PE, it MUST be reflected in the PW Status TLV and sent to the other
   dual-homing PE immediately using the 3 consecutive DHC messages.
   This way, both dual-homing PEs have the status of the working and
   protection PW consistently."
   Note, it's possible that all three messages get lost. If you want to make sure you stay in sync, you need an explicit mechanism for reliability, e.g. sending an ack.

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2017-03-02 for -05)
No email
send info
This should really be a DISCUSS, but I trust the shepherding AD to make sure that it is resolved:

At the beginning of page 6 there are 2 fields: Version and Flags which I don't think are described.

(Kathleen Moriarty) No Objection

Comment (2017-02-28 for -05)
No email
send info
Stephen also noted the SecDir review and text provided.  I also think this should be incorporated to explain the security considerations added by this draft. https://mailarchive.ietf.org/arch/msg/secdir/hE2TffVz-by4u001aSosi8JK6WI