JP Vasseur <[EMAIL PROTECTED]>
07/01/2006 18:36
To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
cc: "Igor Bryskin" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [Pce] RE: I-D
ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt
On Jan 7, 2006, at 12:13 PM, [EMAIL PROTECTED] wrote:
> 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)
>
Make it simple, please ! Or at least not unnecessarily complicated ...
[dp] re-optimization is a complex topic in any case; now the purpose here
is that if you leave the PCC making a full re-check i don't think the
global system is getting simpler because such operation will have to be
performed in a way or another as i don't think it is a common practice to
create unnecessary transients for the sake of a potentially infinitesimal
gain; in brief, there is a set of operations to be performed in a
re-optimization process and proposal here is to make use of a more
convenient distribution of these operations
The PCC will issue a regular request but in this case it will mention
that this is for en existing LSP whose path is XYZ ... The PCE(s)
will then deduct the bw of the existing path and compute a new path
returned to the requester. As already explained, the PCC has to
provide the existing path because otherwise the PCE would not provide
the best results. If it turns out that the PCC does not want to use
it because it is not significantly better this is the decision of the
PCC: in any case, the PCE will have to compute the path, so it is
easier to just provide it and let the PCC decide rather than adding a
complex semantic in the request. As already pointed, this is how TE
implementations with co-located PCEs have been working for years.
[dp] the solution leaving the PCC making this decision is possible (see
above, second bullet, PCC-driven decision process), what is important to
avoid is a system where the PCC gets a new path and has to make a complete
check whether the newly received path is of any value wrt to modification
it implies
There is no need to specify a complex semantic such as: I have a path
X whose cost is Y, provide me a path if the newly computed path
(considering that this is a reop) is better by x% ... You could also
add a ton of other constraints in this case ... (hop counts, SRLG in
common, ...).
[dp] you could simply leave the PCE providing its estimation to the PCC as
stated above (btw, constraints that can be used in the re-optimization
process are the same than the those used for the initial computation; if
the feeling is that we have too much mandatory constraints then one should
revisit the latter set)
Now if you want to add other constraint such as "try to re-use the
max number of common links", this is another requirement (with side
effects: my opinion and I'll let the WG decide here).
[dp] as stated previously, it is part of the set of constraints that
should be allowed in the context of a re-optimization process; for inst.
in non-PSC networks, in particular, one of the big concerns in the
re-optimization process is the sum of transient resources requires
I'll stop the discussion here and let the authors of this ID and the
WG voice their opinion but it it I think quite important to avoid
unnecessary complexity if not required.
JP.
> 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
