Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
Hi Jan, I granted that there is a certain degree of ambiguity in RFC 5440. First, the zero bandwidth case is a corner case, I think. Second, this is different from PCE setting the TE parameters. When you say PCE can set the TE parameters, it sounds like PCE would set the path with any arbitrary parameters it would decide upon. PCE is reactive than proactive. There could be a certain degree of ‘negotiating’ (implicit or explicit) with PCC when the requested parameters are not met by PCE. But this is very different from claiming that PCE can set the TE parameters. Thanks. Young From: Jan Medved (jmedved) [mailto:jmed...@cisco.com] Sent: Monday, November 12, 2012 11:58 AM To: Leeyoung Cc: Edward Crabbe; Fatai Zhang; pce@ietf.org Subject: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Hi Young, On Nov 12, 2012, at 6:05 AM, Leeyoung wrote: Hi Ed and Fatai If any one of them cannot be met, the PCE will send the PCC with an indication of ‘not finding a path’ or this sort. PCE cannot set these TE parameters per RFC4655. These TE parameters are passed by PCC as part of the path constraints to which path computation would apply. I thought it was clear in RFC 4655. please see my response to Fatai. Here it is, in case you have not seen it. "RFC5440 does not say anything about what a PCE MUST do when a PCC requests 0 bandwidth for an LSP. It may just grant a 0 bandwidth to the PCC, or it may determine what the bandwidth should be and include the BANDWIDTH object on a PCRep message to the PCC. The spec also does not say that the bandwidth requested by a PCC MUST be equal to the bandwidth granted by the PCE (the PCE may grant more, equal, or less bandwidth). The point I was trying to make is that the spec already allows for multiple valid use cases (that's actually the beauty of the spec :-) ). One of those use cases is where the PCE can determine all the LSP parameters that can be carried on the PCRep message and "suggest" them to the PCC. Another use case is a PCE that will either compute the ERO for the bandwidth specified in PCC's constrains or respond with a NO-PATH. All are valid use cases." Basically, what you describe above is a valid use case allowed by the spec. But it's not the ONLY valid use case. If the PCC does not set any constrains, the PCE MAY use the optional parameters on PCRep to tell the PCC what to do. It's a matter of policy between the PCC and the PCE. Young Thanks, Jan From: pce-boun...@ietf.org<mailto:pce-boun...@ietf.org> [mailto:pce-boun...@ietf.org] On Behalf Of Edward Crabbe Sent: Sunday, November 11, 2012 11:07 PM To: Fatai Zhang Cc: pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE I'm surprised by your surprise. ^_^ Seriously though, I don't mean to offend you: I want to have a productive discussion here. Most of the conversation in this thread thus far is about either language, or whether the functionality is within the scope of the charter. I believe one of our chairs has already weighed in on the scope side, so I guess we're talking about either language or I'm missing some technical point you've made regarding mechanism. W/rt whether the PCE can set parameters: yes, it clearly can. This is consistent with rfc4655 IMO. As I stated previously: I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... On Sun, Nov 11, 2012 at 8:50 PM, Fatai Zhang mailto:zhangfa...@huawei.com>> wrote: I am surprised by your tone. I am touching the tech points and trying to clarity why PCE cannot *determine* those parameters. You can correct me if I am wrong from the tech perspective. If you still use this kind of tone, sorry, I will ignore your response. Best Regards Fatai 发件人: Edward Crabbe [mailto:e...@google.com<mailto:e...@google.com>] 发送时间: 2012年11月12日 11:59 收件人: Fatai Zhang 抄送: Jan Medved (jmedved); pce@ietf.org<mailto:pce@ietf.org> 主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE We currently appear to be involved in some sort of pre-fiat working group process debate. Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason. At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/ I hope that's not the case. Obviously the working group can have a
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
Hi Young, On Nov 12, 2012, at 6:05 AM, Leeyoung wrote: Hi Ed and Fatai If any one of them cannot be met, the PCE will send the PCC with an indication of ‘not finding a path’ or this sort. PCE cannot set these TE parameters per RFC4655. These TE parameters are passed by PCC as part of the path constraints to which path computation would apply. I thought it was clear in RFC 4655. please see my response to Fatai. Here it is, in case you have not seen it. "RFC5440 does not say anything about what a PCE MUST do when a PCC requests 0 bandwidth for an LSP. It may just grant a 0 bandwidth to the PCC, or it may determine what the bandwidth should be and include the BANDWIDTH object on a PCRep message to the PCC. The spec also does not say that the bandwidth requested by a PCC MUST be equal to the bandwidth granted by the PCE (the PCE may grant more, equal, or less bandwidth). The point I was trying to make is that the spec already allows for multiple valid use cases (that's actually the beauty of the spec :-) ). One of those use cases is where the PCE can determine all the LSP parameters that can be carried on the PCRep message and "suggest" them to the PCC. Another use case is a PCE that will either compute the ERO for the bandwidth specified in PCC's constrains or respond with a NO-PATH. All are valid use cases." Basically, what you describe above is a valid use case allowed by the spec. But it's not the ONLY valid use case. If the PCC does not set any constrains, the PCE MAY use the optional parameters on PCRep to tell the PCC what to do. It's a matter of policy between the PCC and the PCE. Young Thanks, Jan From: pce-boun...@ietf.org<mailto:pce-boun...@ietf.org> [mailto:pce-boun...@ietf.org] On Behalf Of Edward Crabbe Sent: Sunday, November 11, 2012 11:07 PM To: Fatai Zhang Cc: pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE I'm surprised by your surprise. ^_^ Seriously though, I don't mean to offend you: I want to have a productive discussion here. Most of the conversation in this thread thus far is about either language, or whether the functionality is within the scope of the charter. I believe one of our chairs has already weighed in on the scope side, so I guess we're talking about either language or I'm missing some technical point you've made regarding mechanism. W/rt whether the PCE can set parameters: yes, it clearly can. This is consistent with rfc4655 IMO. As I stated previously: I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... On Sun, Nov 11, 2012 at 8:50 PM, Fatai Zhang mailto:zhangfa...@huawei.com>> wrote: I am surprised by your tone. I am touching the tech points and trying to clarity why PCE cannot *determine* those parameters. You can correct me if I am wrong from the tech perspective. If you still use this kind of tone, sorry, I will ignore your response. Best Regards Fatai 发件人: Edward Crabbe [mailto:e...@google.com<mailto:e...@google.com>] 发送时间: 2012年11月12日 11:59 收件人: Fatai Zhang 抄送: Jan Medved (jmedved); pce@ietf.org<mailto:pce@ietf.org> 主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE We currently appear to be involved in some sort of pre-fiat working group process debate. Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason. At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/ I hope that's not the case. Obviously the working group can have any technical discussion it wants, to within the bounds of reason and the chair's limits of tolerence. ;) So let's do that, and try to make our time together here productive. ^_^ w/r/t the specific comments: Yes, we already have introduced a delegation function and have had since the first rev of the draft. It is, IMO, defined clearly in the draft-crabbe-pce-stateful-pce-02. You should read it. If you don't think the definition is clear, then we should discuss that so we can improve the text. I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, t
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
> > > In addition, I would like to remind that **set** != **delegation**, maybe > we stray a little from the point, J > Please clearly explain your perception of the difference. > > > ** ** > > ** ** > > ** ** > > Best Regards > > ** ** > > Fatai > > ** ** > > *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] > *发送时间:* 2012年11月12日 13:09 > *收件人:* Fatai Zhang > *抄送:* Oscar González de Dios; pce@ietf.org > *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and > opinion about stateful PCE > > ** ** > > Fatai, > > ** ** > > On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote: > > > > > > Hi Jan, > > You said: > > =>By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree? > > > > [Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, > etc) are the constraints sent from PCC to PCE for **path computation**. ** > ** > > ** ** > > Please re-read rfc5440. A PCRep *may* contain all the above objects. There > is nothing in the RFC5440 saying the PCE could not set these parameters as > it sees fit - even change the BANDWIDTH parameter suggested by a PCC. > > > > > > For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, > and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE > **cannot > determine** these parameters. The ERO is the path information (path > list) that PCE returns to PCC after path computation. > > > > Please re-read rfc5440 - BANDWIDTH and all other LSP parameters are > *optional* on PCReq. A use case where a PCC does not include BANDWIDTH on > the PCReq message and leaves the determination of a path's bandwidth to the > PCE is well within the spec. And as I said above, a PCRep may optionally > contain bandwidth and other LSP parameters, not just the ERO. > > ** ** > > Even if we say that the only thing that the PCE does is path computation, > the PCC *delegates* path computation to the PCE. That means, delegation - > as a concept - has been a part of the PCE architecture from the very > beginning. Therefore, your arguments above about bandwidth, etc. are moot. > > > ** ** > > If you want to introduce **delegation** function (whatever we call it), > the delegation definintion should be defined clearly. > > ** ** > > We don't have to introduce it, it's already in the PCE architecture. > That's a fact. You may disagree. You are, of course, entitled to your own > opinions, but not to your own facts. > > > > I tried to explain delegation in this email thread as clearly as I could. > Please re-read it, and if you don't understand something, ask a pointed > question. If you disagree with something i wrote, please address that > clearly. Then we can have a meaningful discussion. But please do not try to > reset the discussion to with general statements. > > > > > > And then the WG will/can discuss more whether this “delegation” is needed > or not (and whether this “delegation” is in the scope of the existing > charter). > > > > Where have you been when the WG discussed draft-ietf-pce-stateful-pce? > > > > > > > > Best Regards > > > > Fatai > > > > Thanks, > > Jan > > > > > > *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] > *发送时间:* 2012年11月10日 0:27 > *收件人:* Fatai Zhang > *抄送:* Oscar González de Dios; pce@ietf.org > *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and > opinion about stateful PCE > > > > Faital, > > > > On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote: > > > > > > > >The delegation of LSP control to a PCE is *implicit* in RFC4655. When a > PCC sends a PCReq message to a PCE requesting path computation (and > parameter setting) for an LSP, it effectively > > > delegates control over that LSP to the PCE. The delegation is valid for > one request (and one path computation) only. > > > > [Fatai] I don't think that RFC4655 can support delegation of LSP *control* > (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this > LSP is delegated to the PCE. > > > > By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree? > > > > Now, whether we use "control", "authority", "power", "mandate", whatever - > that does not change the fact that the PCC asks the PCC to determine what > the LSP parameters are, and the PCE determines what the LSP parameters > are. That's what we call delegation - the PCC "delegates" the computation > of LSP path and determination of LSP parameters to the PCE. > > > >
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
We currently appear to be involved in some sort of pre-fiat working group process debate. Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason. At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/ I hope that's not the case. Obviously the working group can have any technical discussion it wants, to within the bounds of reason and the chair's limits of tolerence. ;) So let's do that, and try to make our time together here productive. ^_^ w/r/t the specific comments: Yes, we already have introduced a delegation function and have had since the first rev of the draft. It is, IMO, defined clearly in the draft-crabbe-pce-stateful-pce-02. You should read it. If you don't think the definition is clear, then we should discuss that so we can improve the text. I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang wrote: > Hi Jan, > > You said: > > =>By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree? > > ** ** > > [Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, > etc) are the constraints sent from PCC to PCE for **path computation**. > For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, > and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE > **cannot > determine** these parameters. The ERO is the path information (path > list) that PCE returns to PCC after path computation. > > ** ** > > If you want to introduce **delegation** function (whatever we call it), > the delegation definintion should be defined clearly. And then the WG > will/can discuss more whether this “delegation” is needed or not (and > whether this “delegation” is in the scope of the existing charter). > > ** ** > > ** ** > > Best Regards > > ** ** > > Fatai > > ** ** > > *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] > *发送时间:* 2012年11月10日 0:27 > *收件人:* Fatai Zhang > *抄送:* Oscar González de Dios; pce@ietf.org > *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and > opinion about stateful PCE > > ** ** > > Faital, > > ** ** > > On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote: > > > > > > >The delegation of LSP control to a PCE is *implicit* in RFC4655. When a > PCC sends a PCReq message to a PCE requesting path computation (and > parameter setting) for an LSP, it effectively > > > delegates control over that LSP to the PCE. The delegation is valid for > one request (and one path computation) only. > > > > [Fatai] I don't think that RFC4655 can support delegation of LSP *control* > (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this > LSP is delegated to the PCE. > > ** ** > > By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree? > > ** ** > > Now, whether we use "control", "authority", "power", "mandate", whatever - > that does not change the fact that the PCC asks the PCC to determine what > the LSP parameters are, and the PCE determines what the LSP parameters > are. That's what we call delegation - the PCC "delegates" the computation > of LSP path and determination of LSP parameters to the PCE. > > ** ** > > My email states a little later: "the PCC may or may not use the LSP > path/parameters that it got from the PCE". We all agree that the PCC has > the ultimate control over the LSP - it may take the directions from the > PCE, it may not. > > ** ** > > draft-ietf-pce-stateful-pce does not change any of this. The PCC gives the > PCE the control/authority/mandate/power to determine the LSP's parameter. > But, rather than doing this implicitly by requesting the PCE to determine > those parameters (in a PCReq message), it does it explicitly. Delegation > does not change the paradigm set by RFC4655 and RFC5440 - but in addition > to LSP parameters, it allows the PCE to determine the timing of the LSP > setup. > > ** ** > > If you don't like the term "delegation", please suggest another one. I > don't particularly care what we call the mechanism. > > ** ** > > ** ** > > ** ** > > Thanks, > > Jan > > ** ** > > ** ** > > _
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
On 11/09/2012 09:20 AM, Fatai Zhang wrote: Hi Jan, Hi Fatai, >The PCE is not limited to path computation only. The PCE can set other LSP parameters as well: RFC5440 defines objects for bandwidth, setup & hold priorities, the local protection flag, etc. More LSP parameters have been added in subsequent RFCs and drafts. [Fatai] I have to indicate that PCE cannot *set* other LSP parameters. The parameters (eg., bandwidth, priorities, etc) you mentioned are only used for *path computation*. I agree. The PCE does not set *any* parameters of the LSP. Only PCC can do that PCC. PCE can only provide suggestions and must be fully prepared to have them rejected. I am not aware of any restriction on what information a PCE is allowed to suggest to be modified, apart from the fact that ERO and BANDWIDTH are explictly included in that set (section 5.1.5 of RFC4657). Bye, Robert ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
Hi, I agree with oscar and Fatai The delegation/update and the initiation are related. Regarding a) I recall the in the WG meeting, one comment from the chairs was the service request in RFC4655 is not part of the computation part. In this regard it would be good to address those architectural points, but if we have some doubts we could ask network management related WGs ;-) Regarding b) this does not prevent to clarify where does it fit in the PCE architecture. Best regards / Mit freundlichen Grüßen Cyril Margaria From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of ext Edward Crabbe Sent: Thursday, November 08, 2012 8:57 AM To: Fatai Zhang Cc: pce@ietf.org Subject: Re: [Pce]答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE 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 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 plen
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
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 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 > > ** ** > -- > > > Es
