Hi Adrian Good point about policy. The current revision of draft-crabbe-pce-stateful-pce only covers only basic policy settings for the PCC. We also need to cover PCE-side policies, inter-component communication (e.g. what information must be carried in State Reports form a PCE for use of a policy implemented on a PCE), etc.
IMO the PCE/PCC policy framework defined in RFC5394 by and large applies to stateful PCEs as well. There will be stateful PCEP–specific use cases and examples, policy attributes, and inter-component communication. They would need to be identified and documented.But the overall framework should be directly applicable. Thanks, Jan On 10/18/11 5:39 AM, "Adrian Farrel" <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[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
