Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks
draft-ietf-pwe3-p2mp-pw-requirements-10

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
   PEs.

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....

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).

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
      tunnel).

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

Thanks for adding the new security considerations text.

As a comment, I'd suggest one more tweak

OLD:

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

NEW:

      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.