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

"Zhangxian (Xian)" <zhang.xian@huawei.com> Fri, 26 October 2012 01:28 UTC

Return-Path: <zhang.xian@huawei.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 1ED8521F87BD for <pce@ietfa.amsl.com>; Thu, 25 Oct 2012 18:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.338
X-Spam-Level:
X-Spam-Status: No, score=-4.338 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 Z6tqL6icPeUE for <pce@ietfa.amsl.com>; Thu, 25 Oct 2012 18:28:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1408C21F87A0 for <pce@ietf.org>; Thu, 25 Oct 2012 18:28:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMB52516; Fri, 26 Oct 2012 01:28:05 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 26 Oct 2012 02:27:47 +0100
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 26 Oct 2012 02:28:01 +0100
Received: from SZXEML535-MBX.china.huawei.com ([169.254.3.160]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 26 Oct 2012 09:27:55 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Julien Meuric <julien.meuric@orange.com>, Ramon Casellas <ramon.casellas@cttc.es>
Thread-Topic: [Pce] stateful PCE - moving forward & next steps
Thread-Index: AQHNrpCObCDiBvXRZkOdWOhWHP6m0ZfJRgSAgAGKE+A=
Date: Fri, 26 Oct 2012 01:27:54 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B13921E61@szxeml535-mbx.china.huawei.com>
References: <50824BE9.408@cttc.es> <508908D1.8070204@orange.com>
In-Reply-To: <508908D1.8070204@orange.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.105.102]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [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: Fri, 26 Oct 2012 01:28:12 -0000

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-bounces@ietf.org [mailto:pce-bounces@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 ¨C 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