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
>
> ---
>
>