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
