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
