Subject: [Pals] Mirja Kühlewind's No Objection on draft-ietf-pals-mpls-tp-dual-homing-coordination-05: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 01 Mar 2017 04:05:20 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-pals-mpls-tp-dual-homing-coordination-05: 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-mpls-tp-dual-homing-coordination/

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

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.