Subject: [Pce] Finally: WG Chair review on GCO

From: JP Vasseur <[email-masked]>
Date: Fri, 12 Sep 2008 16:58:40 +0200

Hi,

Here is my WG chair review, Adrian has done his part.

First I must say that I was first inclined to propose to follow the
experimental track. That being said, you managed to clearly explain that GCO
was applicable to a subset of cases and the PCC would be an NMS as opposed
to a set of LSRs, which were my main concerns. So I think that we are fine
following the standard track.

Abstract
S/invisaged/envisaged (appears in several places)
S/ gloablly/globally

Introduction

* ³ As new LSPs are added or removed from the network over time, the
   global network resources become fragmented and the existing placement
   of LSPs within network no longer provides optimal use of the
   available capacity.  A global concurrent path computation is able to
   simultaneously consider the entire topology of the network and the
   complete set of existing LSPs and their respective constraints, and
   look to re-optimize the entire network to satisfy all constraints for
   all LSPs.  Alternatively, the application may consider a subset of
   the LSPs and/or a subset of the network topology.
³

JP> I would suggest to also add: ³Note that other preemption can also help
reducing the fragmentation issues².

* JP> I remembers having made comments to warn the reader on the
applicability of GCO to environments with a high degree od dynamicity and
smal LSP bw/link speed ratios. TO that end, you added:

   ³While GCO is applicable to any simultaneous request for multiple LSPs
   (for example, a request for end-to-end protection), it is not
   invisaged that global concurrent reoptimization would be applied in a
   network (such as an MPLS-TE network) that contains a very large
   number of very low bandwidth or zero bandwidth LSPs since the large
   scope of the problem and the small benefit of concurrent
   reoptimization relative to single LSP reoptimization is unlikely to
   make the process worthwhile.  Further, applying global concurrent
   reoptimization in a network with a high rate of change of LSPs
   (churn) is not advised because of the likelihood that LSPs would
   change before they could be gloablly reoptimized.  Global
   reoptimization is more applicable to stable networks such as
   transport networks or those with long-term TE LSP tunnels.²

And

³ However, the key point remains: computing the reoptimized
   path of one LSP at a time without giving any consideration to the
   other LSPs in the network could result in sub-optimal use of network
   resources.  This may be far more visible in an optical network with a
   low ratio of potential LSPs per link, and far less visible in packet
   networks with micro-flow LSPs.²

Which is good !

JP> I would still want to suggest some NORMATIVE language here, thus
replacing ³it is not envisaged² by ³it is NOT RECOMMEMDED² and ³Further,
applying global concurrent reoptimization in a network with a high rate of
change of LSPs   (churn) is not advised² by ³Further, applying global
concurrent reoptimization in a network with a high rate of change of LSPs
(churn) is NOT RECOMMENDED³

* ³As the PCE has the potential to provide solutions in all path
   computation solutions in a variety of environments and is a candidate
   for performing path computations in support of GCO.²

JP> Word missing in this sentence above ?

Terminology

* ³ GCO: Global Concurrent Optimization: A concurrent path computation
   application where a set of TE paths are computed concurrently in
   order to efficiently utilize network resources.²

JP> May I suggest ³ GCO: Global Concurrent Optimization: A concurrent path
computation
   application where a set of TE paths are computed concurrently in
   order to optimize network resources.²

Section 3

* Greenfield operation: well, it never stays a greenfield for a long time
... As failure arise, TE LSPs get rerouted and it is no longer a greenfield.
* You wrote ³GCO could prevent race condition (i.e.,
   competing for the same resource from different head-end LSRs) that
   may be associated with a distributed computation. ³
JP> I would soften this since such issue could easily be solved with
distributed jittering.
* ³In other words, it may prove to be impossible
   to perform a direct migration from the old LSPs to the new optimal
   LSPs without disrupting traffic because there are insufficient
   network resources to support both sets of LSPs when make-before-break
   is used. ³
JP> This is true if you keep the bw of existing TE LSP unchanged but you
could certainly zeroed the TE LSPs before reoptimization to avoid
inter-lock. Could you just briefly mention it?

Section 4
³*  Overbooking Factor -- The overbooking factor allows the
         reserved bandwidth to be overbooked on each link beyond its
         physical capacity limit.²
JP> Why isn¹t it sufficient for the PCC to provide the bandwidth after
having dividing the bw by the over-booking factor?
*  ³As stated in RFC 4657, the request for a reoptimization MUST
         support the inclusion of the set of previously computed paths
         along with their bandwidth.  This is to avoid double bandwidth
         accounting and also this allows running an algorithm that
         minimizes perturbation and that can compute a migration path
         (LSP setup/removal orders).  This is particularly required for
         stateless PCEs.²
