Hi J-P,
Thanks for your prompt reply. I think we are merging. Please see in-line for my response to your comments. Hi J-L, You may be the right person who can elaborate more on J-P's question on D-bit. I'd appreciate if you can provide your comments for the D-bit question below. Best Regards, Young _____ From: JP Vasseur [mailto:[EMAIL PROTECTED] Sent: Monday, September 15, 2008 1:11 AM To: Young Lee; [EMAIL PROTECTED]; 'Jean-Louis Le Roux'; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Pce] Finally: WG Chair review on GCO Hi Young, Thanks for accommodating the comments/suggestions. Just a few comments in line, On 9/13/08 12:09 AM, "Young Lee" <[EMAIL PROTECTED]> wrote: 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. JP> I was referring to the packet TE LSP case where you could use a 3-step technique to reoptimize to TE LSPs that "block" each other for example. Is this case, you perform a make=before-break along the new path for the first TE LSPs but with 0-bandwidth, then you do a make-before-break along the new path for the second TE LSP again with 0-bandwidth but finally to do a make-before-break for both TE LSPs (no change in the path) but with their actual bandwidth. Of course, this only applies to packet TE LSPs. YOUNG>>> I can add: "This is true if the bandwidth of the existing TE LSP should be kept in tact to re-optimized TE LSP. In a PSC network where resource guarantee is not required, 0-bandwidth LSP migration can be considered. This is done by a 3-step technique: (i) perform a make-before-break along the new path for the first TE LSP with 0-bandwidth; (ii) perform a make-before-break along the new path for the second TE LSP with 0-bandwidth; (iii) perform a make-before-break for both TE LSPs with their actual bandwidth. 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? JP> This is fine as is. I was just wondering whether you looked at this alternative but since it does not overload the protocol too much, leave it unchanged. * "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. JP> You can do this with the current spec. R (Reoptimization - 1 bit): when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when the R bit is set, an RRO (see Section 7.10) MUST be included in the PCReq message to show the path of the existing TE LSP. Also, for all TE LSPs except 0-bandwidth LSPs, then the R bit is set, the existing bandwidth of the TE LSP to be reoptimized MUST be supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH object is in addition to the instance of that object used to describe the desired bandwidth of the reoptimized LSP. For 0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the characteristics of the existing TE LSP are optional. Then in section 7.7: In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type values are defined that refer to the requested bandwidth and the bandwidth of the TE LSP for which a reoptimization is being performed. YOUNG>>> Thanks. Indeed, this is not a new requirement as you indicated. We will remove the 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. JP> Two questions: 1) How does the PCC which TE LSP to order. I would have thought of a mechanism where the PCC signals to the PCE its flexibility to accept ordering (global request) to which the PCE could respond with or without ordering ? 2) What if the "global" request can be satisfied only if all reoptimization have their D flag set (and only a subset of them have the D flag set) ? YOUNG>>> The first question, I believe, is "How does the PCC know which TE LSP to order?" If that is what you asked, it is a local intelligence of PCC which is beyond the scope of this draft. Actually J-L would be a better person to answer this question. Global request is certainly supported by setting D-bit to 1 for each LSP request (in RP object) in the SVEC list. But if you want to make this request to be optional, then we need an additional bit to indicate that. But, if it is only optional, PCE doesn't have to order and will not do. That's why I believe we need to have "order required" bit which is the current specification. The second question: What if the "global" request can be satisfied only if all reoptimization have their D flag set (and only a subset of them have the D flag set) ? --- I can think of two options: (i) PCE sends an error message to indicate the infeasibility if the request cannot be satisfied; else more intelligently (ii) PCE would send back the result to PCC with the global order (only if PCE is able to find a solution; otherwise, an error message would be sent back to PCC). We can add some text to describe this scenario of "what if's." "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. 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
