[Pce] PCE Work in CCAMP

Julien Meuric <julien.meuric@orange.com> Wed, 28 March 2012 16:59 UTC

Return-Path: <julien.meuric@orange.com>
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 E6ED621E8258; Wed, 28 Mar 2012 09:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.841
X-Spam-Level:
X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKaWZJKtbj2i; Wed, 28 Mar 2012 09:59:16 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5AA21E8254; Wed, 28 Mar 2012 09:59:16 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 055BE16C065; Wed, 28 Mar 2012 18:59:15 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id EFBFD16C064; Wed, 28 Mar 2012 18:59:14 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 18:59:14 +0200
Received: from [10.193.116.59] ([10.193.116.59]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 18:59:14 +0200
Message-ID: <4F734361.8020000@orange.com>
Date: Wed, 28 Mar 2012 18:59:13 +0200
From: Julien Meuric <julien.meuric@orange.com>
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19
MIME-Version: 1.0
To: "ccamp@ietf.org" <ccamp@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Mar 2012 16:59:14.0813 (UTC) FILETIME=[1B07AAD0:01CD0D04]
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: [Pce] PCE Work in CCAMP
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: Wed, 28 Mar 2012 16:59:17 -0000

Hi CCAMPers.

Following the meeting this morning, I would like to comment on the 
numerous references to PCE with my chair hat on.

First, I am glad to see the PCE architecture being encompassed as a 
relevant part of various proposals. Nevertheless, as said during several 
PCE meetings, when it comes to make PCEP support a CCAMP feature, it is 
most of the time driven by RSVP-TE capabilities and/or (IGP-driven) path 
computation capabilities. As reminded during the PCE meeting in Taipei, 
this obviously applies to flexi-grid work: when GMPLS protocol 
extensions will be mature enough, PCEP extensions will become rather 
straightforward and PCE-specific frameworks may be useless. I also know 
how tempting it is for the optical world to address problems with 
centralized entities, however the current PCE charter is not to solve 
all issues which may benefit from a centralized entity (which is a very 
_specific_ use case of PCE).

At this stage, my suggestion to CCAMP draft authors (mainly on 
flexi-grid) is to tackle the work step by step without "chasing 2 hares" 
at the same time; i.e. keep the PCE material on hold till the work is 
mature enough, and, then, consider the opportunity to submit this 
material to the _PCE WG_. Let me also take the opportunity to remind that:
- the PCE WG does not standardize a path computation entity, does not 
standardize any structural architecture, but *protocols* relevant to its 
_functional_ architecture;
- even if the PCE WG has started to work on some stateful features, it 
does not automatically imply that anything tagged "stateful" is (nor 
will be) in scope (please read again RFCs and WG I-Ds).

Best regards,

Julien