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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
