Subject: [Pce] New draf: PCEP Extensions for Temporary Reservation of Computed Path Resources and Support for Limited Context State in PCE

From: Oscar González de Dios <[email-masked]>
Date: Mon, 18 Oct 2010 15:56:26 +0200

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

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 18 Oct 2010 14:37:51 -0400

Hi,

I think the extensions proposed by this draft are extremely important 
and necessary for a real scale deployment of the PCE architecture.

Please see comments/questions below.

(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.

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.

(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?

(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.

(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?

(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)
Section 4:
"Specify what level of reservation to apply after the request."

What is level here? Granularity or path level vs SVEC level?

(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

(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?

(9)
Is it a possibility to have request priorities associated with the 
reservations? Will this be policy based applied per PCE?

Best Regards,
Meral

Oscar González de Dios <[email-masked]> 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.
>

---

From: "Ramon Casellas" <[email-masked]>
Date: Mon, 18 Oct 2010 22:44:06 +0200 (CEST)

Dear Meral, all,

> 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.

> 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.

> is crucial to determine the method(s) before finalizing the PCEP

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.

> 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."

> path requests reaches a given threshold value, the PCE may decide to

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.

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

> 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

> 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.

> 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.

> 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.

> 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,

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

--

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 20 Oct 2010 14:25:21 -0400

Hi,

    Thank you Ramon for the detailed explanations. Please see inline.

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

> reservations for the VSPT paths (except the one that is part of the e2e

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.

> 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:)

> request [within a PCReq message] (...) MUST NOT be used on a single

The new text makes perfect sense, thanks.

> to) M actual reservations (_CONFs) with distinct reservation identifiers.

I completely agree.

> 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?

> it is pcc-driven + PCE policy-checked.

Sounds good.

> sent/forwarded to a downstream / parent PCE, not only when the computation

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.

> (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?
> The same comment applies regardless absolute times. I think this may be a

agree, same comment as above on absolute timestamps.

> 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. "

> Completely agreed. I am not (yet?) confident enough to comment on this but

The WG?s help and feedbacks are going to be needed..

> solve the issue of excessive reservations, as mentioned above.

Ok.

> 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).
> your points to improve the idea.

Thank you for the clarifications.

Best Regards,
Meral