Re: [Pce] PCE GCO update

[JP Vasseur <[e-mail]>]

Hi Young,

Gentle reminder ;-) Yes I owe you my review. I'll try to make it asap, this
might be after the cut-off date though ...

Thanks.

JP.


On 7/7/08 4:45 PM, "Young Lee" <[e-mail]> wrote:

> 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