Subject: [Pce] PCE GCO update

From: Young Lee <[email-masked]>
Date: Tue, 24 Jun 2008 12:43:18 -0500

Hi J-P and Adrian, 

Here's the update of PCE GCO draft. As per requested in Philadelphia, this
is ready for the WG chair's review and the last call. Please note section 9
for IANA considerations and new objects/TLV/Flags have been defined. I'd
appreciate your review and look forward to making progress on this work to
the next stage. Thanks. 

I snipped Section 9 below. Thanks.

Regards,

Young

-----------snipped----------------------------------------

9.  IANA Considerations

   IANA maintains a registry of PCEP parameters.  IANA is requested to

   make allocations from the sub-registries as described in the

   following sections.

9.1.  Request Parameter Bit Flags

   As described in Section 5.3, two new bit lfags are defined for

   inclusion in the Flags field of the RP object.  IANA is requested to

   make the following allocations from the "Request Parameter Bit Flags"

   sub-registry.

   Bit      Name    Description                    Reference

   11       D-bit   Report the request order       [This.I-D]

   12       M-bit   Make-before-break              [This.I-D]

9.2.  New PCEP TLV

   As described in Section 5.4, a new PCEP TLV is defined to indicate

   the setup and delete order of LSPs in a GCO.  IANA is requested to

   make the following allocation from the "PCEP TLV Types" sub-registry.

   TLV Type        Meaning                 Reference

   5               Order TLV               [This.I-D]

9.3.  New PCEP Object

   As descried in Section 5.5, a new PCEP object is defined to carry

   global constraints.  IANA is requested to make the following

   allocation from the "PCEP Objects" sub-registry.

   Object  Name                                            Reference

   Class

   24              GLOBAL-CONSTRAINTS                      [This.I-D]

                       Object-Type

                      1: Global Constraints                [This.I-D]

9.4.  New PCEP Error Codes

   As described in Section 5.6, new PCEP error codes are defined for GCO

   errors.  IANA is requested to make allocations from the "PCEP Error

   Types and Values" sub-registry as set out in the following sections.

9.4.1.  New Error-Values for Existing Error-Types

   Error

   Type    Meaning                                            Reference

   5               Policy violation

                           Error-value=5:                     [This.I-D]

                   Global concurrent optimization not allowed

9.4.2.  New Error-Types and Error-Values

   Error

   Type    Meaning                                            Reference

   15              Global Concurrent Optimization Error       [This.I-D]

                   Error-value=1:

                   Insufficient memory                        [This.I-D]

                   Error-value=2:

                   Global concurrent optimization not supported

                                                              [This.I-D]

9.5.  New No-Path Reasons

   IANA is requested to make the following allocations from the "No-Path

   Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV

   in the PCEP NO-PATH object as described in Section 5.7.

   Bit

   Number          Name                         Reference

   6               No GCO migration path found  [This.I-D]

   7               No GCO solution found        [This.I-D]

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Jun 2008 18:56:48 +0100

Hi,

Thanks.

This is now on my list.

Can I do it in time for you to update before Dublin?
Possibly!

A
----- Original Message ----- 
From: "Young Lee" <[email-masked]>
To: "'JP Vasseur'" <[email-masked]>; "'Adrian@OldDog'" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 24, 2008 6:43 PM
Subject: PCE GCO update

---

From: "Filippo Cugini" <[email-masked]>
Date: Wed, 25 Jun 2008 11:24:20 +0200

Hi Young,

1) in case of stateful PCE, is it mandatory to include the full list of RROs in the PCReq message?

2) In section 2, Terminology, GCO is defined to consider only the entire network, while in the rest of the document also network subsets are allowed. 
Is the use of "Global" associated to both the cases of entire network and network subsets or is it just related to the entire network?

Thank you
  Filippo

  ----- Original Message ----- 
  From: Young Lee 
  To: 'JP Vasseur' ; 'Adrian@OldDog' 
  Cc: [email-masked] 
  Sent: Tuesday, June 24, 2008 7:43 PM
  Subject: [Pce] PCE GCO update

  Hi J-P and Adrian, 

  Here's the update of PCE GCO draft. As per requested in Philadelphia, this is ready for the WG chair's review and the last call. Please note section 9 for IANA considerations and new objects/TLV/Flags have been defined. I'd appreciate your review and look forward to making progress on this work to the next stage. Thanks. 

  Regards,

  Young

  -----------snipped----------------------------------------

  9.  IANA Considerations

     following sections.

     sub-registry.

   

  9.2.  New PCEP TLV

   

     5               Order TLV               [This.I-D]

  9.3.  New PCEP Object

   

     Object  Name                                            Reference

     Class

                         Object-Type

   

     Error

     Type    Meaning                                            Reference

     5               Policy violation

   

   

     Error

     Type    Meaning                                            Reference

                     Error-value=1:

                     Error-value=2:

                                                                [This.I-D]

  9.5.  New No-Path Reasons

     Bit

     Number          Name                         Reference

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

