Subject: Re: [Pce] 答复: Re: New Version Notification for draft-crabbe-pce-stateful-pce-01.txt

From: Jan Medved <[email-masked]>
Date: Wed, 2 Nov 2011 17:15:15 -0700

Hi Kexin,

Thanks for the comments, please see below.

/Jan

On 11/1/11 11:48 PM, "[email-masked]" <[email-masked]> 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.

---

From: [email-masked]
Date: Fri, 4 Nov 2011 18:13:25 +0800

Hi Jan,

Thanks for your reply,you mentioned your objectives as follows:

    * 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-masked]
------------------------------------------------------

Hi Kexin,

/Jan

_______________________________________________
Pce mailing list
[email-masked]
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.