Dear Meral, all, On Mon, October 18, 2010 8:37 pm, Meral Shirazipour wrote:
> I think the extensions proposed by this draft are extremely important > and necessary for a real scale deployment of the PCE architecture. Thank you for your supportive words, and for your insightful comments, they clearly pin-point room for improvements, and open issues. Please see inline. > (1) > The idea of resource pre-reservation (reservation) by the PCE is very > useful especially when multiple sequential PCEs are in play (i.e. not > one PCE can provide the end-to-end path). Given the distributed nature > of the problem, determining the correct reservation time is not trivial. Indeed. One of the first use cases was the intra-domain case and the compute-setup-update_ted cycle, but the multi-domain and collaborative PCE setting (sequential or hierarchical) should definitely be considered carefully: on the one hand, we believe it may be a good idea to reserve resources in an upstream PCE to avoid contention or another request "stealing" the resources while the PCE is e.g. waiting for a downstream response and similar examples. However, it is also true that in approaches such as BRPC, the number of potential path segments to be concatenated may grow significantly and reserving for all of them may cause excessive reservations. In short, yes, not only the reservation time is critical but also the fact that reservations for the VSPT paths (except the one that is part of the e2e path) should be avoided. > The necessary PCEP extensions might slightly vary depending on the > method used to determine and convey the reservation times. Therefore it > is crucial to determine the method(s) before finalizing the PCEP > extensions. Yes, although for now the actual determination of the reservation time is still open. As a main guideline, it should be of the order of the setup delay or, more precisely of the compute-setup-update. This is mainly driven by the original use case. > > > (2) > Section 3.1: > "The RESERVATION object is optional in a PCReq message. Multiple > instances of the object MUST NOT be used on a single PCReq message > and if a PCE finds multiple instances of the object it MUST use the > first one and discard the rest (Editors note: alternatively, it could > send a PCErr). The RESERVATION object may appear either at an > individual request level or within a SVEC. The latter means that the > RESERVATION object applies to all requests involved in the SVEC > object. " > > What is the reason to not allow a RESERVATION object "per path" request? > Isn't it too limiting to say that all path requests within the SVEC > will need to apply the same RESERVATION object? Thanks for catching this up. In fact, I'm afraid that the current text is not correct. it should say : "the RESERVATION object is optional in a request [within a PCReq message] (...) MUST NOT be used on a single request." The intended behavior is to allow different reservations per request and per path (i.e. when a response has more than one path, all reservations are distinct): the pcc requests a reservation within the request, and the PCE assigns a reservation for every single path (the RESERVATION_CONF response is an attribute of the path). In other words, typical usage would be: N:1 requests within a PCReq message with (up to) N reservation requests (RESERVATIONS) and, if a response contains M paths, there are (up to) M actual reservations (_CONFs) with distinct reservation identifiers. The exception for this is when the RESERVATION object appears at the SVEC tuple level: in that case it is assumed that the same reservation parameters apply to all requests referred to in the SVEC tuple. This does not preclude that the PCE assigns different reservations (in fact different reservation ids) to individual paths (thus a PCC may cancel individual reservations bound to some of the paths within a request). Note that you can have a SVEC yet individual requests have different RESERVATION objects. It has been left for next version the possibility, for a PCC, to specify whether it requests the same reservation for all the paths or individual reservations for each path. A flag could be added to mean "all paths for a single request/response should share the same reservation so, if it is cancelled, all they are." > (3) > Section 3.5: > "A PCE MAY apply reservations as a means of internal policy and/or > operation." > > I would ad an example for this, as it is significant/high impact > operational practice: an example could be when the rate of incoming > path requests reaches a given threshold value, the PCE may decide to > apply reservations. Good point. We will try to update the draft with this (more generally, referring to the selection of the timer and how this impacts PCE behavior and the relationship with what the client actually requests). Currently, it is pcc-driven + PCE policy-checked. > (4) > Section 3.5, The reservation timer: > "Timer is the value in ms of the time that the resources are blocked" > > Is this a relative time? Would is be better to convey this information > as an absolute time? > In any case, what should the format be? We have considered a relative amount of milliseconds, encoded as a uint32_t, indicating the amount of time the reservation is to be applied (thus resources excluded) right after the computation. However, in multi-domain path computations, it may be a good idea to also consider the possibility to reserve resources at the point when a request is sent/forwarded to a downstream / parent PCE, not only when the computation is finished. We have not considered (but I think we should!) absolute timestamps. Having a common deadline for all resources and all involved PCEs regardless of the latency until they get the request seems a valid option. I guess in this case it should be encoded in UTC or GMT, using timestamps (ISO format, or some equivalent?) > > (5) > Section 4, Page 13, > "Send the Responses (successful or not) using PCRep message(s) and, > where appropriate, indicate the level of reservation and associated > period. " > > Same question as in 4) : how to interpret this period? (6) For now, in the lines of "I'll be reserving the resources for this amount of ms, right after I finished the computation" (i.e. relative values + some unknown offset encompassing the "latency" from the PCE to the PCC). The same comment applies regardless absolute times. I think this may be a valid addition for -01 > Section 4: > "Specify what level of reservation to apply after the request." > > What is level here? Granularity or path level vs SVEC level? Level here means either "basic" resource (wavelength, bandwidth, Timeslot, Tributary) with regard to any other more "aggressive" reservation excluding link/node/srlg. > > (7) Section 5, use cases. We should discuss various path computation > methods e.g. BRPC (RFC5441), draft-king-pce-hierarchy-fwk-05, etc. > This discussion may bring new insights as what is the best method for > determining the reservation time: see comment (1) above Completely agreed. I am not (yet?) confident enough to comment on this but definitely a work item. > (8) > 5.2 and 5.3 , I don't quite see why they are separated. > In 5.2, if a path is returned and a domain sequence is selected, what > guarantees that once we try to compute a path (5.3) the resources will > be available? To avoid confusion I will discuss these in one section > and point out that reservation requests should be applied carefully > when interrogating multiple PCEs in multiple domains? The idea is that if, for some reason, domain sequence selection is decoupled from path computation (e.g. a parent PCE just returns a list of domains so the ingress PCE is able to apply BRPC), reservation should be applied during BRPC. The wording should be improved though. This does not solve the issue of excessive reservations, as mentioned above. > > > (9) > Is it a possibility to have request priorities associated with the > reservations? Will this be policy based applied per PCE? I am not sure. I guess that managing priorities and (eventually) preemption seems a logical extension to the proposed mechanism, but we would need to think about it (do you have a use case in mind?) but right now we simply considered having an exclusive flag with binary state (reserved/not reserved) for a given resource. The original scope is to allow some context state, and although priorities would extend this by tagging a resource with a current priority (plus some extra book-keeping), I tend to think that leaving the room for over-engineering resource reservation protocol within PCEP would be out of scope, raising more questions than it solves :-) I hope this clarifies at least some of your questions. We will discuss your points to improve the idea. Thanks for reading Ramon, > > > Oscar González de Dios <[email protected]> a écrit : > >> Dear PCErs >> >> We have submitted a new draft called "PCEP Extensions >> for Temporary Reservation of Computed Path Resources and Support for >> Limited Context State in PCE". You can find it in >> http://tools.ietf.org/id/draft-gonzalezdedios-pce-resv-res-context-state-00.txt. >> >> As it was pointed out in the PCE Architecture RFC, a limited form of >> statefulness is useful to improve PCE functionality in situations in >> which the local TED might not be up to date, or in the case of >> concurrent requests where most of the LSPs are computed >> before the end of the set-up of the LSPs when the TED is updated. >> The PCE can retain some context from the resources assigned to Path >> Requests during a certain period of time, so that it avoids >> suggesting the use of the same resources for subsequent TE LSPs. >> >> The draft we have submitted proposes an extension to the PCEP >> protocol to allow the PCC to request the PCE to block or reserve the >> resources computed in a path request of a TE LSP for subsequent >> requests for a certain time. >> >> Please consider taking a look at the draft and send us >> your opinion and comments, >> >> Best Regards, >> >> Óscar >> >> > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > -- _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
