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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Sunday, June 29, 2008 5:59 PM > To: Young Lee; 'JP Vasseur' > Cc: [email protected] > 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" <[EMAIL PROTECTED]> > To: "'JP Vasseur'" <[EMAIL PROTECTED]>; "'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]> > Cc: <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
