Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-02.txt

From: [email-masked]
Date: Thu, 20 Aug 2009 07:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element Working Group of the IETF.

	Title           : PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
	Author(s)       : S. Yasukawa, A. Farrel
	Filename        : draft-ietf-pce-p2mp-req-02.txt
	Pages           : 10
	Date            : 2009-08-20

The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multi-Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have
been made in support of point-to-multipoint (P2MP) Traffic Engineered
(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is
already established, and since P2MP TE LSP routes are sometimes
complex to compute, it is likely that PCE will be used for P2MP LSPs.

Generic requirements for a communication protocol between Path
Computation Clients (PCCs) and PCEs are presented in "Path
Computation Element (PCE) Communication Protocol Generic
Requirements". This document complements the generic requirements and
presents a detailed set of PCC-PCE communication protocol
requirements for point-to-multipoint MPLS/GMPLS traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-p2mp-req-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Aug 2009 15:46:00 +0100

Hi,

This revision only updates references and authors' coordinates.

The authors believe that this work is pretty much done, but we are waiting 
for the protocol extensions to stabilise.

We would welcome review input and especially comments from the people 
working on the protocol extensions. Have we explained all of the 
requirements clearly? have you come across anything else that we haven't 
captured?

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 20, 2009 3:30 PM
Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-02.txt

> Title           : PCC-PCE Communication Requirements for Point to 
> Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)

--------------------------------------------------------------------------------

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Fabien Verhaeghe <[email-masked]>
Date: Fri, 21 Aug 2009 09:46:16 +0200

Hi Adrian,

2 minor comment/question

2.1.10
"Therefore, a P2MP Path Computation Request SHOULD
   contain a parameter that allows the PCC to express a cost-benefit
   reoptimization threshold for the whole LSP as well as per
   destination"

Just to be sure to capture correctly this new requirement for the future
P2MP protocol extensions.
Basically that means encoding a new opaque to PCEP field (for instance in a
new object or TLV) that would be pass to PCE policy module.
Is that correct?

2.1.11.
"  It MAY also be possible to indicate on a path computation request a
   cost-benefit reoptimization threshold such that the tree and/or a new
   path to any individual destination is not supplied unless a certain
   improvement is made. Compare with Section 2.1.10."

Does it mean that a PCE may deny the addition of a leaf because the tree
does not provide
certain improvement?
Or do you rather mean that the PCE would not change the existing Path unless
it provides certain improvment?

I guess second option makes more sense. If correct I would suggest something
like:
"The addition of new leaves will not cause reoptimization of the existing
P2MP tree unless a certain improvement is made."
BR
Fabien
On Thu, Aug 20, 2009 at 4:46 PM, Adrian Farrel <[email-masked]> wrote:

> ----- Original Message ----- From: <[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Aug 2009 12:06:45 +0100

Hello Fabien,

> P2MP protocol extensions.

For some definition of "new" :-)

This requirement was in the draft (dated May 2008) that the working group 
accepted as a working group document.

> Basically that means encoding a new opaque to PCEP field (for
> instance in a new object or TLV) that would be pass to PCE
> policy module.
> Is that correct?

I don't think it has to be like that.

I think a number of the PCEP data are transparent, but are still passed to 
(optionally) to the PCE policy module. Is this PCC allowed to request this 
type of computation for this type of service? Reoptimization is more subtle 
than initial computation because it can disrupt traffic. So reoptimization 
can also be subject to policy on the PCE relating to by how much a 
computation must be "better" than the in-place path, before the new path is 
returned to the requester.

In RFC 5440, we deal with reoptimization of individual drafts. The METRIC 
object contains the B flag. This allows the PCC to effectively set a 
reoptimization threshold - and the value supplied could be less than the 
value of the actual path.

Reoptimizing a single P2MP LSP is like a cross between RFC 5440 and RFC 
5557. There is only one LSP, but there are multiple destinations. As for the 
first computation, the PCC needs to be able to indicate how the LSP is to be 
optimized (e.g., shortest path to detination, least cost tree, etc.), but 
since the LSP is already in place and reoptimization of one factor may make 
another factor worse, there will be a trade-off. Thus, the reoptimization 
request needs to be able to guide the PCE as to which factors to reoptimize 
for and what are the acceptable variations of the other factors. 
Additionally, as for the p2p case, an optimization of a very small 
percentage may be considered unwise.

All of these P2MP parameters, just like any other PCEP parameter, is subject 
to policy at the PCE. The PCE is likely to be aware of network policies and 
the concept of "fareness". It may protect the other PCCs against a greedy 
PCC, and it may protect the network against instability.

> does not provide certain improvement?

Yes, the original wording is broken.

Your suggestion is good.

This paragraph now reads...

   It MAY also be possible to indicate on a path computation request a
   cost-benefit reoptimization threshold such that the addition of new
   leaves will not cause reoptimization of the existing P2MP tree unless
   a certain improvement is made over simply grafting the new leaves to
   the existing tree. (Compare with Section 2.1.10.)

Cheers,
Adrian

>>> This draft is a work item of the Path Computation Element Working Group 
>>> of
>>> the IETF.
>>>
>>>