JP> Note that this is already supported by PCEP.

Section 5
* S/ Reported Route Objects (RROs)/Record Route Object
* ³D bit (orDer - 1 bit): when set, in a PCReq message, the requesting
   PCC requires the PCE to specify in the PCRep message the order in
   which this particular path request is to be provisioned relative to
   other requests.²
JP> What if the PCC sets this bit for a subset of the request in the SVEC
list ? (just mention it). Note also that ordering is not meaningful if the
PCC=NMS, not in a distributed system.
³The Order TLV SHOULD be included in the RP object in the PCRep
   message if the D bit is set in the RP object in the PCReq message.²
JP> Why a SHOULD and not a MUST ?

Section 6
* 6.5.  Requirements on Other Protocols and Functional Components

   The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used
   to advertise global concurrent path computation capabilities to PCCs.
JP> How ? New flags in PCE-CAP-FLAGS Sub-TLV ?

Others
In several places we use TE LSPs in other places LSPs. Can you make sure to
systematically use ³TE LSPs² ?

Thanks.

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 12 Sep 2008 17:00:39 +0200

------ Forwarded Message
From: JP Vasseur <[email-masked]>
Date: Fri, 12 Sep 2008 16:58:40 +0200
To: <[email-masked]>
Subject: [Pce] Finally: WG Chair review on GCO

Hi,

Abstract

Introduction

And

Which is good !

Terminology

Section 3

Section 4

Section 5

Section 6

Others

Thanks.

JP.

------ End of Forwarded Message

---

From: Young Lee <[email-masked]>
Date: Fri, 12 Sep 2008 17:09:29 -0500

Hi J-P,

Thanks a lot for spending time for your review. We can accommodate all your
comments in revision. We will shortly get back with you and Adrian. Please
see in-line for my response. 

Best Regards,

Young

  _____  

From: JP Vasseur [mailto:[email-masked]] 
Sent: Friday, September 12, 2008 10:01 AM
To: [email-masked]; [email-masked]; Jean-Louis Le Roux;
[email-masked]
Cc: [email-masked]
Subject: FW: [Pce] Finally: WG Chair review on GCO

------ Forwarded Message

Hi,

YOUNG>> Thank you. 

Abstract

YOUNG>> We will correct them. 

Introduction

* " As new LSPs are added or removed from the network over time, the
"

JP> I would suggest to also add: "Note that other preemption can also help
reducing the fragmentation issues".

YOUNG>> We will add. 

   "While GCO is applicable to any simultaneous request for multiple LSPs
   transport networks or those with long-term TE LSP tunnels."

And

" However, the key point remains: computing the reoptimized
   path of one LSP at a time without giving any consideration to the
   other LSPs in the network could result in sub-optimal use of network
   resources.  This may be far more visible in an optical network with a
   low ratio of potential LSPs per link, and far less visible in packet
   networks with micro-flow LSPs."

Which is good !

JP> I would still want to suggest some NORMATIVE language here, thus
replacing "it is not envisaged" by "it is NOT RECOMMEMDED" and "Further,
applying global concurrent reoptimization in a network with a high rate of
change of LSPs   (churn) is not advised" by "Further, applying global
concurrent reoptimization in a network with a high rate of change of LSPs
(churn) is NOT RECOMMENDED"

YOUNG>> Thanks! It will further clarify the application of GCO. We will add
this. 

* "As the PCE has the potential to provide solutions in all path
   computation solutions in a variety of environments and is a candidate
   for performing path computations in support of GCO."

YOUNG>> You're right. It should've read: "As the PCE has the potential to
provide solutions in all path
   computation solutions in a variety of environments, PCE is a candidate
   for performing path computations in support of GCO." 

YOUNG>> But it may not add much to the draft; I will delete this sentence. 

Terminology

* " GCO: Global Concurrent Optimization: A concurrent path computation
   application where a set of TE paths are computed concurrently in
   order to efficiently utilize network resources."

JP> May I suggest " GCO: Global Concurrent Optimization: A concurrent path
computation
   application where a set of TE paths are computed concurrently in
   order to optimize network resources."

YOUNG>> That's fine with me. Thanks. 

Section 3

 

YOUNG>> You're right. In some optical networks, however, it could stay
longer than IP/MPLS networks. So we included this operation. 

* You wrote "GCO could prevent race condition (i.e.,
   competing for the same resource from different head-end LSRs) that
   may be associated with a distributed computation. "
