IDR
Networking Working Group                                                  Q. Wu                                 S. Previdi, Ed.
Internet-Draft                                                    Huawei                                       Cisco Systems, Inc.
Intended status: Standards Track                              S. Previdi                                   Q. Wu
Expires: July 8, 2015                                              Cisco November 12, 2016                                        Huawei
                                                              H. Gredler
                                                                 Juniper
                                                                  S. Ray
                                                                   Cisco
                                                             J. Tantsura
                                                                Ericsson
                                                         January 4, 2015

 BGP attribute for North-Bound Distribution
                                                              Individual
                                                             C. Filsfils
                                                             L. Ginsberg
                                                     Cisco Systems, Inc.
                                                            May 11, 2016

   BGP-LS Advertisement of IGP Traffic Engineering (TE)
                          performance Metrics
                      draft-ietf-idr-te-pm-bgp-02 Performance Metric
                               Extensions
                      draft-ietf-idr-te-pm-bgp-03

Abstract

   In

   This document defines new BGP-LS TLVs in order to populate network performance information like link
   latency, latency variation, packet loss and bandwidth into carry the IGP
   Traffic Engineering Database(TED) Extensions defined in IS-IS and ALTO server, OSPF protocols.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document describes
   extensions are to BGP protocol, that can be used interpreted as described in RFC 2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to distribute network
   performance information (such be
   interpreted as link delay, delay variation, packet
   loss, residual bandwidth, available bandwidth and utilized bandwidth
   ). carrying RFC-2119 significance.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on July 8, 2015. November 12, 2016.

Copyright Notice

   Copyright (c) 2015 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . .  Link Attribute TLVs for TE Metric Extensions  . . . . . . . .   3
   3.  Use Cases .  TLV Details . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  MPLS-TE with H-PCE  .  Unidirectional Link Delay TLV . . . . . . . . . . . . . .   3
     3.2.  Min/Max Unidirectional Link Delay TLV . . . .   3
     3.2.  ALTO Server Network API . . . . . .   4
     3.3.  Unidirectional Delay Variation TLV  . . . . . . . . . . .   4
   4.  Carrying TE Performance information in BGP  . .
     3.4.  Unidirectional Link Loss TLV  . . . . . . .   5
   5.  Attribute TLV Details . . . . . . .   5
     3.5.  Unidirectional Residual Bandwidth TLV . . . . . . . . . .   5
     3.6.  Unidirectional Available Bandwidth TLV  . . .   6
   6.  Manageability Considerations . . . . . .   5
     3.7.  Unidirectional Utilized Bandwidth TLV . . . . . . . . . .   7
   7.   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . .
   6.  Acknowledgements  . . . . .   8
     9.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative   7
   7.  References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change Log . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . .   9
     A.1.  draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . .   7
     7.2.  Informative References  . .   9
     A.2.  draft-ietf-idr-te-pm-bgp-02 . . . . . . . . . . . . . . .   9   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9   8

1.  Introduction

   As specified in [RFC4655],a Path Computation Element (PCE) is an
   entity that is capable of computing a network path or route based on
   a network graph,

   BGP-LS ([RFC7752]) defines NLRI and of applying computational constraints during the
   computation.  In attributes in order to compute an end to end path, the PCE needs
   to have a unified view of the overall topology[I-D.ietf-pce-pcep-
   service-aware].  [I.D-ietf-idr-ls-distribution] describes a mechanism
   by which links state and traffic engineering information can be
   collected from networks and shared with external components using the
   BGP routing protocol.  This mechanism can be used by both PCE and
   ALTO server to gather information about the topologies and
   capabilities of the network.

   With the growth of network virtualization technology, the Network
   performance or QoS requirements such as latency, limited bandwidth,
   packet loss, and jitter, for real traffic carry
   link-state information.  New BGP-LS Link-Attribute TLVs are all critical factors
   that must be taken into account required
   in the end to end path computation
   and selection ([I-D.ietf-pce-pcep-service-aware])which enable
   optimizing resource usage and degrading gracefully during period of
   heavy load .

   In order to populate network performance information like link
   latency, latency variation, packet loss and bandwidth into TED and
   ALTO server, this document describes extensions to BGP protocol, that
   can be used to distribute network performance information (such as
   link delay, delay variation, packet loss, residual bandwidth,
   available bandwidth, and utilized bandwidth).  The network
   performance information can be distributed in carry the same way as link
   state information distribution,i.e., either directly or via a peer
   BGP speaker (see figure 1 of [I.D-ietf-idr-ls-distribution]).

