Re: [Pce] I-D Action:draft-ietf-pce-p2mp-req-02.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pce] I-D Action:draft-ietf-pce-p2mp-req-02.txt
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
<adrian at olddog.co.uk> 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: <Internet-Drafts at ietf.org>
To: <i-d-announce at ietf.org>
Cc: <pce at ietf.org>
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
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.