Document Action: 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering' to Informational RFC (draft-ietf-pce-inter-layer-req-15.txt)
The IESG <iesg-secretary@ietf.org> Mon, 31 October 2011 17:06 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9411E8170; Mon, 31 Oct 2011 10:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 oY-xLBtKz4MD; Mon, 31 Oct 2011 10:06:34 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA70611E8172; Mon, 31 Oct 2011 10:06:34 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering' to Informational RFC (draft-ietf-pce-inter-layer-req-15.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.62
Message-ID: <20111031170634.18192.74088.idtracker@ietfa.amsl.com>
Date: Mon, 31 Oct 2011 10:06:34 -0700
Cc: 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.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 31 Oct 2011 17:06:35 -0000
The IESG has approved the following document: - 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering' (draft-ietf-pce-inter-layer-req-15.txt) as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-req/ Technical Summary MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. Working Group Summary No controversy on the I-D. Document Quality Comments sent by reviewers during last call have been addressed. A solution I-D is currently PCE WG document. Personnel Julien Meuricis the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note > Section 1 Final sentence > > ADD > and the framework provided in [RFC5623]. > END > > --- > > Section 3.1.2 > > OLD > Note that a PCE may not be able to distinguish virtual TE links from > regular TE links. In such cases, even if a request from a PCC to a > PCE indicates that triggered signaling is not acceptable, a PCE may > choose virtual TE links in path computation. Therefore, when a > network uses virtual TE links and a PCE is not able to distinguish > virtual TE links from regular TE links, it MUST be understood that a > PCE may choose virtual TE links even if a request from a PCC to a PCE > indicates triggered signaling is not acceptable. > NEW > Note that a PCE may not be able to distinguish virtual TE links from > regular TE links. In such cases, even if a request from a PCC to a > PCE indicates that triggered signaling is not acceptable, a PCE may > choose virtual TE links in path computation. Therefore, when a > network uses virtual TE links and a PCE is not able to distinguish > virtual TE links from regular TE links, a PCE MAY choose virtual TE > links even if a request from a PCC to a PCE indicates triggered > signaling is not acceptable. > END > > OLD > Also note that an ingress LSR may be present in multiple layers. > Thus, when a mono-layer path is requested or supplied, PCEP MUST be > able to indicate the required/provided path layer. > NEW > Also note that an ingress LSR of a higher-layer or lower-layer LSP > may be present in multiple layers. > Thus, even when a mono-layer path is requested or supplied, PCEP MUST > be able to indicate the required/provided path layer. > END > > --- > > Section 3.1.3 > > OLD > Furthermore, it may be desirable to constrain the number of layer > boundaries crossed (i.e., the number of adaptations performed on the > end-to-end path), so PCEP SHOULD include a constraint or objective > function to minimize or cap the number of adaptations on a path, and > a mechanism to report that number when a path is supplied. > NEW > Furthermore, it may be desirable to constrain the number of layer > boundaries crossed (i.e., the number of adaptations in the sense used > in [RFC5212] performed on the end-to-end path), so PCEP SHOULD > include a constraint or objective function to minimize or cap the > number of adaptations on a path, and a mechanism to report that > number when a path is supplied. > END > > --- > > 3.1.4 New first paragraph > > NEW > The concept of adaptation is used here as introduced in [RFC5212]. > END > > --- > > Section 4.1 New final paragraph > > NEW > A further discussion of policy-enabled path computation can be found > in [RFC5394]. > END > > --- > > Section 4.6 New first paragraph > > NEW > This section examines the impact on network operations of the > use of a PCE for inter-layer traffic engineering. It does not present > any further requirements on the PCE or PCC, for the PCEP, or for > deployment. > END > > --- > > Section 8.2 > > ADD > [RFC5394] I. Bryskin, D. Papadimitriou, L. Berger, and J. Ash, > "Policy-Enabled Path Computation Framework", RFC 5394, > December 2008 > END > > --- > >