Re: [Pce] PCE GCO update

[Young Lee <[e-mail]>]

Hi Adrian,

Thanks for your thorough review. Would this constitute as the WG chair's
review? I will try to make corrections and revisions per your comments where
possible. I believe I will have enough time to revise before the deadline. 

Best 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

====
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" <[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