Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
RFC 5671
Yes
No Objection
Recuse
Note: This ballot was opened for revision 02 and is now closed.
Lars Eggert No Objection
Section 2.2.2., paragraph 0: > 2.2.2. PCE Congestion Similar to other PCE documents that we've published, I'd suggest to replace "congestion" by "overload" here. In the Internet, congestion implicitly means "data-plane congestion", whereas what is meant here is "control-plane processing overload".
(Ross Callon; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
The OPS-DIR review by Tina Tsou raised a couple of issues. Taking into account that the intended status of this document is Informational I do not believe that these are blocking, however it would be good if they were clarified: 1. In section 2.2.2, which mechanism is used for the PCE congestion? The congestion notification mechanism is mentioned in the document. When there are not sufficient resources for lager number of PCEs, what to do exactly? The document should specify the detailed mechanisms or some references from other documents. 2. When the PCEs are not capable of the complex P2MP reoptimization functionality, which other methods may be used? I like the Manageability Considerations section. I have a few clarification questions and editorial comments. 3. in the intorduction to section 8 > The use of PCE to compute P2MP paths has many of the same manageability considerations as when it is used for P2P LSPs. A reference for these manageability considerations would be useful 4. section 8.2 - it is not clear what is meant by > This will result in much larger data sets to be controlled and modeled and will impact the utility of any management data models, such as MIB modules. If you mean that the data model becomes that complex that the efficiency of configuring by SNMP and MIB modules is in doubt - maybe it's better to say it explicitly. Other protocols and data modelling structures lile NETCONF / NETMOD could be considered 5. In section 8.3 the word 'this' after the period should be capitalized 'This' 6. Maybe we can find a less colourful term than 'nervous LSRs'
(Lisa Dusseault; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
This is an applicability statement for a piece of protocol that has not yet been written. It is not a re-use of the defined PCE Protocol; the document says that "some extensions are needed." This document is distinct from the p2mp PCE requirements document.
(Tim Polk; former steering group member) No Objection
From Brian Weis' secdir review (posted 6/15) The "Note" in the Security Considerations section points out that P2MP computation is CPU-intensive, and posits that an attacker injecting spurious P2MP path computation requests may be more successful than if the attacker injected P2P computation requests. Since you brought up the attack, it would be worth noting that the use of a message integrity mechanism by a PCE protocol should be used to mitigate attacks from devices that are not authorized to send requests to the PCE device. I hesitate to be more specific because the document does not describe a particular PCE protocol.
(Adrian Farrel; former steering group member) Recuse