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

From: [email-masked]
Date: Fri, 6 Jan 2006 22:13:36 +0100

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

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 

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

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

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Jan 2006 17:51:58 -0500

Hi,

On Jan 6, 2006, at 4:13 PM, [email-masked] wrote:

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

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

JP.

>         Subject:        [Pce] RE: I-D ACTION:draft-ietf-pce-comm- 
> protocol-gen-reqs-03.txt
>
>
>
> Hi All,
>
>                 Title                                  : PCE  
> Communication Protocol Generic
> Requirements
>                 Filename                 : draft-ietf-pce-comm- 
> protocol-gen-reqs-03.txt
>                 Pages                                  : 22
>                 Date                                  : 2005-12-28
>

---

From: [email-masked]
Date: Sat, 7 Jan 2006 00:15:30 +0100

hi - see in-line

hi jerry 

section 6.1.17 mentions 

Right.

section 6.3.14 

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. 

        To:        <[email-masked]> 
        cc:         
        Subject:        [Pce] RE: I-D 

Hi All,

Thanks,
Regards,
Jerry

---

From: JP Vasseur <[email-masked]>
Date: Fri, 6 Jan 2006 18:29:50 -0500

On Jan 6, 2006, at 6:15 PM, [email-masked] wrote:

> (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;
>

Yes, there is an indication for reoptimization

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

No you missed my point. The purpose of providing the existing path is  
for the PCE to take into account the bw used by the existing LSP  
while computing the new path (which might be more optimal).

JP.

---

From: [email-masked]
Date: Sat, 7 Jan 2006 01:43:28 +0100

JP Vasseur <[email-masked]>
07/01/2006 00:29
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Ash, Gerald R ((Jerry)), ALABS" <[email-masked]>, 
[email-masked]
        Subject:        Re: [Pce] RE: I-D 
ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt

hi - see in-line 

hi jerry 

section 6.1.17 mentions 

Right. 

section 6.3.14 

[dp] ok

No you missed my point. The purpose of providing the existing path is for 
the PCE to take into account the bw used by the existing LSP while 
computing the new path (which might be more optimal).

[dp] ok, you mean that a re-optimization computation is to be performed by 
taking only into account the global network resource consumption pruned 
from the bandwidth used by the LSP requesting re-optimization (hence, as 
if it was a newly requested path) but you don't take into account the 
constraint put by the current path itself ... imho, this should be 
policy-driven as it is dependent on the gain obtained (in terms of 
bandwidth for inst.) vs modification implied

JP.

JP. 

thanks, 
- dimitri. 

        To:        <[email-masked]> 
        cc:         
        Subject:        [Pce] RE: I-D 

Hi All,

Thanks,
Regards,
Jerry

---

From: "Igor Bryskin" <[email-masked]>
Date: Sat, 7 Jan 2006 09:03:12 -0500

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

  hi jerry 

  section 6.1.17 mentions 

  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 

  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. 

                To:        <[email-masked]> 
                cc:         
                Subject:        [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt 

  Hi All,

  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 

                  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

------------------------------------------------------------------------------

---

From: JP Vasseur <[email-masked]>
Date: Sat, 7 Jan 2006 09:15:29 -0500

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:
>
> 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.

---

From: [email-masked]
Date: Sat, 7 Jan 2006 15:41:25 +0100

igor, indeed, and as i indicated

a re-optimization computation is to be performed not only by taking into 
account the global network resource consumption pruned from the bandwidth 
used by the LSP requesting re-optimization (hence, as if it was a newly 
requested path) but also taking account the constraint put by the current 
path itself;

this should be policy-driven as it is dependent on the gain obtained (in 
terms of bandwidth for inst.) vs modification implied ... this means the 
"re-optimization" process is bound; 

to come to the text, it reads as "optimization" is the only criteria 
independently of gain and impact 

"Igor Bryskin" <[email-masked]>
Sent by: [email-masked]
07/01/2006 15:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur" 
<[email-masked]>
        cc:     [email-masked]
        Subject:        Re: [Pce] RE: I-D 
ACTION:draft-ietf-pce-comm-protocol-gen-reqs-03.txt

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 ----- 
From: [email-masked] 
To: JP Vasseur 
Cc: [email-masked] 
Sent: Friday, January 06, 2006 6:15 PM
Subject: Re: [Pce] RE: I-D 

hi - see in-line 

hi jerry 

section 6.1.17 mentions 

Right. 

section 6.3.14 

JP. 

thanks, 
- dimitri. 

        To:        <[email-masked]> 
        cc: 
        Subject:        [Pce] RE: I-D 

Hi All,

Thanks,
Regards,
Jerry

---

From: JP Vasseur <[email-masked]>
Date: Sat, 7 Jan 2006 10:07:49 -0500

Hi,

On Jan 7, 2006, at 9:46 AM, Igor Bryskin wrote:

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

Well I do not think that we need to spell all the reasons ;-) ... in  
the requirement document.

The optimization that you have mentioned above exist in several  
implementations already with co-located PCE, along with many other ones.

Thanks.

JP.

> From: JP Vasseur
> To: Igor Bryskin
> Cc: [email-masked] ; [email-masked]
> Sent: Saturday, January 07, 2006 9:15 AM
>> management activities that could adversely affect network  
>> stability (Dimitri's point)
>>
>
> 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.
>
>> multiple functions, there is no "simple" default anymore one  
>> should assess the impact of such implication
>>
>>
>> Right.
>>
>> section 6.3.14
>>
>> "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-

---

From: "Igor Bryskin" <[email-masked]>
Date: Sat, 7 Jan 2006 09:46:37 -0500

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 ----- 
  From: JP Vasseur 
  To: Igor Bryskin 
  Cc: [email-masked] ; [email-masked] 
  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,

    Hi,

  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.

  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 

      hi jerry 

      section 6.1.17 mentions 

      Right. 

      section 6.3.14 

      JP. 

      thanks, 
      - dimitri. 

                    To:        <[email-masked]> 
                    cc:         

      Hi All,

      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 

                      

--------------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 7 Jan 2006 18:13:20 +0100

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.

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,

Hi,

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.

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 

hi - see in-line 

hi jerry 

section 6.1.17 mentions 

Right. 

section 6.3.14 

JP. 

thanks, 
- dimitri. 

        To:        <[email-masked]> 
        cc:         
        Subject:        [Pce] RE: I-D 

Hi All,

Thanks,
Regards,
Jerry

---

From: JP Vasseur <[email-masked]>
Date: Sat, 7 Jan 2006 12:36:41 -0500

> new path, together with the new path (PCC driven decision)

Make it simple, please ! Or at least not unnecessarily complicated ...

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.

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

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

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.

> example
> "new path"
> multiple
> since it
> double
> the two
> refers to as
> there an
> is to

---

From: [email-masked]
Date: Sat, 7 Jan 2006 19:21:41 +0100

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

[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

[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

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

[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

JP.