Oscar,
On Nov 12, 2012, at 6:56 AM, Oscar González de Dios wrote:
So… one of the main discussions so far has been the
“delegation” function. The name of delegation itself (and the description in
the draft) suggest a control in the PCE, and that it is the PCE the element
that makes the decisions and executes the orders. However, Jan mentions in one
his mails that the PCC can do whatever he wants with the reply of a PCE, and
that the delegation model does not change that. In my opinion, if by
“delegation” it is meant that “a PCE has to periodically compute the
reoptimization of a given LSP and compute the best moments to change the LSP
parameters”, it would be compliant with RFC 4655.
I think you are describing the following use case:
A PCC may want to request path computation from a PCE, and also let the PCE
determine the timing and sequence of the LSP setup wrt. other LSPs in the
network. So the PCC sends a PCReq message to the PCE, and the PCE, whenever it
thinks it's appropriate, sends a PCRep with the path ERO (and possibly other
parameters) down to the PCC. A PCE may send multiple PCReps down to the PCC,
whenever it decides to change the LSP (this may be periodic, as you point out,
or when the PCE detects a change in the network). When the PCC does not want
the PCE to change its LSP anymore, it sends out a PCNtf to cancel the
outstanding path computation request, or simply ignores the PCRep messages
coming down from the LSP (the notification would be strictly required in a
stateful PCE).
We actually started with this idea, but soon realized that we would have to
redefine the RP object to make it work (the RP Object is meant to associate a
single PC Request with a single PC Response). Redefining the RP object would
break existing implementations, which we did not want to do. Hence a new
message type (PCUpd) - but it is carrying the same objects as the PCRep message
would (i.e. has the same information content). Ah yes, and the PCC had to
somehow tell the PCE to start sending down the computed path, hence the
delegation message - which is performing exactly the same function as PCReq in
the above use case.
Note that, a control element uses the PCE as a computation tool only. But, the
control of the LSP will always be the role of a control element. Thus, the
“execution” of the change of the parameters of the LSP would be done by the
control element and not the PCE.
If that's the case, we would need a control element even in the simplest
stateless PCE case. A stateless PCE would not be able to send a PCRep with an
ERO to the PCC and expect it to act on the ERO. The PCE would have to talk to a
a control element, which would then "execute" the ERO change.
So, the computation vs. control argument boils down to whether the PCE is an
*authoritative* source of LSP parameters or not. If it is, it's control (in
addition to computation); if it's not (i.e. the PCC may or may not follow the
PCE's guidance), it's computation only. Delegation is an orthogonal issue, and
can be used with either.
Also, if a PCC wants to use only the information of a PCE, and trust always on
the results of PCE computation, in my view it is an implementation decision of
the control element, and would mean a very simple control element, which is
perfectly fine. There can be other cases when, depending on the network
operator policies, the PCC not always uses the results.
Thanks,
Jan
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