JP> I would soften this since such issue could easily be solved with
distributed jittering.

YOUNG>> I will modify something like: "Distributed jittering is a technique
that could prevent race condition (i.e., competing for the same resource
from different head-end LSRs) with a distributed computation. GCO provides
an alternative way that could prevent race condition. 

* "In other words, it may prove to be impossible
   is used. "

YOUNG>> Our assumption was to keep the b/w of the existing TE LSP in tact. I
don't understand how the TE LSPs could be zeroed before reoptimization. In
optical networks, there is no such thing as "zero" b/w LSP. In IP/MPLS
networks, I understand there are 0 b/w TE LSP, but when you zero the b/w of
an existing LSP and avoid inter-lock, how can you assure the re-optimized TE
LSP with the original committed B/W? Perhaps, I am missing something here.  

Section 4
"*  Overbooking Factor -- The overbooking factor allows the
         reserved bandwidth to be overbooked on each link beyond its
         physical capacity limit."
JP> Why isn't it sufficient for the PCC to provide the bandwidth after
having dividing the bw by the over-booking factor?

YOUNG>> It can be done by your suggested way. Ning So (Verizon) specified
this requirement for a good reason for his operation. I think it is a matter
of preference. I believe Overbooking Factor allows an easy way to request
multiple TE-LSP's in one shot, instead of going through additional
calculation individually. Do you want to ask Ning about this? 

*  "As stated in RFC 4657, the request for a reoptimization MUST
         stateless PCEs."

YOUNG>> This is in the context of GCO. When there are multiple TE-LSPs to be
re-optimized, can PCEP support multiple requests? I thought PCEP can do one
at a time. Please correct me if I am wrong on this. If we can this with
PCEP, I can remove this text. 

Section 5

YOUNG>> Thanks. We will correct. 

* "D bit (orDer - 1 bit): when set, in a PCReq message, the requesting
   other requests."

YOUNG>> The PCE would apply "ordering" only to the TE-LSP's whose D bit is
set in the RP object. The rest of the TE-LSPs in the SVEC wouldn't be
ordered. If PCC=NMS, this does not apply. 

"The Order TLV SHOULD be included in the RP object in the PCRep
   message if the D bit is set in the RP object in the PCReq message."
JP> Why a SHOULD and not a MUST ?

YOUNG>> It should be "MUST" - will change. 

Section 6

YOUNG>> Yes, we need to define a new flag (value = 9, if not taken yet) in
the current PCE-CAP-FLAGs. 

Others
In several places we use TE LSPs in other places LSPs. Can you make sure to
systematically use "TE LSPs" ?

YOUNG>> Will change globally. 

Thanks.

JP.

  _____

---

From: JP Vasseur <[email-masked]>
Date: Mon, 15 Sep 2008 08:11:22 +0200

Hi Young,

Thanks for accommodating the comments/suggestions. Just a few comments in
line,

On 9/13/08 12:09 AM, "Young Lee" <[email-masked]> wrote:

