Protocol Action: 'Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Fri, 11 June 2010 15:26 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 53F913A68E7; Fri, 11 Jun 2010 08:26:33 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths' to Proposed Standard
Message-Id: <20100611152633.53F913A68E7@core3.amsl.com>
Date: Fri, 11 Jun 2010 08:26:33 -0700
Cc: Internet Architecture Board <iab@iab.org>, pce mailing list <pce@ietf.org>, pce chair <pce-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 15:26:33 -0000

The IESG has approved the following document:

- 'Extensions to the Path Computation Element Communication Protocol 
   (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched 
   Paths '
   <draft-ietf-pce-pcep-p2mp-extensions-11.txt> as a Proposed Standard


This document is the product of the Path Computation Element Working Group. 

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-11.txt

Technical Summary

   The Path Computation Element (PCE) defined in [RFC4655] is an entity
   that is capable of computing a network path or route based on a
   network graph, and applying computational constraints.  A Path
   Computation Client (PCC) may make requests to a PCE for paths to be
   computed.

   [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
   Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   The PCE has been identified as a suitable application for the
   computation of paths for P2MP TE LSPs [RFC5671].

   The PCE communication protocol (PCEP) is designed as a communication
   protocol between PCCs and PCEs for point-to-point (P2P) path
   computations and is defined in [RFC5440].  However, that
   specification does not provide a mechanism to request path
   computation of P2MP TE LSPs.

   A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.
   These S2L sub-LSPs are set up between ingress and egress LSRs and are
   appropriately overlaid to construct a P2MP TE LSP. During path
   computation, the P2MP TE LSP may be determined as a set of S2L sub-
   LSPs that are computed separately and combined to give the path of
   the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP
   tree in a single computation.

   This document relies on the mechanisms of PCEP to request path
   computation for P2MP TE LSPs.  One path computation request message
   from a PCC may request the computation of the whole P2MP TE LSP, or
   the request may be limited to a sub-set of the S2L sub-LSPs. In the
   extreme case, the PCC may request the S2L sub-LSPs to be computed
   individually with it being the PCC's responsibility to decide whether
   to signal individual S2L sub-LSPs or combine the computation results
   to signal the entire P2MP TE LSP.  Hence the PCC may use one path
   computation request message or may split the request across multiple
   path computation messages.

Working Group Summary

   No controversy.

Document Quality

   Good.

   There is one known implementations of the protocol extensions
   described in this document.

RFC Editor Note

Section 3.10 paragraph 4
OLD
   The PCC must also provide the list of old leaves, if any, including
   END-POINTS with leaf type 3, leaf type 4 or both.  The error values
   when the conditions are not satisfied (i.e., when there is no 
   END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with
   leaf type 1 or 2). A generic "Inconsistent END-POINT" error is also
   requested if a PCC receives a request that has an inconsistent
   END-POINT (i.e.,  if a leaf specified as type 1 already exists). The
   The IANA request for all new error values is documented in Section 
   6.6. (PCEP Error Objects and Types) of this document. 
NEW
   When adding new leaves or removing old leaves to the existing P2MP 
   tree the PCC must also provide the list of old leaves, if any, 
   including END-POINTS with leaf type 3, leaf type 4 or both. New PCEP
   error objects and types are necessary to report when certain 
   conditions are not satisfied (i.e., when there are no END-POINTS with
   leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 or
   2). A generic "Inconsistent END-POINT" error will be used if a PCC 
   receives a request that has an inconsistent END-POINT (i.e., if a
   leaf specified as type 1 already exists). These IANA requests are
   documented in Section 6.6. (PCEP Error Objects and Types) of this
   document. 
END

---

Section 4.1 First bullet

OLD
   o  The ability to enable to disable P2MP path computations on the 
      PCE.
NEW
   o  The ability to enable or disable P2MP path computations on the 
      PCE.
END