Hi J-P,
Thanks a lot for spending time for your review. We can accommodate all your comments in revision. We will shortly get back with you and Adrian. Please see in-line for my response. Best Regards, Young _____ From: JP Vasseur [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2008 10:01 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jean-Louis Le Roux; [EMAIL PROTECTED] Cc: [email protected] Subject: FW: [Pce] 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. YOUNG>> Thank you. Abstract S/invisaged/envisaged (appears in several places) S/ gloablly/globally YOUNG>> We will correct them. 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". YOUNG>> We will add. * 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" YOUNG>> Thanks! It will further clarify the application of GCO. We will add this. * "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 ? YOUNG>> You're right. It should've read: "As the PCE has the potential to provide solutions in all path computation solutions in a variety of environments, PCE is a candidate for performing path computations in support of GCO." YOUNG>> But it may not add much to the draft; I will delete this sentence. 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." YOUNG>> That's fine with me. Thanks. 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. YOUNG>> You're right. In some optical networks, however, it could stay longer than IP/MPLS networks. So we included this operation. * 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. YOUNG>> I will modify something like: "Distributed jittering is a technique that could prevent race condition (i.e., competing for the same resource from different head-end LSRs) with a distributed computation. GCO provides an alternative way that could prevent race condition. * "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? YOUNG>> Our assumption was to keep the b/w of the existing TE LSP in tact. I don't understand how the TE LSPs could be zeroed before reoptimization. In optical networks, there is no such thing as "zero" b/w LSP. In IP/MPLS networks, I understand there are 0 b/w TE LSP, but when you zero the b/w of an existing LSP and avoid inter-lock, how can you assure the re-optimized TE LSP with the original committed B/W? Perhaps, I am missing something here. 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? YOUNG>> It can be done by your suggested way. Ning So (Verizon) specified this requirement for a good reason for his operation. I think it is a matter of preference. I believe Overbooking Factor allows an easy way to request multiple TE-LSP's in one shot, instead of going through additional calculation individually. Do you want to ask Ning about this? * "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. YOUNG>> This is in the context of GCO. When there are multiple TE-LSPs to be re-optimized, can PCEP support multiple requests? I thought PCEP can do one at a time. Please correct me if I am wrong on this. If we can this with PCEP, I can remove this text. Section 5 * S/ Reported Route Objects (RROs)/Record Route Object YOUNG>> Thanks. We will correct. * "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. YOUNG>> The PCE would apply "ordering" only to the TE-LSP's whose D bit is set in the RP object. The rest of the TE-LSPs in the SVEC wouldn't be ordered. If PCC=NMS, this does not apply. "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 ? YOUNG>> It should be "MUST" - will change. 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 ? YOUNG>> Yes, we need to define a new flag (value = 9, if not taken yet) in the current PCE-CAP-FLAGs. Others In several places we use TE LSPs in other places LSPs. Can you make sure to systematically use "TE LSPs" ? YOUNG>> Will change globally. 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