---

From: Young Lee <[email-masked]>
Date: Wed, 25 Jun 2008 15:14:01 -0500

Hi Filippo,

Please see inline for my comment. Thanks.

Young

  _____  

From: Filippo Cugini [mailto:[email-masked]] 
Sent: Wednesday, June 25, 2008 4:24 AM
To: Young Lee
Cc: [email-masked]
Subject: Re: [Pce] PCE GCO update

Hi Young,

1) in case of stateful PCE, is it mandatory to include the full list of RROs
in the PCReq message?

Young>> I am not sure of your definition of stateful PCE. If you mean
stateful PCE to be the PCE that keeps the state of the active LSPs at the
PCE, this is beyond the scope of PCEP in IETF. Nonetheless, if this is what
you mean by stateful PCE, I am not sure why you need to send the full list
of RROs in the PCReq message since the PCE keeps such information with
stateful PCE.  When you want to do re-optimization with stateless PCE, you
need to send the full list of RROs of the LSPs to be re-optimized in the PC
Req message. This way PCE needs not maintain the state of LSPs at the PCE
level. 

2) In section 2, Terminology, GCO is defined to consider only the entire
network, while in the rest of the document also network subsets are allowed.

Is the use of "Global" associated to both the cases of entire network and
network subsets or is it just related to the entire network?

Young>> Although GCO considers the entire network in general case, there are
applications of GCO where only a subset of TE LSPs can be re-optimized. This
has a protocol support. I believe you are quoting the statement in the
Introduction, "Alternatively, the application may consider a subset of the
LSPs and/or a subset of the network topology." I may have to delete the last
clause. This can be achieved, but we don't have ways to limit the whole
topology into a subset in the current PCEP for GCO. Are you aware of any
good application for this case? 

Thank you

  Filippo

----- Original Message ----- 

From: Young Lee <mailto:[email-masked]>  

To: 'JP Vasseur' <mailto:[email-masked]>  ; 'Adrian@OldDog' 

Cc: [email-masked] 

Hi J-P and Adrian, 

Regards,

Young

-----------snipped----------------------------------------

9.  IANA Considerations

   following sections.

   sub-registry.

 

9.2.  New PCEP TLV

 

   5               Order TLV               [This.I-D]

9.3.  New PCEP Object

 

   Object  Name                                            Reference

   Class

                       Object-Type

 

   Error

   Type    Meaning                                            Reference

   5               Policy violation

 

 

   Error

   Type    Meaning                                            Reference

                   Error-value=1:

                   Error-value=2:

                                                              [This.I-D]

9.5.  New No-Path Reasons

   Bit

   Number          Name                         Reference

  _____

---

From: "Filippo Cugini" <[email-masked]>
Date: Thu, 26 Jun 2008 12:23:51 +0200

Hi,
please see in-line. 

Young>> I am not sure of your definition of stateful PCE. If you mean stateful PCE to be the PCE that keeps the state of the active LSPs at the PCE, this is beyond the scope of PCEP in IETF. Nonetheless, if this is what you mean by stateful PCE, I am not sure why you need to send the full list of RROs in the PCReq message since the PCE keeps such information with stateful PCE. When you want to do re-optimization with stateless PCE, you need to send the full list of RROs of the LSPs to be re-optimized in the PC Req message. This way PCE needs not maintain the state of LSPs at the PCE level.   

Filippo>> agree that in case of Stateful PCE (yes, the one that keeps the state of active LSPs) there is no need to send the full list, however, in draft-ietf-pce-pcep-12.txt, section 7.4.1 and .2, it is reported that in case of re-optimization, PCReq messages MUST include RROs. 

Young>> Although GCO considers the entire network in general case, there are applications of GCO where only a subset of TE LSPs can be re-optimized. This has a protocol support. I believe you are quoting the statement in the Introduction, "Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology." I may have to delete the last clause. This can be achieved, but we don't have ways to limit the whole topology into a subset in the current PCEP for GCO. Are you aware of any good application for this case? 

Filippo>> Yes, exactly that statement in the introduction which should become consistent with the rest of the document. 

