PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering
RFC 6457

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    pce mailing list <pce@ietf.org>,
    pce chair <pce-chairs@tools.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)

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