Hi Jan,
>The PCE is not limited to path computation only. The PCE can set other LSP >parameters as well: RFC5440 defines objects for bandwidth, setup & hold >priorities, the local protection flag, etc. More LSP parameters have been >added in subsequent RFCs and drafts. [Fatai] I have to indicate that PCE cannot *set* other LSP parameters. The parameters (eg., bandwidth, priorities, etc) you mentioned are only used for *path computation*. >> I may have jumped over some paragraph where it says that the role of a Path >> Computation Element (stateful o not stateful) is to take care of the control >> of an LSP... but I honestly cannot find such statement anywhere. So... could >> you give me some arguments why the delegation of control is in scope of >> current RFC 4655? >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. Best Regards Fatai -----邮件原件----- 发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Jan Medved (jmedved) 发送时间: 2012年11月9日 9:12 收件人: Oscar González de Dios 抄送: pce@ietf.org 主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Hi Oscar, please see inline. On Nov 8, 2012, at 2:28 PM, Oscar González de Dios wrote: > [Oscar]: The state synchronization functions, aimed at (citing literally) > provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE are > consistent with this statement, they are beyond simple request/response > interactions and collect and report information in support of a stateful PCE. > Thus, this function is perfectly OK with RFC 4555. > > However, I see that the LSP delegation function goes beyond reporting > information to support a stateful PCE. It instructs the PCE to take control > of the LSP, and, during the life-time of the LSP, citing literally "the PCC > grants to a PCE the right to update LSP attributes on one or more LSPs; the > PCE becomes the authoritative source of the LSP's attributes as long as the > delegation is in effect". Thus, delegation function clearly is not used to > provide information to support later path computation. So... unless I have > mistaken the read of RFC 4655, it is explicitly mentioned that the PCE > architecture is aimed at solving the problem of path computation. The PCE is not limited to path computation only. The PCE can set other LSP parameters as well: RFC5440 defines objects for bandwidth, setup & hold priorities, the local protection flag, etc. More LSP parameters have been added in subsequent RFCs and drafts. > I may have jumped over some paragraph where it says that the role of a Path > Computation Element (stateful o not stateful) is to take care of the control > of an LSP... but I honestly cannot find such statement anywhere. So... could > you give me some arguments why the delegation of control is in scope of > current RFC 4655? 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. Now, the PCC may or may not use the LSP path/parameters that it got from the PCE. But why would the PCC not use the PCE-computed path & parameters, if we want the whole scheme to work? The PCC goes to the PCE for LSP path because the PCE can do a better job at path computation (and LSP parameter setting) that the PCC itself. The PCC would only throw away the PCE-computed LSP parameters if there was an error condition and the LSP could not be established (the PCC may in this case compute the path locally). So there is delegation in 4655, although it's implicit. Delegation is not so obvious for stateless PCEs - basically, a if PCC does not use a PCE-computed path, the impact on the stateless PCE and its path computations for other PCCs is not big, because the stateless PCE does not keep track of LSPs. The delegation concept is a lot stronger for stateful PCEs, where strict state synchronization between a PCC and a PCE is required. RFC4655 Section 6.8 states: "there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network." So if a PCC does not use the path computed by the PCE, it must notify the PCE, and also tell it about the path/parameters that were used for the LSP. This points at a tighter PCE control by a PCE over a PCC's LSPs, which in turn requires stronger delegation. In draft-ietf-pce-stateful-pce we had to make delegation explicit, because the PCE controls the timing of LSP setups/teardowns. So, when a PCC is ready to accept PCE's path computations and LSP setups, it *explicitly* delegates its LSPs to the PCE. Note that the PCC still owns all its LSPs, and can withdraw the LSP delegation from a PCE at any time. If a PCC decides not to use LSP path/parameters computed by a PCE - it can still do it, just like in the above cases. It simply revokes the LSP delegation from the PCE and does whatever it wants with the LSP. However, since it is a stateful PCC, it still MUST tell the PCE what it has done (sending a PCReport for the LSP). > (Of course the scope can be widened in future, so let's try to stick to > current RFC 4655) As outlined above, IMO draft-ietf-pce-stateful-pce is compliant with RFC4655. 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
