Hi, Others may want to comment on their algorithm but we do not standardize algorithms at the IETF, but protocols.
Thanks. JP. On 9/18/08 9:09 AM, "saquib khan" <[EMAIL PROTECTED]> wrote: > 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
