Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection
draft-ietf-pals-mpls-tp-dual-homing-coordination-06
Yes
(Deborah Brungard)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 05 and is now closed.
Deborah Brungard Former IESG member
Yes
Yes
(for -05)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2017-03-02 for -05)
Unknown
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.
Alia Atlas Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-03-01 for -05)
Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-02-28 for -05)
Unknown
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
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-03-01 for -05)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2017-02-28 for -05)
Unknown
- 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
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -05)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -05)
Unknown