Adrian; I think not mentioning 5557 is clearly an oversight on our part. We will remedy this in the next version of the draft.
Optimization of resource usage is certainly an interesting use case for stateful PCE (although by no means the only one), and the draft would benefit from a comparison with what is achievable via stateful extensions relative to 5557. Global control of LSP operation sequence in 5557 is predicated on the use of what is effectively a stateful (or semi-stateful) NMS, which is either not local to the switch (in which case we are required to use another northbound interface for LSP attribute changes) or local/collocated, in which case we have some significant issues with efficiency in resource usage. Stateful adds a few features here in that: 1) the requirements for the NMS and additional northbound interface are effectively removed 2) it allows the system with the greatest visibility of the system to determine which LSPs should reoptimized and on what time interval 3) the pce controls the sequence of events across pcc's, allowing for bulk (if not global) optimization, lsp shuffling etc Thanks much for pointing out the oversight. :-/ best, -ed On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel <[email protected]> wrote: > Hi Ed,**** > > ** ** > > Interesting work, thanks. As you know, the concept of stateful PCE was in > our minds all through the architecture phase of PCE and is included as a > concept in RFC 4655.**** > > ** ** > > I think stateful PCE was left on one side over the last few years because > it added complexity and the use cases were far more sophisticated than > applied to initial use cases. But now that PCE is established as an idea, it > is interesting to look at the more advanced uses that you describe and see > how stateful PCE could be a benefit.**** > > ** ** > > It is good that you have a section on policy, because it is likely that > operators will want to tweak this function in different ways according to > how they run their networks. It might be interesting to make a reference to > RFC 5394 and show how that description of policy fits in. Maybe the authors > of 5394 could comment?**** > > ** ** > > You don't mention RFC 5557. Is this because you think GCO is too complex to > be valuable or because it is not one of your primary use cases?**** > > ** ** > > Thanks,**** > > Adrian**** > > ** ** > > *From:* Edward Crabbe [mailto:[email protected]] > *Sent:* 17 October 2011 06:33 > *To:* [email protected] > *Cc:* JP Vasseur; Julien Meuric > *Subject:* Fwd: New Version Notification for > draft-crabbe-pce-stateful-pce-00.txt**** > > ** ** > > Hello;**** > > ** ** > > We've submitted a draft for the group's consideration. We know that > stateful PCE has been discussed by the working group in the past. We believe > that we have addressed some of the issues that have been raised in previous > discussions and have specific use cases that make stateful PCE valuable. We > hope you'll find the time to look through the draft and comment on the list > before the WG meeting in Taipei, and hope that we'll be able to have a > fruitful and lively discussion there. **** > > ** ** > > best,**** > > ** ** > > -Edward**** > > ** ** > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Sun, Oct 16, 2011 at 7:51 PM > Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt > To: [email protected] > Cc: [email protected], [email protected], [email protected] > > > A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been > successfully submitted by Edward Crabbe and posted to the IETF repository. > > Filename: draft-crabbe-pce-stateful-pce > Revision: 00 > Title: PCEP Extensions for Stateful PCE > Creation date: 2011-10-16 > WG ID: Individual Submission > Number of pages: 39 > > 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
