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