Re: [Pce] PCE GCO update

[Young Lee <[e-mail]>]

Hi Adrian,

See in-line for my comment. I met almost all of your comments in the updated
version (04) except the following:

- on the name of GCO: I'd rather want to keep the current name --it's a bit
too late to change now. Also "global" is definitely a good part of what this
draft is about. I hope people would read the definition of GCO in the
glossary which makes the definition very clear.

- on error 15/2 --- I think you are right. If a legacy PCE does not
understand the lingo "GCO" then it cannot properly generate an appropriate
error message back to PCC. However, we have defined a new error-value (5) in
the current error-type (5) to handle policy error associated with GCO in the
PCEP. The current texts read: 

   To indicate an error associated with policy violation, a new error
   value "global concurrent optimization not allowed" should be added to
   an existing error code for policy violation (Error-Type=5) as defined
   in [PCEP].

   Error-Type=5; Error-Value=5: if a PCE receives a global concurrent
   path optimization request which is not compliant with administrative
   privileges (i.e., the PCE policy does not support global concurrent
   optimization), the PCE sends a PCErr message with a PCEP-ERROR Object
   (Error-Type=5) and an Error-Value (Error-Value=5).  The PCE stops the
   processing the request.  The corresponding global concurrent path
   computation MUST be cancelled at the PCC.

Do you think this can be used for indicating "GCO incapable" error? 

I haven't officially published 04 version yet. But it is enclosed here for
JP's review. 

Regards,
Young

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Sunday, June 29, 2008 5:59 PM
To: Young Lee; 'JP Vasseur'
Cc: [e-mail]
Subject: Re: PCE GCO update

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

YOUNG>> I corrected all of the above. 

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

YOUNG>> I inserted your suggested text both in the intro and abstract. 

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

YOUNG>> I also inserted this sentence in the abstract.
====
Section 1 para 1
s/(LSP)/(LSPs)/

YOUNG>> Yes
====
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.

YOUNG>> Yes
====
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"?

YOUNG>> I kept the "global". I explained the reason why I kept it in the
above. 
====
Section 1 final paragraph
s/BRPC/Backward Recursive Path Computation (BRPC)/

YOUNG>> Yes. 
====
Section 3.1
s/protocol, this/protocol; this/

YOUNG>> Yes. 
====
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.

YOUNG>> Yes. 
====
Section 3.2
You use the term "sequential re-optimization".
Could you introduce the term or explain it.

YOUNG>> I put the following: Sequential re-optimization refers to a
   path computation method in which to compute the re-optimized path of
   one LSP at a time without giving any consideration to the other LSPs
   that need to be re-optimized in the network.  
====
Section 3.2
s/with giving no/without giving any/

YOUNG>> Yes. 
====
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.

YOUNG>> New text reads: 
   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.  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.  However, a
   centralized system will typically suffer from a slower response time
   than a distributed system.
====
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.

YOUNG>> Yes. 
====
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.

YOUNG>> Yes. 
====
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.

YOUNG>> Yes. 
====
Section 3.3
s/green-field/greenfield/
s/a set of TE LSPs need/a set of TE LSPs needs/

YOUNG>> Yes. 
====
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.

YOUNG>> Yes. 
====
Section 3.3.1
s/green-field/greenfield/

YOUNG>> Yes. 
====
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.

YOUNG>> Yes. 
====
Section 3.3.2
Add a reference to draft-ietf-pce-inter-layer-frwk

YOUNG>> Yes. 
====
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.

YOUNG>> New Texts read: 
A Global Objective Function (GOF) field in which to specify the
      global objective function.  The global objective function is the
      overarching objective function to which all individual path
      computation requests are subjected in order to find a globally
      optimal solution.  Note that this requirement is covered by
      "synchronized objective functions" in section 5.1.7 [RFC4657] and
      that [PCE-OF] defined three global objective functions as follows.
      A list of available global objective functions SHOULD include the
      following objective functions at the minimum and SHOULD be
      expandable for future addition:

      *  Minimize aggregate Bandwidth Consumption (MBC)

      *  Minimize the load of the Most Loaded Link (MLL)

      *  Minimize Cumulative Cost of a set of paths (MCC)
====
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.

YOUNG>> See the beginning of the mail. 

====
Section 4
s/When the PCE could not find a feasible/When the PCE cannot find a 
feasible/

YOUNG>> Yes.
====
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"?

YOUNG>> Yes. 
====
Section 4
s/The request message must allow/The request message MUST allow/

YOUNG>> Yes.
====
Section 5
Please capitalise the section heading

YOUNG>> Yes. 
====
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?

YOUNG>> New Texts read: The placement of the OF object
   (in which the global objective function is specified) in the SVEC-
   list is defined in [PCE-OF].  Details of this change will be
   discussed in the following sections.
====
Section 5 final paragraph
s/should/SHOULD/
s/RRO object/Reported Route Object (RRO)/

YOUNG>> Yes.
====
Section 5.1 final paragraph
s/i.)/i./

YOUNG>> Yes.
====
Section 5.3
Please capitalise the section heading

YOUNG>> Yes. 
====
Section 5.4
   The delete order should not be equal to the setup order.
Is that "SHOULD"?

YOUNG>> Yes. 
====
Section 5.4
s/To illustrate,/To illustrate this,/

YOUNG>> Yes. 
====
Section 5.4
    two established requests
Hmmm. LSPs can be established, not requests.

YOUNG>> Yes.
====
Section 5.5
Please be consitent between
   GLOBAL CONSTRAINTS Object
   Global Constraints Object
   GLOBAL CONSTRAINT Object

YOUNG>> Changed all to GLOBAL CONSTRAINTS 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.

YOUNG>> removed it. 
====
Section 5.6
s/is not capable of the request/is not capable of processing the request/

YOUNG>> Yes.
====
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.

YOUNG>> New Texts read: The PCE stops processing the request.
   The corresponding global concurrent path optimization request MUST be
   cancelled at the PCC.
====
Sections 6.4 and 6.6
s/does not/do not/

YOUNG>> Yes. 
====

----- Original Message ----- 
From: "Young Lee" <[e-mail]>
To: "'JP Vasseur'" <[e-mail]>; "'Adrian@OldDog'" 
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, June 24, 2008 6:43 PM
Subject: 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.
>
>
>
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/pce