Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy
draft-ietf-pwe3-iccp-16

Adding a note after discussion with Stewart and bearing in mind some observations from a couple of other ADs, I think that this I-D might make it more obvious that ICCP is running within LDP and why that choice was made. That will stop people "expressing surprise" and making claims of "unwarranted piggybacking."

While I accept that this information can be gleaned from the document, it is not really painted red. Perhaps add a short sentence to the Introduction (and not buried :-) saying something like....

This document assumes that it is normal to run LDP between the PEs in the RG, and that LDP components will in any case be present on the PEs to establish and maintain PWs. Therefore, ICCP is built as a secondary protocol running within LDP and taking advantage of the LDP session mechanisms and the underlying TCP and TCP-based security mechanisms already necessary for LDP operation.

===

I just so wish you hadn't made this "LDP" it shares so little with
LDP that you might just as easily have made it a whole new protocol
and saved all of the baggage and the strangeness that *will* happen
when an implementation gets confused and sends a regular LDP message
trying for a label.

Indeed, the whole document basically fails to discuss how this fits
within LDP in terms of session establishment etc. Thus, I think there
is an assumption that there is already an MPLS LDP session between
each pair of PEs in an RG such that the elements of this protocol can
just piggy-back on that.

Indeed, section 4.6 presents a hack for a "separate" session without
saying separate from what. In the case where no labels exchange is
needed between the PEs, this would be the normal case and it indicates
that LDP is not really the best choice for this approach.

However, "I think this way of doing things sucks" is clearly not a
reason to place a Discuss or to block the document. It is also clear
that this approach has been coded and shipped. I think it's a shame it
wasn't done cleanly and I am surprised that LDP architects and the PWE3
WG didn't think this an unnecessary hack.

---

I think Tom may want to change his coordinates

---

I think that new LDP-based documents would do well to include references
to further work on MPLS and LDP security. In particular, RFC 5920, RFC
6952, and draft-ietf-mpls-ldp-hello-crypto-auth.

Updated...

Having read Adrian's comments, I re-read the specification and concur with his concern.  Overloading existing protocols can lead to problems.  I can envision future work where either the ICCP function or the LDP function needs to change its core behavior.  It is quite possible that the requirements for the other function will interfere with making such changes.  Given the nature of ICCP, it seems to me that a better design decision would have been to make it a separate protocol.

For the IESG... I equate this with the recent discussion we had over the ICMP AUP draft.  Overloading existing protocols because they have similar semantics or functionality is not good protocol design.