Hi Ed, answers inline,
IMO: they're the same thing, the only difference is directionality and
asynchrony.
[Oscar] Agree.. Let's see what our WG chairs say.
My opinion in the matter of the stateful PCE is that we should
separate the functionality is different functional elements, in the same way as
it was done in the Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic
Engineering (RFC 5623) between a VNTM and the PCE. In such RFC, the roles of
each functional element are clearly distinguished. Let be the stateful PCE a
Path Computation element using the traffic engineering database and the LSP
database, and then, define another functional element (call it LSP controller,
call it manager) that is in care of the control issues.
This argument is orthogonal to the previous paragraph regarding the charter;
let's separate the two discussions. ;)
[Oscar] Agree, it's a separate discussion.
w/r/t *element* separation: I think that's a poor idea, sorry. It makes total
sense to me that a given PCE would be able to negotiate and support stateful or
stateless functionality.
[Oscar] What I mean is to have a demarcation of the functional blocks. My
problem is that I may be too picky, but I like to call things by its name...
and for me still Path Computation refers to the computation function and not
controlling. So path computation and control of a delegated LSP (or even
initiation) are different functions, which are tightly connected to solve the
problems. I guess when you refer to negotiate "stateful" functionality you are
referring to negotiate the delegation+whatever control functionalities and not
only the fact of using (and synchronizing) the LSP Database. The confusion may
come from the fact you see the "stateful PCE" as the sum of a controller + a
PCE + TEDB+LSPDB.... I like that entity, but, strictly speaking, it is more
than a PCE ...... But it is only a matter of naming, we all have agreed that
the functionality is needed, and that PCEP is a good protocol to support it.
I see this "controller" functional block as a generalization of the VNTM
functional block defined in RFC 5623 for the specific case of
controlling/managing an overlay network.
Said that, I must say that I like the new functionalities
proposed , and I think they solve problems (and people also did like them, as
the stateful draft was supported by the WG people). What I do not like at all
is how it is being handled. There has been a solution quickly adopted without
taking any care in the architectural/functional implications. In my opinion we
should handle them now.
Define quickly man? The original draft went through multiple rounds of review
both on list and in multiple (technically two but really three) IETF meetings
before acceptance.
It has received, as you said, broad support and review by many people on the
list, including you. ;) It is at a relatively low rev count and is still a work
in progress.
[Oscar] And I do support it and like it! I meant quickly because it went
through directly as a solution. Other pieces of work had to deal first with the
framework/requirements and then jump in the solution, there are plenty of
examples around, you can see the time of the first draft of the
framework/requirements and the time of the adoption of the first WG
solution.... (Interlayer, GMPLS, H-PCE)... This stateful PCE approach has a lot
of implications, this is why I think we should take it with care and make it
work together, with a clear architecture and make a good framework to have
solid foundations.
best,
-ed
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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
