Hi Igor,On Jan 7, 2006, at 9:03 AM, Igor Bryskin wrote: Hi, I think both Dimitri and JP are correct here. While performing re-optimization path computation PCE needs to know about the old path for two reasons: a) Not to block TE links that do not have enough bandwidth (JP's point) b) Not to route the new path unnecessarily over new TE links (for example in case of equal cost paths) to avoid extra resource management activities that could adversely affect network stability (Dimitri's point)
Well note that (a) is clearly mandatory and easy to understand.
Dimitri's point on whether the PCE should try to "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" is arguable since this may lead to a less optimal path of course. But this is an algorithmic aspect that does not need to be standardized.
Bottom line is that the only request was editorial to clarify the need.
Thanks.
JP. Igor ----- Original Message ----- Sent: Friday, January 06, 2006 6:15 PM Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt
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;
[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)
JP.
thanks,
- dimitri.
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
|
