I completely disagree. I think it makes a great deal of sense from both organizational and an implementation perspectives.
As a designer of these protocols, it makes a great deal of sense to separate different extensions into different documents. This improves readability, makes draft revision simpler, decreases overall complexity for draft readers and just makes great deal of sense from an organizational perspective. As a consumer of these protocols, I may want to encourage vendors to implement one of these features without forcing them to implement both. (in fact this is the case for Google; as a company we do not care about GMPLS, we /do/ very much care about MPLS-TE.) On Thu, Oct 25, 2012 at 6:27 PM, Zhangxian (Xian) <zhang.x...@huawei.com>wrote: > Hi, Dear Julien and all, > > IMHO, the stateful PCEP protocol extensions for both MPLS and GMPLS > have lots in common. So, my understanding is that there should be one > extension document. However, the preference of different parties diverges. > It would be good if we can hear more from the experts on the list which is > a better way to proceed. > > Regards, > > Xian > > -----Original Message----- > From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of > Julien Meuric > Sent: 2012年10月25日 17:39 > To: Ramon Casellas > Cc: pce@ietf.org > Subject: Re: [Pce] stateful PCE - moving forward & next steps > > Hi Ramon, hi contributors from shadow. > > We appreciate the effort of all those who are working on this work. It > will be interesting to discuss the progress during our meeting in > Atlanta. In the meantime, do not hesitate to share with the WG using the > mailing list, like your message below. > > One 1st comment at this stage: you seem to suggest that the idea is to > have separate document for MPLS-TE and GMPLS, but you do not give > rationale. Apart from our history of RFC 5440 + draft-ietf-pce-gmpls > (even with its scope, the former had a hard time), is there a particular > reason for this choice? Do you expect much difference between those 2 > kinds of extensions? Also keep in mind that GMPLS includes PSC... > > Thank you, > > Julien > > > On 10/20/2012 08:59, Ramon Casellas wrote: > > 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 – 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 > > > > > > > > _______________________________________________ > 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 > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
