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> 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**** > > ** ** > > ** ** > > _______________________________________________ > 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
