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 On Tue, Nov 1, 2011 at 11:48 PM, <[email protected]> wrote: > > 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 > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Jan Medved > > Sent: Monday, October 31, 2011 12:02 AM > > To: [email protected] > > 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 protected]" > > <[email protected]> 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 protected] > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > 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. > >
<<image/gif>>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
