[Pce] stateful PCE - moving forward & next steps

Ramon Casellas <ramon.casellas@cttc.es> Sat, 20 October 2012 07:00 UTC

Return-Path: <ramon.casellas@cttc.es>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9339921F8744 for <pce@ietfa.amsl.com>; Sat, 20 Oct 2012 00:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7stzrA+YWqYR for <pce@ietfa.amsl.com>; Sat, 20 Oct 2012 00:00:01 -0700 (PDT)
Received: from villa.puc.rediris.es (unknown [IPv6:2001:720:418:ca00::7]) by ietfa.amsl.com (Postfix) with ESMTP id CB52B21F873A for <pce@ietf.org>; Sat, 20 Oct 2012 00:00:00 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <ramon.casellas@cttc.es>) id 1TPT2K-0002RX-Co for pce@ietf.org; Sat, 20 Oct 2012 08:59:56 +0200
Received: from [192.168.0.100] (62.83.140.15.dyn.user.ono.com [62.83.140.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id BF2C01FC1B for <pce@ietf.org>; Sat, 20 Oct 2012 08:59:53 +0200 (CEST)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <50824BE9.408@cttc.es>
Date: Sat, 20 Oct 2012 08:59:53 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "pce@ietf.org" <pce@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-SPF-Received: 4
X-Spamina-Bogosity: Unsure
Subject: [Pce] stateful PCE - moving forward & next steps
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Oct 2012 07:00:02 -0000

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



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