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

From: Jan Medved <[email-masked]>
Date: Sat, 5 Nov 2011 21:29:25 -0700

Hi Kexin

Thanks for the comments, please see inline.

/Jan

On 11/4/11 3:13 AM, "[email-masked]" <[email-masked]> wrote:

>
>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,

Agreed.

>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?

Yes, that could be one of the use cases too.

The primary motivation for the second objective is to give a PCE the
control over the sequence and timing in altering LSP path characteristics
within and across PCEP sessions (in other words, coordinate LSP modifies
across multiple PCCs). In the draft we give multiple real-world examples
that demonstrate the need for such capability.

>
>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,
>
>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.
>
>
>>
>
>_______________________________________________
>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.