2.  Conventions used Traffic Engineering Metric Extensions defined
   in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", [RFC7810] and "OPTIONAL" in this
   document [RFC7471].

2.  Link Attribute TLVs for TE Metric Extensions

   The following new Link Attribute TLVs are to be interpreted as described in RFC2119 [RFC2119]. defined:

      TLV Type                   Value
   --------------------------------------------------------
    1104 (Suggested)  Unidirectional Link Delay

    1105 (Suggested)  Min/Max Unidirectional Link Delay

    1106 (Suggested)  Unidirectional Delay Variation

    1107 (Suggested)  Unidirectional Packet Loss

    1108 (Suggested)  Unidirectional Residual Bandwidth

    1109 (Suggested)  Unidirectional Available Bandwidth

    1110 (Suggested)  Unidirectional Bandwidth Utilization

3.  Use Cases  TLV Details

3.1.  MPLS-TE with H-PCE

   For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805]
   may be used to compute the optimal sequence of domains.  Within the
   H-PCE architecture, the child PCE communicates domain connectivity
   information to the parent PCE, and the parent PCE will use this
   information to compute a multi-domain path based on  Unidirectional Link Delay TLV

   This TLV advertises the optimal TE
   links average link delay between domains [I.D-ietf-pce-hierarchy-extensions] for the
   end-to-end path. two directly
   connected IGP link-state neighbors.  The following figure demonstrates how a parent PCE may obtain TE
   performance information beyond that contained in the LINK_STATE
   attributes [I.D-ietf-idr-ls-distribution] using semantic of the mechanism TLV is
   described in this document.

                  +----------+                           +---------+
                  |  -----   |                           |   BGP   |
                  | | TED |<-+-------------------------->| Speaker |
                  |  -----   |   TED synchronization     |         |
                  |    |     |        mechanism:         +---------+
                  | [RFC7810] and [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type                      | BGP with TE performance           Length                |    v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|  RESERVED   |        NLRI                   Delay                       |  -----
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

                                 Figure 1

   Type: TBA (suggested value: 1104).

   Length: 4.

3.2.  Min/Max Unidirectional Link Delay TLV

   This sub-TLV advertises the minimum and maximum delay values between
   two directly connected IGP link-state neighbors.  The semantic of the
   TLV is described in [RFC7810] and [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type                      |           Length                | PCE
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A| RESERVED    |                   Min Delay                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  -----   RESERVED    |
                  +----------+
                       ^                   Max Delay                   | Request/
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

                                 Figure 2

   Type: TBA (suggested value: 1105).

   Length: 8.

3.3.  Unidirectional Delay Variation TLV

   This sub-TLV advertises the average link delay variation between two
   directly connected IGP link-state neighbors.  The semantic of the TLV
   is described in [RFC7810] and [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Response
                       v
         Service  +----------+   Signaling  +----------+
         Request   Type                      | Head-End           Length                |   Protocol
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Adjacent  RESERVED     |
         -------->|  Node    |<------------>|   Node               Delay Variation                 |
                  +----------+              +----------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

                                 Figure 1: External PCE node using 3

   Type: TBA (suggested value: 1106).

   Length: 4.

3.4.  Unidirectional Link Loss TLV

   This sub-TLV advertises the loss (as a TED synchronization mechanism

3.2.  ALTO Server Network API

   The ALTO Server can aggregate information from multiple systems to
   provide an abstract and unified view that can be more useful to
   applications. packet percentage) between two
   directly connected IGP link-state neighbors.  The following figure shows how an ALTO Server can get TE performance
   information from the underlying network beyond that contained in the
   LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using semantic of the
   mechanism TLV
   is described in this document.

   +--------+
   | Client |<--+
   +--------+   |
                |    ALTO    +--------+     BGP with    +---------+
   +--------+   |  Protocol  |  ALTO  |  TE Performance |   BGP   | [RFC7810] and [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Client |<--+------------| Server |<----------------| Speaker   Type                      |
   +--------+           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|  RESERVED   |                  Link Loss                    |      NLR
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Type: TBA (suggested value: 1107).

   Length: 4.

3.5.  Unidirectional Residual Bandwidth TLV

   This sub-TLV advertises the residual bandwidth between two directly
   connected IGP link-state neighbors.  The semantic of the TLV is
   described in [RFC7810] and [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type                      |           Length                |            +--------+                 +---------+
   +--------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Residual Bandwidth                   | Client |<--+
   +--------+
     Figure 2: ALTO Server using network performance information
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Type: TBA (suggested value: 1108).

   Length: 4.  Carrying TE Performance information in BGP

3.6.  Unidirectional Available Bandwidth TLV

   This document proposes new BGP TE performance TLVs that can be
   announced as attribute in sub-TLV advertises the BGP-LS attribute (defined in [I.D-ietf-
   idr-ls-distribution]) to distribute network performance information. available bandwidth between two directly
   connected IGP link-state neighbors.  The extensions in this document build on semantic of the ones provided TLV is
   described in BGP-LS
   [I.D-ietf-idr-ls-distribution] [RFC7810] and BGP-4 [RFC4271].

   BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested
   TLVs which allow the BGP-LS attribute to be readily extended.  This
   document proposes seven additional TLVs as its attributes: [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type            Value

      TBD1        Unidirectional Link Delay

      TBD2        Min/Max Unidirectional Link Delay

      TBD3        Unidirectional Delay Variation

      TBD4        Unidirectional Packet Loss

      TBD5        Unidirectional Residual Bandwidth

      TBD6        Unidirectional                      |           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Available Bandwidth

      TBD7                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

                                 Figure 4

   Type: TBA (suggested value: 1109).

   Length: 4.

3.7.  Unidirectional Utilized Bandwidth

   As can be seen in the list above, TLV

   This sub-TLV advertises the TLVs described in this document
   carry different types of network performance information.  Some bandwidth utilization between two
   directly connected IGP link-state neighbors.  The semantic of
   these TLVs include a bit called the Anomalous (or "A") bit at the
   left-most bit after length field of each TLV defined
   is described in figure [RFC7810] and [RFC7471].

    0                   1                   2                   3
    0 1 2 3 4 of
   [[I.D-ietf-idr-ls-distribution]].  The other bits 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type                      |           Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Utilized Bandwidth                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

                                 Figure 5

   Type: TBA (suggested value: 1110).

   Length: 4.

4.  Security Considerations

   Procedures and protocol extensions defined in the first octets
   after length field of each TLV is reserved for future use.  When the
   A bit is clear (or when the TLV does this document do not include an A bit), the TLV
   describes steady state link performance.  This information could
   conceivably be used to construct a steady state performance topology
   for initial tunnel path computation, or to verify alternative
   failover paths.

   When network performance downgrades and exceeds configurable maximum
   thresholds, a TLV with
   affect the A bit set is advertised.  These TLVs could
   be used by the receiving BGP peer to determine whether to redirect
   failing traffic to a backup path, or whether to calculate an entirely
   new path.  If link performance improves later and falls below a
   configurable value, that TLV can be re- advertised with security model.  See the Anomalous
   bit cleared.  In this case, 'Security Considerations'
   section of [RFC4271] for a receiving discussion of BGP peer can conceivably do
   whatever re-optimization (or failback) it wishes security.  Also refer to do (including
   nothing).

   Note that when a TLV does not include the A bit, that TLV cannot be
   used
   [RFC4272] and [RFC6952] for analysis of security issues for failover purposes. BGP.

   The A bit was intentionally omitted from
   some TLVs to help mitigate oscillations.

   Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the
   bandwidth advertisements, the delay and delay variation
   advertisements, packet loss defined introduced in this document MUST be encoded
   in the same unit as one are used to propagate IGP
   defined in IS-IS Extended IS Reachability
   sub-TLVs [ISIS-TE-METRIC].  All values (except residual bandwidth)
   MUST be obtained by a filter that is reasonably representative of an
   average or calculated as rolling averages where the averaging period
   MUST be a configurable period of time.  The measurement interval, any
   filter coefficients, information ([RFC7810] and any advertisement intervals MUST be
   configurable per sub-TLV in the same way as ones defined in section 5
   of [ISIS-TE-METRIC].

5.  Attribute TLV Details

   Link attribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls-
   distribution]are [RFC7471].)  These TLVs that may be encoded in represent
   the BGP-LS attribute
   with a link NLRI.  Each 'Link Attribute' is a Type/Length/ Value
   (TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr-
   ls-distribution].  The format state and semantics resources availability of the 'value' fields in
   'Link Attribute' IGP link.  The IGP
   instances originating these TLVs correspond are assumed to have all the format required
   security and semantics of value
   fields authentication mechanism (as described in IS-IS Extended IS Reachability sub-TLVs, defined [RFC7810] and
   [RFC7471]) in
   [RFC5305].  Although order to prevent any security issue when propagating
   the encodings for 'Link Attribute' TLVs were
   originally defined into BGP-LS.

5.  IANA Considerations

   This document requests assigning code-points from the registry "BGP-
   LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
   TLVs" for IS-IS, the new Link Attribute TLVs can carry data sourced either
   by IS-IS or OSPF.

   The following 'Link Attribute' TLVs are valid deefined in the LINK_STATE
   attribute:

   +------------+---------------------+--------------+-----------------+
   | table here
   below:

    TLV Code  | Description         |     IS-IS    | Defined in:     |
   |    Point   |                     |  TLV/Sub-TLV |                 |
   +------------+---------------------+--------------+-----------------+
   |    xxxx    | code-point                 Value
   --------------------------------------------------------
    1104 (Suggested)  Unidirectional      |    22/xx     | [ISIS-TE-       |
   |            | Link Delay          |              | METRIC]/4.1     |
   |            |                     |              |                 |
   |    xxxx    |

    1105 (Suggested)  Min/Max Unidirection|    22/xx     | [ISIS-TE-       |
   |            | Unidirectional Link Delay          |              | METRIC]/4.2     |
   |            |                     |              |                 |
   |    xxxx    |

    1106 (Suggested)  Unidirectional      |    22/xx     | [ISIS-TE-       |
   |            | Delay Variation     |              | METRIC]/4.3     |
   |            |                     |              |                 |
   |    xxxx    |

    1107 (Suggested)  Unidirectional      |    22/xx     | [ISIS-TE-       |
   |            | Link Packet Loss           |              | METRIC]/4.4     |
   |            |                     |              |                 |
   |    xxxx    |

    1108 (Suggested)  Unidirectional      |    22/xx     | [ISIS-TE-       |
   |            |Residual Residual Bandwidth   |              | METRIC]/4.5     |
   |            |                     |              |                 |
   |    xxxx    |

    1109 (Suggested)  Unidirectional      |    22/xx     | [ISIS-TE-       |
   |            |Available Available Bandwidth  |              | METRIC]/4.6     |
   |            |                     |              |                 |
   |    xxxx    |

    1110 (Suggested)  Unidirectional      |    22/xx     | [ISIS-TE-       |
   |            |Utilized Bandwidth   |              | METRIC]/4.7     |
   +------------+---------------------+--------------+-----------------+

                        Table 1: Link Attribute TLVs Utilization

6.  Manageability Considerations

   Manageability Considerations described in section 6.2 of [I-D.ietf-
   idr-ls-distribution] can be applied to Traffic Engineering (TE)
   performance Metrics as well.  Acknowledgements

   TBD

7.  Security Considerations

   This document does not introduce security issues beyond those
   discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271].

8.  IANA Considerations

   IANA maintains the registry for the TLVs.  BGP TE Performance TLV
   will require one new type code per TLV defined in this document.

9.  References

9.1.

7.1.  Normative References

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., "North-Bound Distribution of Link-State and
              TE Information using BGP", ID draft-ietf-idr-ls-
              distribution-07, November 2014.

   [I-D.ietf-pce-pcep-service-aware]
              Dhruv, D., "Extensions to the Path Computation Element
              Communication Protocol (PCEP) to compute service aware
              Label Switched Path (LSP)", ID draft-ietf-pce-pcep-
              service-aware-06, December 2014.

   [ISIS-TE-METRIC]
              Giacalone, S., "ISIS Traffic Engineering (TE) Metric
              Extensions", ID draft-ietf-isis-te-metric-extensions-04,
              October 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006.

   [RFC5305]  Li, T., 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <http://www.rfc-editor.org/info/rfc7471>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <http://www.rfc-editor.org/info/rfc7752>.

   [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
              Q. Wu, "IS-IS Extensions for Traffic Engineering", Engineering (TE) Metric Extensions",
              RFC
              5305, October 2008.

9.2. 7810, DOI 10.17487/RFC7810, May 2016,
              <http://www.rfc-editor.org/info/rfc7810>.

7.2.  Informative References

   [ALTO]     Yang, Y., "ALTO Protocol", ID
              http://tools.ietf.org/html/draft-ietf-alto-protocol-16,
              May 2013.

   [I.D-ietf-pce-hierarchy-extensions]
              Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
              and D. King, "Extensions to Path Computation Element
              Communication Protocol (PCEP) for Hierarchical Path
              Computation Elements (PCE)", ID draft-ietf-pce-hierarchy-
              extensions-01, February 2014.

   [RFC4655]  Farrel, A., "A Path Computation Element (PCE)-Based
              Architecture",

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4655, August 2006.

Appendix A.  Change Log

   Note to the RFC-Editor: please remove this section prior 4272, DOI 10.17487/RFC4272, January 2006,
              <http://www.rfc-editor.org/info/rfc4272>.

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to
   publication as an RFC.

A.1.  draft-ietf-idr-te-pm-bgp-00

   The following are the major changes compared to previous version
   draft-wu-idr-te-pm-bgp-03:

   o  Update PCE case in section 3.1.

   o  Add some texts in section 1 Keying
              and section 4 to clarify from where to
      distribute pm info and measurement interval and method.

A.2.  draft-ietf-idr-te-pm-bgp-02

   The following are the major changes compared to previous version
   draft-wu-idr-te-pm-bgp-03:

   o  Some Editorial changes. Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
              <http://www.rfc-editor.org/info/rfc6952>.

Authors' Addresses

   Stefano Previdi (editor)
   Cisco Systems, Inc.
   Via Del Serafico 200
   Rome  00191
   IT

   Email: sprevidi@cisco.com

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com

   Stefano Previdi
   Cisco Systems, Inc.
   Via Del Serafico 200
   Rome  00191
   Italy

   Email: sprevidi@cisco.com
   Hannes Gredler
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US
   Individual
   AT

   Email: hannes@juniper.net hannes@gredler.at

   Saikat Ray
   Cisco Systems, Inc.
   170, West Tasman Drive
   San Jose, CA  95134
   Individual
   US

   Email: sairay@cisco.com raysaikat@gmail.com

   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   Individual
   US

   Email: jefftant@gmail.com

   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   BE

   Email: cfilsfil@cisco.com

   Les Ginsberg
   Cisco Systems, Inc.
   US

   Email: jeff.tantsura@ericsson.com ginsberg@cisco.com