Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
Note: This ballot was opened for revision 01 and is now closed.
( Ross Callon ) Yes
( Ron Bonica ) No Objection
( Ralph Droms ) No Objection
( Lisa Dusseault ) No Objection
( Lars Eggert ) No Objection
Comment (2009-06-16 for -)
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".
( Pasi Eronen ) No Objection
( Russ Housley ) No Objection
Comment (2009-06-15 for -)
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.
( Alexey Melnikov ) No Objection
( Tim Polk ) No Objection
Comment (2009-06-17 for -)
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.
( Dan Romascanu ) No Objection
Comment (2009-06-17 for -)
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'