Hi,
Thank you Ramon for the detailed explanations. Please see inline.
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.
By intra-domain do you mean single PCE scenarios? Because I believe in
the same domain (AS or Area) we can deploy multiple PCEs, sharing or
not the same TED. I believe that the reservation extensions proposed by
this draft are valid for both single and multiple PCE scenarios (with
probably more benefits in the multiple PCE case).
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.
I don't think that reservation should be avoided in all BRPC cases.
Depending on the case at hand, it may be more beneficial to reserve
resources (along the VSPT) with the 'right' reservation times to avoid
blockage at deployment time. One such example is when the PCEs are
triggered at a higher rate than usual and where not reserving causes
high chances of blockage at LSP signaling time.
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.
This is good and unfortunately determining the right reservation times
is not a trivial question. Looking forward to discuss it further with
you and the co-authors:)
(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 new text makes perfect sense, thanks.
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.
I completely agree.
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."
At first glance I would recommend assigning the same value as the
Request-ID-number to the reservation ID. This way any path request
inside a PCReq that requires a reservation will also have its own
reservation ID irrespective of being part of a SVEC or not. This may
also make it easier to match the reservation to the right LSP at
signaling time?
(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.
Sounds good.
(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.
That is why I also think that it would be worth using absolute timestamps.
We have not considered (but I think we should!) absolute timestamps.
I agree.
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?)
Yes, NTP or (ISO 8601 (?)) timestamps Another comment about Section
3.3) Cancelling a Reservation:
Would it make sense to say this: A PCC that triggers more than once PCE
with reservation requests SHOULD explicitly cancel the reservations on
all other (remaining) PCEs as soon as it decides on using the path
returned by one of them. That would avoid counting only on the
reservations expiry times, and therefore avoid holding in reserve mode
resources that the PCC does not plan to use?
(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
agree, same comment as above on absolute timestamps.
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.
My confusion came from Section 3.1 which uses the word "level" as :
"The RESERVATION object may appear either at an individual request
level or within a SVEC. "
(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.
The WG?s help and feedbacks are going to be needed..
(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.
Ok.
(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 raised this question by looking at the whole thing from a path
computation algorithm perspective :) Also this addition may be be
natural ...given the optional 3 bit PRI bits specified in the RP object
(section 7.4.1 in RFC5440).
I hope this clarifies at least some of your questions. We will discuss
your points to improve the idea.
Thanks for reading
Thank you for the clarifications.
Ramon,
Best Regards,
Meral
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
