Fatai, On Nov 11, 2012, at 10:12 PM, Fatai Zhang wrote:
Hi Jan, [RFC5440] says: If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is not equal to 0, the PCReq message MUST contain a BANDWIDTH object. I don’t think this means that PCE can set the bandwdith. All the paratermetes (either optional or mandatory) sent from PCC to PCE in the PCReq are the contranits that will be taken into acccount for PCE to perform path compution. 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. In addition, I would like to remind that *set* != *delegation*, maybe we stray a little from the point, :) Agreed. *delegation* == *allow to set*. When a PCC sends a PCReq to a PCC, the PCC allows the PCE to set the ERO for one of its LSPs. (Let's just focus on the ERO for now; a PCE can determine other LSP parameters as well, but let's leave that aside for now and agree on the ERO.) The PCC delegates, the PCE sets. Best Regards Fatai Thanks, Jan 发件人: Jan Medved (jmedved) [mailto:jmed...@cisco.com] 发送时间: 2012年11月12日 13:09 收件人: 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 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<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 https://www.ietf.org/mailman/listinfo/pce
