Thank you, Ramon, for summarizing the off-list discussion. We, authors of relevant drafts wrt stateful PCE, have had a fruitful discussion. As always, comments to the discussion detailed as below and/or the relevant drafts themselves are more than welcome.
Regards, Xian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ramon Casellas Sent: 2012年10月20日 15:00 To: [email protected] Subject: [Pce] stateful PCE - moving forward & next steps Dear PCErs, We've taken this issue off-list and discussed. A summary of our agreed upon next steps follows for WG review: 1/ - We have agreed to merge the applicability portion of the existing WG draft (draft-ietf-pce-stateful-pce) with Xian’s presented draft on this very same aspect. This new joint/merged draft, temporarily referred to as draft-zhang-pce-stateful-pce-app-03, will tentatively be ready for IETF86. It will be informational in nature, highlighting the benefits and use cases of a stateful PCE. While this split is by no means mandatory, it does address some comments raised during WG adoption. Selected text and wording from to current framework draft draft-ietf-pce-stateful-pce-02 will be moved to the applicability, notably in sections 2 and 3. 2/ - draft-ietf-pce-stateful-pce-02 is relatively mature, and a significant amount of time has been invested on it. It has been recently updated to acknowledge/reflect that PCEP (and consequently any PCEP functional extensions) needs to be extended to fully cover GMPLS networks in a way similar to how RFC5440 is extended by draft-ietf-pce-gmpls. This draft already covers most refined details such as protocol procedures & messages, LSP identifiers, LSP descriptive names, etc., while leaving technology specific aspects aside. 2.a �C it is worth noting that, although draft-zhang-pce-stateful-app will surely need to follow regular draft procedures, the chairs explicitly agreed to accept the post-split framework as a working group document given the acceptance of the original stateful doc. 3/ Since one of the additional comments during the WG adoption poll (e.g., by yours truly and others) was that, in its previous form, draft-ietf-pce-stateful-pce did not cover GMPLS extensions and could limit its applicability in transport networks, specific “solutions” documents addressing extensions will be developed. They will be based on the framework and will refer to it. -A consequence of this is that draft "Current Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks", aka draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt will be rewritten to follow the new apps & fwk and will define encodings e.g. at the "message level" (such as extended RBNF for a PCRpt message considering GMPLS-specific extensions). -Likewise, for RSVP-TE covering non-GMPLS cases & networks, a new draft has just been submitted and will be presented (draft-crabbe-pce-stateful-pce-mpls-te-00) -Within reasonable standard procedures, the GMPLS solutions draft can just point at the relevant sections within draft-crabbe-pce-stateful-pce-mpls-te-00 and complete where appropriate / necessary. 4/ Other stateful-PCE based applications will be identified in the future. Our suggested procedure will consist on extending the basic framework document by means of other drafts that complement it and build upon the core framework. Thank you, Ramon, on behalf of the stateful-PCErs -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
