Hi Ed, I agree these are important usecases to consider in defining a new architecture for PCE.
Thanks, Vishwas On Tue, Oct 18, 2011 at 6:32 PM, Edward Crabbe <e...@google.com> wrote: > 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 <adr...@olddog.co.uk>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:e...@google.com] >> *Sent:* 17 October 2011 06:33 >> *To:* pce@ietf.org >> *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: <internet-dra...@ietf.org> >> Date: Sun, Oct 16, 2011 at 7:51 PM >> Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt >> To: e...@google.com >> Cc: jmed...@juniper.net, e...@google.com, rva...@juniper.net >> >> >> 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
