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 <zhangfa...@huawei.com<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, then please, by all means... On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang <zhangfa...@huawei.com<mailto:zhangfa...@huawei.com>> 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<mailto:jmed...@cisco.com>] 发送时间: 2012年11月10日 0:27 收件人: Fatai Zhang 抄送: Oscar González de Dios; pce@ietf.org<mailto: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 _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