To restrict the computation to a network subset, a possible solution could be the use of IRO object, e.g. specifying the IP prefix or AS number (don't know how to indicate Area ID).

Typo: in section 4, "section 6.1.14 of [RFC4657]" -> "section 5.1.14 of.."

Thanks

  Filippo

---

From: Young Lee <[email-masked]>
Date: Thu, 26 Jun 2008 10:39:48 -0500

Hi Filippo, 

The reason for the RRO inclusion in PCReq in draft-ietf-pce-pcep-12.txt is
because the PCE is stateless. As far as I know, all the PCE drafts and RFCs
assume that PCE is stateless. Thanks for your review on the latest GCO
draft, I will make some corrections to make it consistent. 

Regards,

Young

  _____  

From: Filippo Cugini [mailto:[email-masked]] 
Sent: Thursday, June 26, 2008 5:24 AM
To: Young Lee
Cc: [email-masked]
Subject: Re: [Pce] PCE GCO update

Hi,

please see in-line. 

Filippo>> agree that in case of Stateful PCE (yes, the one that keeps the
state of active LSPs) there is no need to send the full list, however, in
draft-ietf-pce-pcep-12.txt, section 7.4.1 and .2, it is reported that in
case of re-optimization, PCReq messages MUST include RROs. 

Filippo>> Yes, exactly that statement in the introduction which should
become consistent with the rest of the document. 

To restrict the computation to a network subset, a possible solution could
be the use of IRO object, e.g. specifying theIP prefix or AS number (don't
know how to indicate Area ID).

Thanks

Filippo

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 29 Jun 2008 23:59:27 +0100

Hi Young,

Here is my review as promised...

Cheers,
Adrian
====

idnits (http://tools.ietf.org/tools/idnits/) gives the following errors and 
warnings...

== Missing Reference: 'RFC5058' is mentioned on line 186, but not defined

  == Missing Reference: 'RFC5059' is mentioned on line 186, but not defined

  == Missing Reference: 'ISIS PCED' is mentioned on line 858, but not 
defined

  == Missing Reference: 'OSPF PCED' is mentioned on line 858, but not 
defined

  == Unused Reference: 'ISIS-PCED' is defined on line 1009, but no explicit
     reference was found in the text

  == Unused Reference: 'OSPF-PCED' is defined on line 1018, but no explicit
     reference was found in the text

  == Unused Reference: 'PCE-MLN' is defined on line 1023, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-09) exists of
     draft-ietf-pce-brpc-05

  -- Possible downref: Normative reference to a draft: ref. 'PCE-OF'  (No
     intended status found in state file of draft-leroux-pce-of)

  == Outdated reference: A later version (-05) exists of
     draft-ietf-pce-pcep-xro-00

  ** Downref: Normative reference to an Informational RFC: RFC 4655

  ** Downref: Normative reference to an Informational RFC: RFC 4657

  ** Downref: Normative reference to an Informational RFC: RFC 4674

  == Outdated reference: draft-ietf-pce-disco-proto-isis has been published
     as RFC 5089

  == Outdated reference: draft-ietf-pce-disco-proto-ospf has been published
     as RFC 5088

====
Philosophy...
Please add to the Abstract *and* Introduction some comment like...

   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.

I hope that this sort of text is not in oposition to your intentions. I 
believe it will go a long way toward calming some of the concerns about this 
document. the distinction I am trying to draw is in the applicability of 
global optimization and global reoptimization.

====
Abstract
   The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.

Suggest you add...
   In this context a PCC may be a Label Switching Router (LSR),
   an Network management Station (NMS), or another PCE.

====
Section 1 para 1
s/(LSP)/(LSPs)/
====
Section 1
I would suggest reversing the order of paragraphs 5 and 6.
As currently presented, it appears that the reoptimization issue is a larger 
usage than the provisioning/planning use.
However, as per my suggested text for the Abstract and Introduction, the 
provisioning/planning use can be applied in any network, while 
reoptimization may not be appropriate in some networks.

You might also re-order sections 3.2 and 3.3 for the same reasons.
====
Philosophy...
Is "Global" causing problems in discussions? The word implies that *all* 
LSPs must be concurrently optimized. As in plain from this I-D, you allow 
global, but you also allow a subset or batch dropping down to just two LSPs 
as the extreme minimum case.
I know that GCO rolls off the tongue nicely, but is it too late to change 
this to just "concurrent optimization"?
====
Section 1 final paragraph
s/BRPC/Backward Recursive Path Computation (BRPC)/
====
Section 3.1
s/protocol, this/protocol; this/
====
Section 3.1
This is the first section to mention "algorithms".
I suggest you add something like.
   Various algorithms and computation techniques have
   been proposed to perform this function. Specification
   of such algorithms or techniques is outside the scope of
   this document.
====
Section 3.2
You use the term "sequential re-optimization".
Could you introduce the term or explain it.
====
Section 3.2
s/with giving no/without giving any/
====
Section 3.2
You have
   With regards to applicability of GCO in the event of catastrophic
   failures, there may be a real benefit in computing the paths of the
   LSPs as a set rather than computing new paths from the head-end LSRs
   in a distributed manner.  It is to be noted, however, that a
   centralized system will typically suffer from a slower response time
   than a distributed system.
You may want to give some comment on the cost/benefit of this.
====
Section 3.2.1
It might be good to reference draft-ietf-pce-inter-layer-frwk as this is a 
PCE working group draft with a wider discussion of VNT.
====
Section 3.2.2 first paragraph
I understand the point you are making, but it could be more clearly made.
You have:
   However, the PCE may be able to determine an order of LSP
   rerouting actions so that make-before-break can be performed within
   the limited resources.
What about...
   However, a PCE may be able to determine a sequence of make-before-
   break replacement of individual LSPs or small sets of LSPs so that
   the full set of LSPs can be migrated without any disruption.
====
Section 3.3
OLD
   Greenfield optimization is a special case of GCO application when
   there is no LSP setup.  Once the LSPs are setup, it is not a
   greenfield.  The need for greenfield arises when network planner will
   want to make use of computation servers to plan the LSPs that will be
   provisioned in the network.
NEW
   Greenfield optimization is a special case of GCO application when
   there are no LSPs already set up in the network. The need for
   greenfield optimization arises when network planner wants to make use
   of a computation server to plan the LSPs that will be provisioned in
   the network.
====
Section 3.3
s/green-field/greenfield/
s/a set of TE LSPs need/a set of TE LSPs needs/
====
Section 3.3
OLD
   Under this scenario, concurrent computation ability is highly
   desirable, or required, to utilize network resources in an optimal
   manner and avoid blocking risks.
NEW
   In this scenario, the ability to perform concurrent computation is
   desirable, or required, to utilize network resources in an optimal
   manner and avoid blocking.
====
Section 3.3.1
s/green-field/greenfield/
====
Section 3.3.1
OLD
   For example,
   MPLS-TE network can be established based on layer 3 specific traffic
   demand, network topology, and network resources.
NEW
   For example,
   an MPLS-TE network can be planned based on layer 3 traffic demands,
   the network topology, and available network resources.
====
Section 3.3.2
Add a reference to draft-ietf-pce-inter-layer-frwk
====
Section 4
Please reconcile the two objective functions you have defined with the three 
(numbers 4, 5, and 6) defined in draft-ietf-pce-of.
A forward reference to section 5.1 might help.
====
Backward compatibility
I would like to see some discussion of what happens if a PCE doesn't support 
GCO. How will it treat a request and will it be graceful?
Note that error 15/2 doesn't do it because a legacy PCE does not know to 
send this error.
====
Section 4
s/When the PCE could not find a feasible/When the PCE cannot find a 
feasible/
====
Section 4
         It might also be desirable to
         have the PCE indicate whether ordering is in fact required or
         not.
Is that "might" actually "MAY"?
====
Section 4
s/The request message must allow/The request message MUST allow/
====
Section 5
Please capitalise the section heading
====
Section 5
I'm a little confused as to which is the normative document for defining the 
placement of <OF> in the <SVEC-List>.
This document of draft-ietf-pce-of?
====
Section 5 final paragraph
s/should/SHOULD/
s/RRO object/Reported Route Object (RRO)/
====
Section 5.1 final paragraph
s/i.)/i./
====
Section 5.3
Please capitalise the section heading
====
Section 5.4
   The delete order should not be equal to the setup order.
Is that "SHOULD"?
====
Section 5.4
s/To illustrate,/To illustrate this,/
====
Section 5.4
    two established requests
Hmmm. LSPs can be established, not requests.
====
Section 5.5
Please be consitent between
   GLOBAL CONSTRAINTS Object
   Global Constraints Object
   GLOBAL CONSTRAINT Object
====
Section 5.5
I *really* don't like the full 32 bits of Reserved field. This is highly 
unusual.
At the very least you must justify it. By preference you should remove it.
====
Section 5.6
s/is not capable of the request/is not capable of processing the request/
====
Section 5.6
For a couple of errors, you have...
   The corresponding global concurrent path
   optimization request MUST be cancelled.
This is an error from the PCE, right? So what does "MUST be cancelled" mean?
Do you mean:
   The PCE stops processing the request.
====
Sections 6.4 and 6.6
s/does not/do not/
====

----- Original Message ----- 
From: "Young Lee" <[email-masked]>
To: "'JP Vasseur'" <[email-masked]>; "'Adrian@OldDog'" 
<[email-masked]>
Cc: <[email-masked]>