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 > > --- > > _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
