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

From: "Cooper, Dave" <[email-masked]>
Date: Wed, 2 Nov 2011 05:58:58 +0000

Hi Jan, 
I'd like to express my support for this draft.

One note;

In the 3.1.2.3 Deadlock section, the first paragraph is a little confusing.   I'm unsure why the behavior is not desirable given the explanations made.  Do you mean that attempts to signal a LSP's bandwidth increase, for a given priority, may lead to sub-optimal allocation of "global" resources if the reservations of existing LSPs already signaled are not taken into account?

Thanks,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jan Medved
> Sent: Monday, October 31, 2011 12:02 AM
> To: [email-masked]
> Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful-
> pce-01.txt
> 
> Hello,
> 
> We submitted a new version of the Stateful PCE draft, where we addressed
> comments / suggestions from reviewers on the mailing list - many thanks to
> all who reviewed & commented.
> 
> We to hope to have a good discussion of the draft in Taipei.
> 
> 
> Thanks,
> Ed+Jan+Robert
> 
> 
> 
> 
> On 10/30/11 11:50 PM, "[email-masked]"
> <[email-masked]> wrote:
> 
> >A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been
> >successfully submitted by Jan Medved and posted to the IETF repository.
> >
> >Filename:	 draft-crabbe-pce-stateful-pce
> >Revision:	 01
> >Title:		 PCEP Extensions for Stateful PCE
> >Creation date:	 2011-10-30
> >WG ID:		 Individual Submission
> >Number of pages: 41
> >
> >Abstract:
> >   The Path Computation Element Communication Protocol (PCEP) provides
> >   mechanisms for Path Computation Elements (PCEs) to perform path
> >   computations in response to Path Computation Clients (PCCs) requests.
> >
> >   Although PCEP explicitly makes no assumptions regarding the
> >   information available to the PCE, it also makes no provisions for
> >   synchronization or PCE control of timing and sequence of path
> >   computations within and across PCEP sessions.  This document
> >   describes a set of extensions to PCEP to enable this functionality,
> >   providing stateful control of Multiprotocol Label Switching (MPLS)
> >   Traffic Engineering Label Switched Paths (TE LSP) via PCEP.
> >
> >
> >
> >
> >
> >
> >The IETF Secretariat
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 1 Nov 2011 23:30:44 -0700

Dave,

Thanks, good catch - we're actually trying to say that the behavior is
specified in 3209 AND is desirable for the reasons given.  We will correct
the text.

cheers,

  -ed

On Tue, Nov 1, 2011 at 10:58 PM, Cooper, Dave <[email-masked]>wrote:

> In the 3.1.2.3 Deadlock section, the first paragraph is a little
> confusing.   I'm unsure why the behavior is not desirable given the
> explanations made.  Do you mean that attempts to signal a LSP's bandwidth
> increase, for a given priority, may lead to sub-optimal allocation of
> "global" resources if the reservations of existing LSPs already signaled
> are not taken into account?
>
> Thanks,
> Dave
>
>

---

From: [email-masked]
Date: Wed, 2 Nov 2011 14:48:06 +0800

Dear Authors,

I have reviewed your draft, the motivation described in 3.1.2 is very 
reasonable.
I have a question. Do you make the assumption in your examples that there 
is no sufficient network resource for all the LSPs to be set up?

We updated our "stateful PCE" I-D recently. 
http://tools.ietf.org/html/draft-tang-pce-stateful-pce-02
I think we are considering the same following problems.
1. Why stateful PCE is important?
2. How to realize stateful PCE?

For the 1st problem, as I mentioned above, your consideration may mainly 
focus on the scenario where network resources is insufficient.
Our motivation is mainly to the condition that the network capacity is 
enougy for all the LSPs to be set up.
Our objective is to avoid resources conflict because lack of the state of 
LSPs. 
Take the follow demonstration topology for example.

Link capacity of A-B / B-C / A-C:  100M
Bandwidth demond: LSP 1 needs 80M. LSP2 needs 80M.
Source and destination of LSP1 and LSP2: Both of them is from A to B.
T1: PCE computed the shortest path for LSP1 : A-B (computation result did 
not synchronized with PCE)
T2: PCE computed the shortest path for LSP2 : A-B (PCE assume the 
unreserved bandwidth of A-B is still 100M, although is 20M in fact)
T3: LSP1 set up successful by signaling 
T4: LSP2 failed to set up by signaling (no sufficient link capacity 
aviable on link A-B)

I think the objective of the two draft are the same that stateful PCE 
synchronized with the state of LSPs although by different mechanism.
You defined two new PCEP messages (PCRpt and PCUpd), while we extended the 
existing PCNtf message.

Thanks,
Kexin

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

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 2 Nov 2011 10:15:13 -0700

Kexin,

Not true;   in one case (3.1.2.3) there is insufficient capacity to meet a
demand (and thus the demand set: ie: the network is underprovisioned).
In the rest of the cases, there is sufficient aggregate capacity to meet
the demands.  The total demand time series set is given for each toy
example.

The problem may be that you are interpreting the column on the far left of
the demand tables as an lsp id / demand index when it is a time point in
the time series of demand characteristics?

best,

  -ed