Re: [Pce] stateful PCE - moving forward & next steps

[Julien Meuric <[e-mail]>]

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
>
>
>