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

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

(Alia Atlas) Yes

Comment (2014-03-20 for -15)
No email
send info
This is definitely a point solution to the problem for pseudo-wires, where targeted LDP is used as a signalling protocol.  My earlier concerns have been addressed in version -14.

A minor correction (found by Binny Jeshan):

Section 7.2.5. mLACP Port Config TLV says,
- Flags

       Valid values are:

            -i. Synchronized (0x01)

                Indicates that the sender has concluded transmitting all
                member link port configurations for a given Aggregator.

Shouldn't this be stating it as "given Port" ?

(Stewart Bryant) Yes

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Spencer Dawkins) No Objection

Comment (2014-02-20 for -13)
No email
send info
For what it's worth, not remotely my area of expertise and I'll rely on people who understand this better to carry out the conversation, but I had assumed that this was a fairly straightforward extension of LDP and am bemused to understand that it's not.

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-03-14 for -15)
No email
send info

Thanks for handling my discuss about the security mechanisms.
-15 specifies those nicely I think.

The question below remains and I don't recall if we discussed
that. If the actor key were a cryptographic key then we might
need to chat more. Can you confirm its an identifier and not
a cryptographic key?

- 7.2.4 - what is an "LACP Actor Key"?  Sorry, I just
don't know:-) Is that an identifier for a thing or a
cryptographic key? I assume the former.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-03-25 for -15)
No email
send info
This comment is a non-blocking consideration for future improvement.  The security model relies upon physical security with some (not great) provisions for authentication and access controls (address filtering, anti-spoofing, MD5 authentication).  Monitoring provides the ability to catch a problem if a security breach arises s was described in the response to the SecDir review.  Our threat models and understanding of them continues to evolve with service providers being a major target, as well as administrators.  Stronger authentication options and session encryption should be considered if a redesign as suggested in other IESG reviews is done.

(Pete Resnick) No Objection

Comment (2014-03-26 for -15)
No email
send info
Thanks for addressing my earlier comments. I note that you added to each instance:

   The string MUST NOT include a terminating null character.

That's a silly use of "MUST NOT". You mean "does not". You don't really care if there happens to be a terminating null; if someone puts one there, that's fine. What you care about is that nobody think that it *will* have a terminating null. So you want to say that the string *does not* include a terminating null character. You don't care if the producer of the packet adds an additional null at the end.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2014-02-20 for -13)
No email
send info
I support Stephen's position.

(Adrian Farrel) Abstain

Comment (2014-02-20 for -13)
No email
send info
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.

(Brian Haberman) (was No Objection) Abstain

Comment (2014-02-20 for -13)
No email
send info
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.