Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks
RFC 7338
Yes
No Objection
Abstain
Note: This ballot was opened for revision 08 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Alia Atlas; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
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....
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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
(Stephen Farrell; former steering group member) (was Discuss) No Objection
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.
(Ted Lemon; former steering group member) Abstain
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.