Hi Kexin, Thanks for the comments, please see below.
/Jan On 11/1/11 11:48 PM, "[email protected]" <[email protected]> wrote: >I think the objective of the two draft are the same that stateful PCE >synchronized with the state of LSPs although by different mechanism. The objectives of draft-crabbe-pce-stateful-pce are twofold: * Keep a stateful PCE synchronized with the state of LSPs in a PCC; this objective is the same as the objective of draft-tang-pce-stateful-pce. * Allow a stateful PCE to determine the timing of LSP setup in the network (in addition to determining the LSP paths through the network). We call the PCE that only wishes to know the LSP state the 'passive stateful PCE'. We call the PCE that controls the timing of LSP setups in the network the 'active stateful PCE'. > >You defined two new PCEP messages (PCRpt and PCUpd), while we extended >the existing PCNtf message. We considered extending the PCNtf message, but in the end decided to to define a new message for LSP State Reporting (PCRpt). We defined the PCUpd message to satisfy the other objective of draft-crabbe-pce-stateful-pce the active control of LSPs by a PCE. There are good reasons to define a new message for LSP State Reporting. I think we are both agreement that an LSP state report/notification must carry a set of LSP attributes that describe the LSP's state. Now, if we want to re-use the PCNtf message for LSP state reports / notifications, we can either define in the NOTIFICATION Object a set of optional TLVs that can carry the LSP attributes, or redefine the PCNtf message itself to use already defined PCEP Objects to carry LSP attributes. The TLV approach is not ideal: we already have a set of PCEP Objects that can carry the LSP attributes, now we would have to define all of them as TLVs as well. And if new LSP attributes are introduced to the PCEP protocol in the future, the may have to be defined both in PCEP Objects and in NOTIFICATION TLVs. The approach where the PCNtf message is redefined is not ideal either. For one, we may be breaking existing implementations because we are redefining the message and not using optional TLVs to define new functionality. (Note that with a new message we are not breaking existing implementations, because new messages are only used if stateful capabilities are negotiated between PCEP Speakers). Second, the PCNtf message as currently defined in PCEP seems to be designed for PCEP events (PCE congestion, cancellation of Pending Requests, Š), and changing its semantics to carry both PCEP events and LSP state does not seem to be the right thing to do. Finally, redefining the PCNtf message changes its structure to a point where we may as well define a new message, and let each message perform just one function well. > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
