|
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)
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
|
