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> 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] > *发送时间:* 2012年11月12日 11:59 > *收件人:* Fatai Zhang > *抄送:* Jan Medved (jmedved); 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> > 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
