Hi Jan,
Thanks for your reply,you mentioned your objectives as follows:
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).
The 1st objective is common for both drafts, which consistent with the
definition of stateful PCE described in RFC4655,
and I think it is the main problem to realize stateful PCE I think.
As to the 2nd objective you described , I was not sure about the main use
cases of active stateful PCE.
Is it when the PCE can not compute a path for the upcoming LSP,then the
PCE change the existing "pending"LSP to "down",
so as to maximize the network resourece utilization or for other
optimization objective,according to some policy?
Thanks,
Kexin
------------------------------------------------------
Kexin Tang
Control Plane Engineer
ZTE Corporation
address: No.50 Software Avenue, Yuhuatai District,
Nanjing,Jiangsu, P.R.China,210012
phone: 13815871206
email: [email protected]
------------------------------------------------------
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
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and are
not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
