| JP Vasseur <[EMAIL PROTECTED]>
07/01/2006 00:29 |
To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED] cc: "Ash, Gerald R ((Jerry)), ALABS" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt |
On Jan 6, 2006, at 6:15 PM, [EMAIL PROTECTED] wrote:
hi - see in-line
On Jan 6, 2006, at 4:13 PM, [EMAIL PROTECTED] wrote:
hi jerry
section 6.1.17 mentions
The PCECP MUST support the following "unsynchronized" objective
functions:
o Minimum cost path (shortest path)
o Least loaded path (widest path)
o To be determined
not sure to understand the last bullet, this said by mandating multiple functions, there is no "simple" default anymore one should assess the impact of such implication
Right.
section 6.3.14
" The path computation request message MUST support TE LSP path
reoptimization and the inclusion of a previously computed path."
i don't understand the sentence, how a message can support re-optimization; i think you mean here that an indication is required as part of the message ?
btw, the only that differentiates the path request for re-routing vs re-optimization is timing, and that the former must support inclusion of the failed element and the "old path" this is not the case for re-optimization
" This will help ensure optimal routing of a reoptimized path, since it will
allow the PCE to avoid double bandwidth accounting and help reduce
blocking issues."
the fact of giving the "old path" is not an indication of avoiding double bandwidth accounting (it is linked to make-before-break process) nor ensuring optimal routing
Well this is easy to understand. You must be able to differentiate the two following cases:
(1) PCC requests a path computation for a new LSP
(2) PCC requests a path computation for an existing LSP: this refers to as the reoptimization case and of course, the PCC needs to provide the existing path to avoid double bandwidth accounting that could lead to sub-optimal path ...
[dp] understood but the answer depends on the first point i.e. is there an explicit indication for re-optimzation or not - the sentence says "and" the inclusion so i consider this is an information put in addition of the explicit indication ? please confirm or infirm because the sentence is open to interpetation;
Yes, there is an indication for reoptimization
[dp] ok
[dp] now, the only purpose for having this additional information is to force the "new path" to make use as much as possible of the "old path" such as to minimize the sum of the resources required by the old and the new path during the transient period of re-optimization (hence, including the "old path" is not an indication for avoiding double booking it is an indication for minimizing the transient resource required for the re-optimization)
No you missed my point. The purpose of providing the existing path is for the PCE to take into account the bw used by the existing LSP while computing the new path (which might be more optimal).
[dp] ok, you mean that a re-optimization computation is to be performed by taking only into account the global network resource consumption pruned from the bandwidth used by the LSP requesting re-optimization (hence, as if it was a newly requested path) but you don't take into account the constraint put by the current path itself ... imho, this should be policy-driven as it is dependent on the gain obtained (in terms of bandwidth for inst.) vs modification implied
JP.
JP.
thanks,
- dimitri.
| "Ash, Gerald R \(Jerry\),
ALABS" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 28/12/2005 18:18 |
To: <[EMAIL PROTECTED]> cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt |
Hi All,
Please review and comment on the updated version of the PCE
communications protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt.
Per our agreements at IETF-64 (see JL's slide at
http://www3.ietf.org/proceedings/05nov/slides/pce-11/sld7.htm), the
referenced requirements in the inter-area PCECP requirements draft have
been moved into the generic PCECP requirements draft. In particular,
- Section 6.1.17 'Objective Functions Supported' was added
- Section 6.3.4 'LSP Rerouting & Reoptimization' was updated
Our objective is to start a WG last call soon. We look forward to your
review and comments.
Thanks,
Regards,
Jerry
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, December 28, 2005 10:50 AM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.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 : PCE Communication Protocol Generic
Requirements
Author(s) : J. Le Roux, J. Ash
Filename : draft-ietf-pce-comm-protocol-gen-reqs-03.txt
Pages : 22
Date : 2005-12-28
The PCE model is described in the "PCE Architecture" document and
facilitates path computation requests from Path Computation Clients
(PCCs) to Path Computation Elements (PCEs). This document specifies
generic requirements for a communication protocol between PCCs and
PCEs, and also between PCEs where cooperation between PCEs is
desirable. Subsequent documents will specify application-specific
requirements for the PCE communication protocol.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-03.txt
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
