[Pce] RFC6006bis

Dhruv Dhody <dhruv.dhody@huawei.com> Thu, 03 November 2016 09:58 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2F9B5129586 for <pce@ietfa.amsl.com>; Thu, 3 Nov 2016 02:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.718
X-Spam-Status: No, score=-5.718 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=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WpDmjFtiVpqs for <pce@ietfa.amsl.com>; Thu, 3 Nov 2016 02:58:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E56129428 for <pce@ietf.org>; Thu, 3 Nov 2016 02:58:22 -0700 (PDT)
Received: from (EHLO lhreml705-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUK98742; Thu, 03 Nov 2016 09:58:18 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com ( by lhreml705-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Thu, 3 Nov 2016 09:58:12 +0000
Received: from BLREML501-MBX.china.huawei.com ([]) by BLREML407-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 15:28:01 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "pce@ietf.org" <pce@ietf.org>
Thread-Topic: RFC6006bis
Thread-Index: AdI1senDznHi90ZNSxO4IKCBtMFEPg==
Date: Thu, 3 Nov 2016 09:58:01 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8C9C143C@blreml501-mbx>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.581B0A3A.01C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 02c5a4303595e96b474ec6fe5667c59a
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/MA1_cuYmdGGfDspJe6xkfcYoLFU>
Subject: [Pce] RFC6006bis
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 09:58:25 -0000


We have uploaded a bis document for RFC6006 (P2MP) - https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/. 

The changes made to RFC6006 can be seen at - 


   This document obsoletes RFC 6006 making following changes to that

   o Incorporate all outstanding Errata.

      * Erratum with IDs: 3819, 3830, and 3836. 

   o Update the Routing Backus-Naur Form (RBNF) [RFC5511] for Request
   message format: 

      * Update the request message to allows for the bundling of
      multiple path computation requests within a single Path
      Computation Request (PCReq) message.

      * Add <svec-list> in PCReq message. This object was  missed in

      * Add BNC object in PCReq message. This object is required to
      support P2MP. It shares the same format as Include Route Object
      (IRO) but it is a different object. 

      * Update the <RRO-List> format to also allow Secondary Record
      Route object (SRRO). This object was  missed in [RFC6006].

      * Removed the BANDWIDTH Object followed by Record Route Object
      (RRO) from <RRO-List>. As BANDWIDTH object doesn't need to follow
      for each RRO in the <RRO-List>, there already exist BANDWIDTH
      object follow <RRO-List> and is backward compatible with

      * Update the <end-point-rro-pair-list> to allow optional BANDWIDTH
      object only if <RRO-List> is included. 

   o Update the RBNF for Reply message format:

      * Update PCEP allows for the bundling of multiple path computation
      responses within a single Path Computation Reply (PCRep) message.

      * Update UNREACH-DESTINATION in PCRep message. This object was 
      missed in [RFC6006].

We request WG to have a look and provide comments. 

Stateful P2MP draft is also updated to accommodate these changes -