Re: [Pce] New Version Notification for draft-tanaka-pce-stateful-pce-mbb-04.txt

Ramanjaneya palleti <ramanjaneya.palleti@huawei.com> Mon, 03 July 2017 04:23 UTC

Return-Path: <ramanjaneya.palleti@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 07597128C81; Sun, 2 Jul 2017 21:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caVGcH5efpEF; Sun, 2 Jul 2017 21:23:41 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908BC124D6C; Sun, 2 Jul 2017 21:23:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJP79992; Mon, 03 Jul 2017 04:23:38 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 05:23:37 +0100
Received: from DGGEMA401-HUB.china.huawei.com (10.3.20.42) by NKGEML413-HUB.china.huawei.com (10.98.56.74) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 3 Jul 2017 12:23:34 +0800
Received: from DGGEMA503-MBS.china.huawei.com ([169.254.2.48]) by DGGEMA401-HUB.china.huawei.com ([10.3.20.42]) with mapi id 14.03.0301.000; Mon, 3 Jul 2017 12:23:25 +0800
From: Ramanjaneya palleti <ramanjaneya.palleti@huawei.com>
To: Ramanjaneya palleti <ramanjaneya.palleti@huawei.com>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>, Yosuke Tanaka <yosuke.tanaka@ntt.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Yuji Kamite <y.kamite@ntt.com>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: New Version Notification for draft-tanaka-pce-stateful-pce-mbb-04.txt
Thread-Index: AQHS79Y/+pMf5opc50+PUICesXwtGKJBeWgwgAAOc0A=
Date: Mon, 03 Jul 2017 04:23:24 +0000
Message-ID: <E64D53B0BCA26E4CBC6E4FB01D42350DE25E147C@DGGEMA503-MBS.china.huawei.com>
References: <149863065062.18278.11407971009031865457.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.152.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5959C6CB.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a236b5376e5582c9bde5f42340fa6cf8
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/VCRm-skgbzlsMj24ZvJeTdrSigM>
Subject: Re: [Pce] New Version Notification for draft-tanaka-pce-stateful-pce-mbb-04.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 03 Jul 2017 04:23:43 -0000

Hi WG, 

We have update the Stateful PCE make-before-break draft. It uses the base association draft by creating a new association type for explicit MBB. 

The main changes are – 

-       Use of base ASSOCIATION object
-       Updated the Trial LSP TLV as per ASSOCIATION object semantics.

Thanks & Regards,
Ramanjaneya

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 28 June 2017 11:48
To: Yosuke Tanaka; Ramanjaneya palleti; Dhruv Dhody; Ramanjaneya palleti; Yuji Kamite
Subject: New Version Notification for draft-tanaka-pce-stateful-pce-mbb-04.txt


A new version of I-D, draft-tanaka-pce-stateful-pce-mbb-04.txt
has been successfully submitted by Dhruv Dhody and posted to the IETF repository.

Name:		draft-tanaka-pce-stateful-pce-mbb
Revision:	04
Title:		Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE
Document date:	2017-06-27
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-tanaka-pce-stateful-pce-mbb-04.txt
Status:         https://datatracker.ietf.org/doc/draft-tanaka-pce-stateful-pce-mbb/
Htmlized:       https://tools.ietf.org/html/draft-tanaka-pce-stateful-pce-mbb-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-tanaka-pce-stateful-pce-mbb-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-tanaka-pce-stateful-pce-mbb-04

Abstract:
   Stateful Path Computation Element (PCE) and its corresponding
   protocol extensions provide a mechanism that enables PCE to do
   stateful control of Multiprotocol Label Switching (MPLS) Traffic
   Engineering Label Switched Paths (TE LSP).  Stateful PCE supports
   manipulating of the existing LSP's state and attributes (e.g.,
   bandwidth and path) via delegation and also instantiation of new LSPs
   in the network via PCE Initiation procedures.

   In the current MPLS TE network using Resource ReSerVation Protocol
   (RSVP-TE), LSPs are often controlled by Make-before-break (M-B-B)
   signaling by the headend for the purpose of LSP restoration and
   reoptimization.  In most cases, it is an essential operation to
   reroute LSP traffic without any data disruption.

   This document specifies the procedure of applying stateful PCE's
   control to make-before-break RSVP-TE signaling.  In this document,
   two types of restoration/reoptimization procedures are defined,
   implicit mode and explicit mode.  This document also specifies the
   usage and handling of stateful PCEP (PCE Communication Protocol)
   messages, expected behavior of PCC as RSVP-TE headend and necessary
   extensions of additional PCEP objects.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat