Hello Fabien,
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.
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.
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."
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
On Thu, Aug 20, 2009 at 4:46 PM, Adrian Farrel <[email protected]>
wrote:
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 protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Thursday, August 20, 2009 3:30 PM
Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-02.txt
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.
--------------------------------------------------------------------------------
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
