Hi Oscar, Ed and all, I totally agree with Oscar.
I think we should follow the regular procedures of PCE WG (IETF as well) to define the foundation work first including FWK, requirement, applicability before dropping into the solution stuff. Guidance from WG chairs on this stateful PCE work must be appreciated. Best Regards Fatai 发件人: [email protected] [mailto:[email protected]] 代表 Oscar González de Dios 发送时间: 2012年11月8日 8:17 收件人: Edward Crabbe 抄送: [email protected] 主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