> comments in revision. We will shortly get back with you and Adrian. Please see
> in-line for my response.
>  
> Best Regards,
> Young
>  
> 
> 
> was applicable to a subset of cases and the PCC would be an NMS as opposed to
> a set of LSRs, which were my main concerns. So I think that we are fine
> * JP> I remembers having made comments to warn the reader on the applicability
> of GCO to environments with a high degree od dynamicity and smal LSP bw/link
> speed ratios. TO that end, you added:
> 
> JP> I would still want to suggest some NORMATIVE language here, thus replacing
> ³it is not envisaged² by ³it is NOT RECOMMEMDED² and ³Further, applying global
> (churn) is not advised² by ³Further, applying global concurrent reoptimization
> in a network with a high rate of change of LSPs (churn) is NOT RECOMMENDED³
>  
> YOUNG>> You¹re right. It should¹ve read: ³As the PCE has the potential to
> YOUNG>> That¹s fine with me. Thanks.
> 
> Section 3
> 
> * Greenfield operation: well, it never stays a greenfield for a long time ...
> As failure arise, TE LSPs get rerouted and it is no longer a greenfield.
>  
> YOUNG>> You¹re right. In some optical networks, however, it could stay longer
> than IP/MPLS networks. So we included this operation.
> 
> YOUNG>> I will modify something like: ³Distributed jittering is a technique
> that could prevent race condition (i.e., competing for the same resource from
> different head-end LSRs) with a distributed computation. GCO provides an
> alternative way that could prevent race condition.
> 
> JP> This is true if you keep the bw of existing TE LSP unchanged but you could
> certainly zeroed the TE LSPs before reoptimization to avoid inter-lock. Could
> you just briefly mention it?
>  
> don¹t understand how the TE LSPs could be zeroed before reoptimization. In
> optical networks, there is no such thing as ³zero² b/w LSP. In IP/MPLS
> networks, I understand there are 0 b/w TE LSP, but when you zero the b/w of an
> existing LSP and avoid inter-lock, how can you assure the re-optimized TE LSP
> with the original committed B/W? Perhaps, I am missing something here.
> 
> JP> I was referring to the packet TE LSP case where you could use a 3-step
> technique to reoptimize to TE LSPs that ³block² each other for example. Is
> this case, you perform a make=before-break along the new path for the first TE
> LSPs but with 0-bandwidth, then you do a make-before-break along the new path
> for the second TE LSP again with 0-bandwidth but finally to do a
> make-before-break for both TE LSPs (no change in the path) but with their
> actual bandwidth. Of course, this only applies to packet TE LSPs.
> 
> Section 4
> JP> Why isn¹t it sufficient for the PCC to provide the bandwidth after having
> dividing the bw by the over-booking factor?
>  
> YOUNG>> It can be done by your suggested way. Ning So (Verizon) specified this
> requirement for a good reason for his operation. I think it is a matter of
> preference. I believe Overbooking Factor allows an easy way to request
> multiple TE-LSP¹s in one shot, instead of going through additional calculation
> individually. Do you want to ask Ning about this?
> 
> JP> This is fine as is. I was just wondering whether you looked at this
> alternative but since it does not overload the protocol too much, leave it
> unchanged.
> 
> re-optimized, can PCEP support multiple requests? I thought PCEP can do one at
> a time. Please correct me if I am wrong on this. If we can this with PCEP, I
> can remove this text.
> 
> JP> You can do this with the current spec.
>  
>              R (Reoptimization - 1 bit): when set, the requesting PCC
> specifies
>       that the PCReq message relates to the reoptimization of an
>       existing TE LSP.  For all TE LSPs except 0-bandwidth LSPs, when
>       the R bit is set, an RRO (see Section 7.10) MUST be included in
>       the PCReq message to show the path of the existing TE LSP.  Also,
>       for all TE LSPs except 0-bandwidth LSPs, then the R bit is set,
>       the existing bandwidth of the TE LSP to be reoptimized MUST be
>       supplied in a BANDWIDTH object (see Section 7.7).  This BANDWIDTH
>       object is in addition to the instance of that object used to
>       describe the desired bandwidth of the reoptimized LSP.  For
>       0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the
>       characteristics of the existing TE LSP are optional.
> 
> Then in section 7.7:
> 
>    In the case of the reoptimization of a TE LSP, the bandwidth of the
>    existing TE LSP MUST also be included in addition to the requested
>    bandwidth if and only if the two values differ.  Consequently, two
>    Object-Type values are defined that refer to the requested bandwidth
>    and the bandwidth of the TE LSP for which a reoptimization is being
>    performed.
> 
> 
> 
> Section 5
> JP> What if the PCC sets this bit for a subset of the request in the SVEC list
> ? (just mention it). Note also that ordering is not meaningful if the PCC=NMS,
> not in a distributed system.
>  
> YOUNG>> The PCE would apply ³ordering² only to the TE-LSP¹s whose D bit is set
> in the RP object. The rest of the TE-LSPs in the SVEC wouldn¹t be ordered. If
> PCC=NMS, this does not apply.
> 
> JP> Two questions:
> 1) How does the PCC which TE LSP to order. I would have thought of a mechanism
> where the PCC signals to the PCE its flexibility to accept ordering (global
> request) to which the PCE could respond with or without ordering ?
> 2) What if the ³global² request can be satisfied only if all reoptimization
> have their D flag set (and only a subset of them have the D flag set) ?
> 
> 
> YOUNG>> It should be ³MUST²  will change.
> 
> 
> Section 6
> YOUNG>> Yes, we need to define a new flag (value = 9, if not taken yet) in the
> current PCE-CAP-FLAGs.
> 
> 
> 
> Others

---

From: Young Lee <[email-masked]>
Date: Mon, 15 Sep 2008 16:28:08 -0500

Hi J-P,

Thanks for your prompt reply. I think we are merging. Please see in-line for
my response to your comments. 

Hi J-L,

You may be the right person who can elaborate more on J-P's question on
D-bit. I'd appreciate if you can provide your comments for the D-bit
question below. 

Best Regards,

Young

  _____  

