Hi,
Here is my WG chair review, Adrian has done his part.
First I must say that I was first inclined to propose to follow the
experimental track. That being said, you managed to clearly explain that GCO
was applicable to a subset of cases and the PCC would be an NMS as opposed
to a set of LSRs, which were my main concerns. So I think that we are fine
following the standard track.
Abstract
S/invisaged/envisaged (appears in several places)
S/ gloablly/globally
Introduction
* ³ As new LSPs are added or removed from the network over time, the
global network resources become fragmented and the existing placement
of LSPs within network no longer provides optimal use of the
available capacity. A global concurrent path computation is able to
simultaneously consider the entire topology of the network and the
complete set of existing LSPs and their respective constraints, and
look to re-optimize the entire network to satisfy all constraints for
all LSPs. Alternatively, the application may consider a subset of
the LSPs and/or a subset of the network topology.
³
JP> I would suggest to also add: ³Note that other preemption can also help
reducing the fragmentation issues².
* JP> I remembers having made comments to warn the reader on the
applicability of GCO to environments with a high degree od dynamicity and
smal LSP bw/link speed ratios. TO that end, you added:
³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.²
And
³ However, the key point remains: computing the reoptimized
path of one LSP at a time without giving any consideration to the
other LSPs in the network could result in sub-optimal use of network
resources. This may be far more visible in an optical network with a
low ratio of potential LSPs per link, and far less visible in packet
networks with micro-flow LSPs.²
Which is good !
JP> I would still want to suggest some NORMATIVE language here, thus
replacing ³it is not envisaged² by ³it is NOT RECOMMEMDED² and ³Further,
applying global concurrent reoptimization in a network with a high rate of
change of LSPs (churn) is not advised² by ³Further, applying global
concurrent reoptimization in a network with a high rate of change of LSPs
(churn) is NOT RECOMMENDED³
* ³As the PCE has the potential to provide solutions in all path
computation solutions in a variety of environments and is a candidate
for performing path computations in support of GCO.²
JP> Word missing in this sentence above ?
Terminology
* ³ GCO: Global Concurrent Optimization: A concurrent path computation
application where a set of TE paths are computed concurrently in
order to efficiently utilize network resources.²
JP> May I suggest ³ GCO: Global Concurrent Optimization: A concurrent path
computation
application where a set of TE paths are computed concurrently in
order to optimize network resources.²
Section 3
* Greenfield operation: well, it never stays a greenfield for a long time
... As failure arise, TE LSPs get rerouted and it is no longer a greenfield.
* You wrote ³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. ³
JP> I would soften this since such issue could easily be solved with
distributed jittering.
* ³In other words, it may prove to be impossible
to perform a direct migration from the old LSPs to the new optimal
LSPs without disrupting traffic because there are insufficient
network resources to support both sets of LSPs when make-before-break
is used. ³
JP> This is true if you keep the bw of existing TE LSP unchanged but you
could certainly zeroed the TE LSPs before reoptimization to avoid
inter-lock. Could you just briefly mention it?
Section 4
³* Overbooking Factor -- The overbooking factor allows the
reserved bandwidth to be overbooked on each link beyond its
physical capacity limit.²
JP> Why isn¹t it sufficient for the PCC to provide the bandwidth after
having dividing the bw by the over-booking factor?
* ³As stated in RFC 4657, the request for a reoptimization MUST
support the inclusion of the set of previously computed paths
along with their bandwidth. This is to avoid double bandwidth
accounting and also this allows running an algorithm that
minimizes perturbation and that can compute a migration path
(LSP setup/removal orders). This is particularly required for
stateless PCEs.²
JP> Note that this is already supported by PCEP.
Section 5
* S/ Reported Route Objects (RROs)/Record Route Object
* ³D bit (orDer - 1 bit): when set, in a PCReq message, the requesting
PCC requires the PCE to specify in the PCRep message the order in
which this particular path request is to be provisioned relative to
other requests.²
JP> What if the PCC sets this bit for a subset of the request in the SVEC
list ? (just mention it). Note also that ordering is not meaningful if the
PCC=NMS, not in a distributed system.
³The Order TLV SHOULD be included in the RP object in the PCRep
message if the D bit is set in the RP object in the PCReq message.²
JP> Why a SHOULD and not a MUST ?
Section 6
* 6.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used
to advertise global concurrent path computation capabilities to PCCs.
JP> How ? New flags in PCE-CAP-FLAGS Sub-TLV ?
Others
In several places we use TE LSPs in other places LSPs. Can you make sure to
systematically use ³TE LSPs² ?
Thanks.
JP.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
