Subject: [Pce] Control vs Computation

From: Oscar González de Dios <[email-masked]>
Date: Mon, 12 Nov 2012 14:56:51 +0000

Dear PCErs,

                Let's follow Ed suggestion of renaming the thread discussion to "Control vs Computation", and try to agree in this point (other threads can be started for other discussions, such as what can be computed or not). I'll try to summarize my vision of control vs computation based on the latest discussions in the list.

                In my humble opinion, the role of PCE is computation only (see definition in section 3 of RFC 4655). This does not mean "computing only a ERO from a request". There can be different kind of computations. For example, a computation can be a re-optimization of an existing path, and as a result, some parameters of the path may change. In case of a multilayer network, a result of a computation may include new paths from the server layer. Note in this last case, not only a single path is computed, but several ones. Thus, there are lots of possible computation use cases. We may (if needed) start a separate thread on what can be computed or not, so I will not enter in this discussion now.

                However, what is done with the information from the computation is not a business of a Path Computation Element. A control element, with the help of a PCE will make the necessary changes in the network (modify the parameters of a path, create new LSPs, etc), and will have all the necessary policies and mechanisms for that. We all agree that, even stateless or stateful PCE can help the control element, only a stateful PCE has enough information to be useful in some cases, especially when optimization is involved. Thus, a control element, with a help of a stateful PCE, is a powerful tool for a traffic engineering. And, in my opinion, this combination of control element+PCE cannot be called "stateful PCE".

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

                The same would apply to the "inititation" function. Note in this case, there is a precedent in the PCE architecture. In RFC 6457, a path computation can determine the LSPs that would need to be set-up in a server layer. Does it mean that the PCE establishes these LSPs? No.. For example, in one of the proposed models, there is a "control" element called "VNTM", literally defined as the element that manages and controls the VNT, and it is the element that is in charge of initiating the new LSPs. There are several models proposed for that case, but in none the PCE establishes the LSPS. Thus, the "execution" of establishment of new LSPs would be done by another element, not the PCE. When I did some research work in the VNTM, I proposed a "suggestion" function. This is, a PCE computes a set of useful additional paths for a given LSP. Then, the control element decides if it is OK to go with them or not.

                Please, let me know if you agree or not with this vision about the separation of roles of computation vs control (as said on the beginning, if you disagree of what can be computed or not, let's use another thread). If we all agree, the solution would be easy, defining and scoping clearly delegation, and eventually find a new name as Jan suggests, with which the WG members feel better (if needed).

                Best Regards,

                               Óscar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Tue, 13 Nov 2012 03:48:41 +0000

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