From: JP Vasseur [mailto:[email-masked]] 
Sent: Monday, September 15, 2008 1:11 AM
To: Young Lee; [email-masked]; 'Jean-Louis Le Roux';
[email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Finally: WG Chair review on GCO

Hi Young,

Hi J-P,

Best Regards,
Young

  _____  

------ Forwarded Message

Hi,

YOUNG>> Thank you. 

Abstract

Introduction

YOUNG>> We will add. 

And

Which is good !

 

Terminology

Section 3

JP> I was referring to the packet TE LSP case where you could use a 3-step
technique to reoptimize to TE LSPs that "block" each other for example. Is
this case, you perform a make=before-break along the new path for the first
TE LSPs but with 0-bandwidth, then you do a make-before-break along the new
path for the second TE LSP again with 0-bandwidth but finally to do a
make-before-break for both TE LSPs (no change in the path) but with their
actual bandwidth. Of course, this only applies to packet TE LSPs. 

YOUNG>>> I can add: "This is true if the bandwidth of the existing TE LSP
should be kept in tact to re-optimized TE LSP. In a PSC network where
resource guarantee is not required, 0-bandwidth LSP migration can be
considered. This is done by a 3-step technique: (i) perform a
make-before-break along the new path for the first TE LSP with 0-bandwidth;
(ii) perform a make-before-break along the new path for the second TE LSP
with 0-bandwidth; (iii) perform a make-before-break for both TE LSPs with
their actual bandwidth. 

Section 4

 

Then in section 7.7:

YOUNG>>> Thanks. Indeed, this is not a new requirement as you indicated. We
will remove the text. 

Section 5

JP> Two questions:
1) How does the PCC which TE LSP to order. I would have thought of a
mechanism where the PCC signals to the PCE its flexibility to accept
ordering (global request) to which the PCE could respond with or without
ordering ?
2) What if the "global" request can be satisfied only if all reoptimization
have their D flag set (and only a subset of them have the D flag set) ?

YOUNG>>> The first question, I believe, is "How does the PCC know which TE
LSP to order?" If that is what you asked, it is a local intelligence of PCC
which is beyond the scope of this draft. Actually J-L would be a better
person to answer this question. 

Global request is certainly supported by setting D-bit to 1 for each LSP
request (in RP object) in the SVEC list. But if you want to make this
request to be optional, then we need an additional bit to indicate that.
But, if it is only optional, PCE doesn't have to order and will not do.
That's why I believe we need to have "order required" bit which is the
current specification.  

The second question: What if the "global" request can be satisfied only if
all reoptimization have their D flag set (and only a subset of them have the
D flag set) ? --- I can think of two options: (i) PCE sends an error message
to indicate the infeasibility if the request cannot be satisfied; else more
intelligently (ii) PCE would send back the result to PCC with the global
order (only if PCE is able to find a solution; otherwise, an error message
would be sent back to PCC).  We can add some text to describe this scenario
of "what if's." 

Section 6

Others

Thanks.

JP.

Thanks.

JP. 

  _____

---

From: saquib khan <[email-masked]>
Date: Thu, 18 Sep 2008 12:39:14 +0530

Hi,

Can I get the info regarding Global Optimization?Which algorithms are used
for Global Optimization?

****************************************************************************
****************************************************************************
***********

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

****************************************************************************
****************************************************************************
***********

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Friday, September 12, 2008 8:31 PM
To: [email-masked]; [email-masked]; Jean-Louis Le Roux;
[email-masked]
Cc: [email-masked]
Subject: [Pce] FW: Finally: WG Chair review on GCO

------ Forwarded Message

Hi,

Abstract

Introduction

And

Which is good !

Terminology

Section 3

Section 4

Section 5

Section 6

Others

Thanks.

JP.

  _____

---

From: JP Vasseur <[email-masked]>
Date: Thu, 18 Sep 2008 09:17:28 +0200

Hi,

Others may want to comment on their algorithm but we do not standardize
algorithms at the IETF, but protocols.

Thanks.

JP.

On 9/18/08 9:09 AM, "saquib khan" <[email-masked]> wrote:

> Hi,
> Can I get the info regarding Global Optimization?Which algorithms are used for
> Global Optimization?
>  
> 
> ******************************************************************************
> ******************************************************************************
> *******
> which is intended only for the person or entity whose address is listed above.
> Any use of the information contained herein in any way (including, but not
> limited to, total or partial disclosure, reproduction, or dissemination) by
> persons other than the intended recipient's) is prohibited. If you receive
> this e-mail in error, please notify the sender by phone or email immediately
> and delete it!
> ******************************************************************************
> ******************************************************************************
> *******
> 
>