Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks
RFC 7338

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

(Alia Atlas) Yes

(Adrian Farrel) Yes

(Jari Arkko) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2014-05-27 for -09)
No email
send info
A nit: In the Abstract

   This document presents a set of requirements and a framework for
   providing a Point-to-Multipoint Pseudowire (PW) over MPLS Packet
   Switched Networks. The requirements identified in this document are
   related to architecture, signaling and maintenance aspects of Point-
   to-Multipoint PW operation. They are proposed as guidelines for the
   standardization of such mechanisms. Among other potential
   applications, Point-to-Multipoint PWs can be used to optimize the
   support of multicast layer 2 services (Virtual Private LAN Service
   and Virtual Private Multicast Service) as defined in the Layer 2
   Virtual Private Network Working Group.

I thought common practice was that we didn't refer to working groups (which conclude) in RFCs (that last forever)?

More than a nit, but not a Discuss: This draft contains a fair number of SHOULDs with no guidance on why you might not or what happens if you don't. I don't have anywhere near the background to question specific SHOULDs ... with maybe one or two exceptions, like:

3.4.5. Failure Detection and Reporting

   -  In case of failure, it SHOULD correctly report which Leaf PEs are
      affected.  This SHOULD be realized by enhancing existing PW
      methods, such as LDP Status Notification.  The notification
      message SHOULD include the type of fault (P2MP PW, AC or PSN

Are there network operators who think it will be awesome to see failure reports that don't tell them what Leaf PEs are affected, or don't tell them the type of fault? 

Maybe that's normal in the PW world, and that would be fine if it's true, but I'm imagining seeing a failure report that says "Something bad happened, but I can't tell you much about it. You should worry. Good luck on finding it" :D

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-06-20)
No email
send info
Thanks for adding the new security considerations text.

As a comment, I'd suggest one more tweak


       The solution SHOULD provide means to guarantee the traffic delivery	
			to receivers (Integrity, Confidentially)


      The solution SHOULD provide means to protect the traffic delivered
			to receivers (Integrity, Confidentially, Endpoint Authentication)

Not quite a nit, but definitely not discuss-worthy.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-05-20 for -09)
No email
send info
UPDATE: My comments below have been addressed in -09; thanks.

I'm happy to see this fine document approved.  I have two small comments, neither of which is a big deal:

1. In Section 3.4.7, you say

   The solution SHOULD scale at worst linearly with the number of Leaf

It's probably worth adding a few more words to say *what* should scale that way.  Maybe something like this (thanks to a conversation with Adrian):

   The solution SHOULD scale at worst linearly for message size, memory
   requirements, and processing requirements, with the number of Leaf PEs.

2. My sense of "normative references" are those that are necessary for a reader to understand the document at hand.  I think some of the informative references should be moved to normative, including 3985, 5659, 5332, and 3916.  I'm of mixed mind about 4446, 6310 -- they're targets of MUST clauses, but I'm on the fence about whether that alone makes them normative.

Anyway, please consider going through the informative references, and making a handful of the most critical ones be normative.

Both of these comments are non-blocking, so if you think it's fine as it is, carry on and you'll have no further discussion from me.  Thanks for considering....

(Kathleen Moriarty) No Objection

Comment (2014-05-28 for -09)
No email
send info
I support Stephen's discuss and would like to see a response to the SecDir comments as well (one fits in as a question on a particular change in the security considerations from the referenced RFC and may help in Stephen's discuss).

(Martin Stiemerling) No Objection

(Ted Lemon) Abstain

Comment (2014-05-28 for -09)
No email
send info
I don't think work covered by this requirements doc should go forward without resolving the outstanding IPR issue, but I'm not going to try to block the document—just registering my concern.