AFAIK: (a): we are getting guidance from the chairs on an ongoing basis and (b): the solution and framework are coupled and are reasonably well defined currently, modulo the (largely aesthetic) considerations raised
On Thu, Nov 8, 2012 at 1:11 AM, Fatai Zhang <zhangfa...@huawei.com> wrote: > 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**** > > ** ** > > *发件人:* pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] *代表 *Oscar González > de Dios > *发送时间:* 2012年11月8日 8:17 > *收件人:* Edward Crabbe > *抄送:* pce@ietf.org > *主题:* 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
