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. > > 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. > > > > 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) ? > > > ³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
