|
Hi.
I probably misunderstood the Dimitiri's point. In
this case I have a point of my own :=)
If a PCE, while performing path
re-optimization, finds out that a new path exists and it has the same (or even
insignificantly better) cost as the old path.
Would it be beneficial if the PCE in this case
returns the old path rather than the new path? I think yes, because in this case unnecessary resource management
activities would be avoided. The point is that there is another reason (apart
from avoiding double booking) to pass to PCE the old path in the path
re-optimization request, which I suggest to be spelled out
Igor
----- Original Message -----
Sent: Saturday, January 07, 2006 9:15
AM
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
-----
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
|
