> > > 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.**** > > **** > > 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 > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
