Subject: RE: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt

From: "Ash, Gerald R \(Jerry\)" <[email-masked]>
Date: Sat, 7 Jan 2006 18:33:49 -0600

> I'll stop the discussion here and let the authors of this ID and the 
> WG voice their opinion but it is I think quite important to avoid 
> unnecessary complexity if not required.

I agree with JP here.  I have made a similar comment a few times wrt
complexity of other PCE requirements...

For reoptimization, IMO it is sufficient to request reoptimization and
specify the current path.  As suggested earlier by Dimitri, I think this
wording of the requirement is fine:
"The path computation request message MUST indicate if the computation
is for path reoptimization of the TE LSP and MUST include the current
path of this LSP."

I think specifying thresholds for 'how much improvement will a PCC
accept', etc., is more complex that needed at this stage.

Perhaps we can add such a capability in a later phase, after we get some
experience to verify that it is really needed.

Thanks,
Jerry

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 12 Jan 2006 23:58:49 +0100

Hi Dimitri,

[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 

[JLLR] You have actually the same problem in packet networks when you want to move a set of TE-LSPs. This is a well known "Morphing" problem.
I agree with you that when doing a global reoptimization (that is taking into account all LSPs in a coordinated manner) so as to improve a global crieria (e.g. Minimize aggregate bandwidth consumption on all links), you may want to take into account the set of old paths so as to avoid blocking issues, and maybe also to minimize the number of rerouted LSPs (minimum perturbation problem): If L1 is the initial LSPs layout and L2 the final layout there are algorithms that compute L2 taking into account L1 so as to allow L1-> L2 migration without any blocking issue. 

However when you are reoptimizing on a per LSP basis, i.e. in a greedy manner (for instance you are looking for a better path cost), the problem is quite different. If you achieve to find a better path this means that there are ressources available on this better path so I don't see any transient ressource issue here. I agree that during the mb4b reoptimization you will consume more ressources but they are available anyway...
By the way, trying to maximize link reutilization could become counter productive w.r.t the reoptimization objective. You combine two competitive criterias. You will end up with requests such as "Try to reduce the path cost form X% while reusing at least Y% of links"...This will rapidily become unmanageable from an operational point of view.

Best Regards,

JL

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Envoyé : samedi 7 janvier 2006 19:22
> À : JP Vasseur
> Cc : [email-masked]; [email-masked]
> Objet : Re: [Pce] RE: I-D 
> ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt
> 
> JP Vasseur <[email-masked]>
> 07/01/2006 18:36
>  
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Igor Bryskin" <[email-masked]>, [email-masked], 
> [email-masked]
>         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-masked] 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-masked]>
> > Sent by: [email-masked]
> > 07/01/2006 15:15
> >
> >         To:     "Igor Bryskin" <[email-masked]>
> >         cc:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
> [email-masked]
> >         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-masked]
> > To: JP Vasseur
> > Cc: [email-masked]
> > 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-masked] 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-masked]>
> > Sent by: [email-masked]
> > 28/12/2005 18:18
> >
> >         To:        <[email-masked]>
> >         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-masked]
> > [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Wednesday, December 28, 2005 10:50 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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
> >

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 13 Jan 2006 00:05:42 +0100

Hi Jerry, all, 

> [mailto:[email-masked]] De la part de Ash, Gerald 
> R (Jerry)
> Envoyé : dimanche 8 janvier 2006 01:34
> À : [email-masked]; JP Vasseur
> Cc : [email-masked]
> Objet : RE: [Pce] RE: I-D 
> I agree with JP here.  I have made a similar comment a few 
> times wrt complexity of other PCE requirements...
> 
> For reoptimization, IMO it is sufficient to request 
> reoptimization and specify the current path.  As suggested 
> earlier by Dimitri, I think this wording of the requirement is fine:
> "The path computation request message MUST indicate if the 
> computation is for path reoptimization of the TE LSP and MUST 
> include the current path of this LSP."

This re-wording sounds good to me. 
The requirement is quite straightforward by the way.
There is functionally nothing new from what is performed today on head-end LSRs...

> 
> I think specifying thresholds for 'how much improvement will 
> a PCC accept', etc., is more complex that needed at this stage.

I agree. IMO this introduces useless complexity at this stage. As well pointed out by JP the path needs to be computed anyway so why not replying and letting the PCC decide whether the LSP has to be reoptimized or not?

Regards,

JL

> 
> Perhaps we can add such a capability in a later phase, after 
> we get some experience to verify that it is really needed.
> 
> Thanks,
> Jerry
>