jp -
the issue is not editorial, and is not (only) algorithmic because it has
comm.protocol impact
the text should read such as to indicate that the inclusion of the old
path in the PCC->PCE request is such as
1) to avoid the PCE taking into account resources used by the path during
new path computation (pruning)
2) to bind the gain obtained with this newly computed path vs modification
implied from the old path
hence, there are two possibilities
o) either the PCC->PCE request should include as part of the request the
expect, the gain from which PCC would accept receiving a different path
from the PCE, and return the new path iff this gain is attained (PCE
driven decision)
o) or the PCE should provide in the response the gain between the old and
new path, together with the new path (PCC driven decision)
otherwise each time a new path, the requesting PCC will not have the
possibility to assess what is the value of the answer (i.e. the new path)
wrt to the modification from the current path
thanks,
- dimitri.
JP Vasseur <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/01/2006 15:15
To: "Igor Bryskin" <[EMAIL PROTECTED]>
cc: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Pce] RE: I-D
ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt
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 -----
From: [EMAIL PROTECTED]
To: JP Vasseur
Cc: [EMAIL PROTECTED]
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.
"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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
