datatracker.ietf.org
Sign in
Version 5.6.3.p2, 2014-09-29
Report a bug

Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
draft-ietf-pce-p2mp-app-02

Note: This ballot was opened for revision 01 and is now closed.

Summary: Needs a YES.

[Dan Romascanu]

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'

[Lars Eggert]

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".

[Russ Housley]

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.

[Tim Polk]

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.