Note: This ballot was opened for revision 01 and is now closed.
Summary: Needs a YES.
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
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'
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".
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.
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.