Hi, Can I get the info regarding Global Optimization?Which algorithms are used for Global Optimization?
**************************************************************************** **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** **************************************************************************** *********** _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JP Vasseur Sent: Friday, September 12, 2008 8:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jean-Louis Le Roux; [EMAIL PROTECTED] Cc: [email protected] Subject: [Pce] FW: Finally: WG Chair review on GCO ------ Forwarded Message From: JP Vasseur <[EMAIL PROTECTED]> Date: Fri, 12 Sep 2008 16:58:40 +0200 To: <[email protected]> Subject: [Pce] Finally: WG Chair review on GCO 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 ------ End of Forwarded Message
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
