Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
RFC 5671

Note: This ballot was opened for revision 02 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 -)
No email
send info
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 -)
No email
send info
  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 -)
No email
send info
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 -)
No email
send info
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'

(Robert Sparks) No Objection

(Adrian Farrel) Recuse