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