draft-ietf-pce-hierarchy-extensions-09.txt   draft-ietf-pce-hierarchy-extensions-10.txt 
PCE Working Group F. Zhang PCE Working Group F. Zhang
Internet-Draft Q. Zhao Internet-Draft Q. Zhao
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: August 7, 2019 O. Gonzalez de Dios Expires: September 5, 2019 O. Gonzalez de Dios
Telefonica I+D Telefonica I+D
R. Casellas R. Casellas
CTTC CTTC
D. King D. King
Old Dog Consulting Old Dog Consulting
February 6, 2019 March 4, 2019
Extensions to Path Computation Element Communication Protocol (PCEP) for Extensions to Path Computation Element Communication Protocol (PCEP) for
Hierarchical Path Computation Elements (PCE) Hierarchical Path Computation Elements (PCE)
draft-ietf-pce-hierarchy-extensions-09 draft-ietf-pce-hierarchy-extensions-10
Abstract Abstract
The Hierarchical Path Computation Element (H-PCE) architecture is The Hierarchical Path Computation Element (H-PCE) architecture is
defined in RFC 6805. It provides a mechanism to derive an optimum defined in RFC 6805. It provides a mechanism to derive an optimum
end-to-end path in a multi-domain environment by using a hierarchical end-to-end path in a multi-domain environment by using a hierarchical
relationship between domains to select the optimum sequence of relationship between domains to select the optimum sequence of
domains and optimum paths across those domains. domains and optimum paths across those domains.
This document defines extensions to the Path Computation Element This document defines extensions to the Path Computation Element
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 7, 2019. This Internet-Draft will expire on September 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .1
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . .5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . .5
1.3. Requirements Language . . . . . . . . . . . . . . . . . .5 1.3. Requirements Language . . . . . . . . . . . . . . . . . .5
2. Requirements for H-PCE . . . . . . . . . . . . . . . . . . .5 2. Requirements for H-PCE . . . . . . . . . . . . . . . . . . .5
2.1. Path Computation Request . . . . . . . . . . . . . . . .6 2.1. Path Computation Request . . . . . . . . . . . . . . . .6
2.1.1. Qualification of PCEP Requests . . . . . . . . . . .6 2.1.1. Qualification of PCEP Requests . . . . . . . . . . .6
2.1.2. Multi-domain Objective Functions . . . . . . . . . .6 2.1.2. Multi-domain Objective Functions . . . . . . . . . .6
2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . .7 2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . .6
2.2. Parent PCE Capability Advertisement . . . . . . . . . . .7 2.2. Parent PCE Capability Advertisement . . . . . . . . . . .7
2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7 2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7
2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7 2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .8 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .8
3.1 Applicability to PCC-PCE Communications . . . . . . . . .8 3.1 Applicability to PCC-PCE Communications . . . . . . . . .8
3.2. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8 3.2. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8
3.2.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8 3.2.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8
3.2.1.1 Backwards Compatibility . . . . . . . . . . . . . . .9 3.2.1.1 Backwards Compatibility . . . . . . . . . . . . . . .9
3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10
3.2. RP Object . . . . . . . . . . . . . . . . . . . . . . . .11 3.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . .11
3.2.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .11 3.3.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .11
3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .12 3.3.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .11
3.3. Objective Functions . . . . . . . . . . . . . . . . . . .12 3.4. Objective Functions . . . . . . . . . . . . . . . . . . .12
3.3.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .12 3.4.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .12
3.3.2. OF Object . . . . . . . . . . . . . . . . . . . . . .13 3.4.2. OF Object . . . . . . . . . . . . . . . . . . . . . .13
3.4. Metric Object . . . . . . . . . . . . . . . . . . . . . .14 3.5. Metric Object . . . . . . . . . . . . . . . . . . . . . .14
3.5. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .15 3.6. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .14
3.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .15 3.7. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .15
3.6.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .15 3.7.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .15
3.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .15 3.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .15
4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .16 4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .16
4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .16 4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .16
4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .17 4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .17
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .17 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .17
6. Manageability Considerations . . . . . . . . . . . . . . . .18 6. Manageability Considerations . . . . . . . . . . . . . . . .17
6.1. Control of Function and Policy . . . . . . . . . . . . .18 6.1. Control of Function and Policy . . . . . . . . . . . . .18
6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .19 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .18
6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .18 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .18
6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .19 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .19
6.2. Information and Data Models . . . . . . . . . . . . . . .19 6.2. Information and Data Models . . . . . . . . . . . . . . .19
6.3. Liveness Detection and Monitoring . . . . . . . . . . . .19 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .19
6.4. Verify Correct Operations . . . . . . . . . . . . . . . .19 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .19
6.5. Requirements On Other Protocols . . . . . . . . . . . . .20 6.5. Requirements On Other Protocols . . . . . . . . . . . . .20
6.6. Impact On Network Operations . . . . . . . . . . . . . .20 6.6. Impact On Network Operations . . . . . . . . . . . . . .20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .20
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .20 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .20
7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .20 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .20
7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .21 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .21
7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .21 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .21
7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .22 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .22
7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .22 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .22
7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .22 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .22
7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .23 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .23
7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .23 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .23
7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .23 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .23
8. Security Considerations . . . . . . . . . . . . . . . . . . .23 8. Security Considerations . . . . . . . . . . . . . . . . . . .23
9. Contributing Authors. . . . . . . . . . . . . . . . . . . . .24 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . .24
10. References . . . . . . . . . . . . . . . . . . . . . . . . .24 10.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .24
10.1. Normative References . . . . . . . . . . . . . . . . . .24 11. References . . . . . . . . . . . . . . . . . . . . . . . . .24
10.2. Informative References . . . . . . . . . . . . . . . . .26 11.1. Normative References . . . . . . . . . . . . . . . . . .24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .28 11.2. Informative References . . . . . . . . . . . . . . . . .25
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .27
A1. Implementation Status . . . . . . . . . . . . . . . . . . .29 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .29 A1. Implementation Status . . . . . . . . . . . . . . . . . . .28
A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .31 A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .28
A1.3. H-PCE Proof of Concept developed by Huawei . . . . . . .32 A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .30
A1.3. H-PCE Proof of Concept developed by Huawei . . . . . . .31
1. Introduction 1. Introduction
The Path Computation Element communication Protocol (PCEP) provides The Path Computation Element communication Protocol (PCEP) provides
a mechanism for Path Computation Elements (PCEs) and Path Computation a mechanism for Path Computation Elements (PCEs) and Path Computation
Clients (PCCs) to exchange requests for path computation and Clients (PCCs) to exchange requests for path computation and
responses that provide computed paths. responses that provide computed paths.
The capability to compute the routes of end-to-end inter-domain MPLS The capability to compute the routes of end-to-end inter-domain MPLS
Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs)
skipping to change at page 4, line 5 skipping to change at page 4, line 5
capability may be realized by a PCE [RFC4655]. The methods for capability may be realized by a PCE [RFC4655]. The methods for
establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are
documented in [RFC4726]. documented in [RFC4726].
[RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can
be used for computing end-to-end paths for inter-domain MPLS Traffic be used for computing end-to-end paths for inter-domain MPLS Traffic
Engineering (TE) and GMPLS Label Switched Paths (LSPs). Engineering (TE) and GMPLS Label Switched Paths (LSPs).
Within the hierarchical PCE architecture, the parent PCE is used to Within the hierarchical PCE architecture, the parent PCE is used to
compute a multi-domain path based on the domain connectivity compute a multi-domain path based on the domain connectivity
information. A child PCE may be responsible for a single domain or information. A child PCE may be responsible for single or multiple
multiple domains, it is used to compute the intra-domain path based domains and is used to compute the intra-domain path based on its
on its own domain topology information. own domain topology information.
The H-PCE end-to-end domain path computation procedure is described The H-PCE end-to-end domain path computation procedure is described
below: below:
o A path computation client (PCC) sends the inter-domain path o A path computation client (PCC) sends the inter-domain path
computation requests to the child PCE responsible for its domain; computation requests to the child PCE responsible for its domain;
o The child PCE forwards the request to the parent PCE; o The child PCE forwards the request to the parent PCE;
o The parent PCE computes the likely domain paths from the ingress o The parent PCE computes the likely domain paths from the ingress
skipping to change at page 4, line 33 skipping to change at page 4, line 33
o The child PCEs return the intra-domain paths to the parent PCE; o The child PCEs return the intra-domain paths to the parent PCE;
o The parent PCE constructs the end-to-end inter-domain path based o The parent PCE constructs the end-to-end inter-domain path based
on the intra-domain paths; on the intra-domain paths;
o The parent PCE returns the inter-domain path to the child PCE; o The parent PCE returns the inter-domain path to the child PCE;
o The child PCE forwards the inter-domain path to the PCC. o The child PCE forwards the inter-domain path to the PCC.
In addition, the parent PCE may be requested to provide only the The parent PCE may be requested to provide only the sequence of
sequence of domains to a child PCE so that alternative inter-domain domains to achild PCE so that alternative inter-domain path
path computation procedures, including Per Domain (PD) [RFC5152] and computation procedures, including Per Domain (PD) [RFC5152] and
Backwards Recursive Path Computation (BRPC) [RFC5441] may be used. Backwards Recursive Path Computation (BRPC) [RFC5441], may be used.
This document defines the PCEP extensions for the purpose of This document defines the PCEP extensions for the purpose of
implementing Hierarchical PCE procedures, which are described in implementing Hierarchical PCE procedures, which are described in
[RFC6805]. [RFC6805].
1.1. Scope 1.1. Scope
The following functions are out of scope of this document. The following functions are out of scope of this document:
o Determination of Destination Domain (section 4.5 of [RFC6805]). o Determination of Destination Domain (section 4.5 of [RFC6805]):
This could be done
* via a collection of reachability information from child domain; * via a collection of reachability information from child domain;
* via requests to the child PCEs to discover if they contain the * via requests to the child PCEs to discover if they contain the
destination node; destination node;
* or any other methods. * or any other methods.
o Parent Traffic Engineering Database (TED) methods (section 4.4 of o Parent Traffic Engineering Database (TED) methods (section 4.4 of
[RFC6805]). This could be done via [RFC6805]), suitible mechanisms include:
* Yang based management interfaces * YANG-based management interfaces;
* BGP-LS [RFC7752] * BGP-LS [RFC7752];
* Future extension to PCEP (such as PCEP-LS) * Future extension to PCEP (such as PCEP-LS).
o Learning of Domain connectivity and boundary nodes (BN) addresses. o Learning of Domain connectivity and boundary nodes (BN) addresses.
This could be done via This could be done achieved:
* Yang based management interfaces * YANG-based management interfaces;
* BGP-LS [RFC7752] * BGP-LS [RFC7752];
* Future extension to PCEP (such as PCEP-LS) * Future extension to PCEP (such as PCEP-LS).
o Stateful PCE Operations. (Refer [I-D.ietf-pce-stateful-hpce]) o Stateful PCE Operations. (Refer [I-D.ietf-pce-stateful-hpce])
The hierarchical relationship model is described in [RFC6805]. It is o The hierarchical relationship model is described in [RFC6805]. It
applicable to environments with small groups of domains where is applicable to environments with small groups of domains where
visibility from the ingress LSRs is limited. As highlighted in visibility from the ingress LSRs is limited. As highlighted in
[RFC7399] applying the hierarchical PCE model to large groups of [RFC7399] applying the hierarchical PCE model to large groups of
domains such as the Internet is not considered feasible or desirable. domains such as the Internet is not considered feasible or
desirable.
1.2. Terminology 1.2. Terminology
This document uses the terminology defined in [RFC4655], [RFC5440] This document uses the terminology defined in [RFC4655], [RFC5440]
and the additional terms defined in Section 1.4 of [RFC6805]. and the additional terms defined in Section 1.4 of [RFC6805].
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Requirements for H-PCE 2. Requirements for H-PCE
This section compiles the set of requirements to the PCEP extension This section compiles the set of requirements to the PCEP extensions
to support the H-PCE architecture and procedures. to support the H-PCE architecture and procedures.
[RFC6805] identifies high-level requirements of PCEP extensions [RFC6805] identifies high-level requirements of PCEP extensions
required to support the hierarchical PCE model. required to support the hierarchical PCE model.
2.1. Path Computation Request 2.1. Path Computation Request
The Path Computation Request (PCReq) [RFC5440] messages are used by The Path Computation Request (PCReq) [RFC5440] messages are used by
a PCC or a PCE to make a path computation request to a PCE. In order a PCC or a PCE to make a path computation request to a PCE. In order
to achieve the full functionality of the H-PCE procedures, the PCReq to achieve the full functionality of the H-PCE procedures, the PCReq
message needs to include: message needs to include:
skipping to change at page 10, line 17 skipping to change at page 10, line 9
will not be created. will not be created.
If a PCE does not support the extensions defined in this document but If a PCE does not support the extensions defined in this document but
receives them in a PCEP message (notwithstanding the fact that the receives them in a PCEP message (notwithstanding the fact that the
session was not established as supporting a H-PCE relationship), the session was not established as supporting a H-PCE relationship), the
receiving PCE will ignore the H-PCE related parameters because they receiving PCE will ignore the H-PCE related parameters because they
are all encoded in TLVs within standard PCEP objects. are all encoded in TLVs within standard PCEP objects.
3.2.2. Domain-ID TLV 3.2.2. Domain-ID TLV
The Domain-ID TLV when used in the OPEN object, identify the domains The Domain-ID TLV, when used in the OPEN object, identifies the
served by the PCE. The child PCE uses this mechanism to inform the domains served by the PCE. The child PCE uses this mechanism to
domain information to the parent PCE. inform the domain information to the parent PCE.
The Domain-ID TLV is defined below: The Domain-ID TLV is defined below:
0 1 2 3 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 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= TBD2 | Length | | Type= TBD2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | Reserved | | Domain Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 17 skipping to change at page 11, line 9
Domain ID (variable): Indicates an IGP Area ID or AS number as Domain ID (variable): Indicates an IGP Area ID or AS number as
per the Domain Type field. It can be 2 bytes, 4 bytes or variable per the Domain Type field. It can be 2 bytes, 4 bytes or variable
length depending on the domain identifier used. It is padded with length depending on the domain identifier used. It is padded with
trailing zeros to a 4-byte boundary. In case of IS-IS it includes trailing zeros to a 4-byte boundary. In case of IS-IS it includes
the Area-Len as well. the Area-Len as well.
In the case a PCE serves more than one domain, multiple Domain-ID In the case a PCE serves more than one domain, multiple Domain-ID
TLVs are included for each domain it serves. TLVs are included for each domain it serves.
3.2. RP Object 3.3. RP Object
3.2.1. H-PCE-FLAG TLV 3.3.1. H-PCE-FLAG TLV
The H-PCE-FLAG TLV is an optional TLV associated with the RP Object The H-PCE-FLAG TLV is an optional TLV associated with the RP Object
[RFC5440] to indicate the H-PCE path computation request and options. [RFC5440] to indicate the H-PCE path computation request and options.
Its format is shown in the following figure: Its format is shown in the following figure:
0 1 2 3 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 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= TBD3 | Length=4 | | Type= TBD3 | Length=4 |
skipping to change at page 12, line 6 skipping to change at page 11, line 46
D (Disallow Domain Re-entry bit): if set, will signal that the D (Disallow Domain Re-entry bit): if set, will signal that the
computed path does not enter a domain more than once. computed path does not enter a domain more than once.
Unassigned bits MUST be set to 0 on transmission and MUST be ignored Unassigned bits MUST be set to 0 on transmission and MUST be ignored
on receipt. on receipt.
The presence of the TLV indicates that the H-PCE based path The presence of the TLV indicates that the H-PCE based path
computation is requested as per this document. computation is requested as per this document.
3.2.2. Domain-ID TLV 3.3.2. Domain-ID TLV
The usage of Domain-ID TLV carried in an OPEN object is used to The usage of Domain-ID TLV, carried in an OPEN object, is used to
indicate a (list of) managed domains and is described in indicate a (list of) managed domains and is described in
Section 3.3.1. This TLV when carried in an RP object, indicates the Section 3.3.1. This TLV, when carried in an RP object, indicates the
destination domain ID. If a PCC knows the egress domain, it can destination domain ID. If a PCC knows the egress domain, it can
supply this information in the PCReq message. The format and supply this information in the PCReq message. The format and
procedure of this TLV are defined in Section 3.1.2. procedure of this TLV are defined in Section 3.2.2.
If a Domain-id TLV is used in the RP object, and the destination is If a Domain-id TLV is used in the RP object, and the destination is
not actually in the indicated domain, then the parent not actually in the indicated domain, then the parent
PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV
should be used, and a new bit number is assigned to indicate should be used. A new bit number is assigned to indicate
"Destination not found in the indicated domain" (see Section 3.7). "Destination not found in the indicated domain" (see Section 3.7).
3.3. Objective Functions 3.4. Objective Functions
3.3.1. OF Codes 3.4.1. OF Codes
[RFC5541] defines a mechanism to specify an Objective Function that [RFC5541] defines a mechanism to specify an Objective Function that
is used by a PCE when it computes a path. Three new Objective is used by a PCE when it computes a path. Three new Objective
Functions are defined for H-PCE, these are: Functions are defined for H-PCE, these are:
o MTD o MTD
* Name: Minimize the number of Transit Domains (MTD) * Name: Minimize the number of Transit Domains (MTD)
* Objective Function Code - TBD4 (to be assigned by IANA) * Objective Function Code - TBD4 (to be assigned by IANA)
skipping to change at page 13, line 24 skipping to change at page 13, line 17
+ D(Lpi) if a function that determines if the links Lpi + D(Lpi) if a function that determines if the links Lpi
and Lpi+1 belong to different domains, D(Li) = 1 if link and Lpi+1 belong to different domains, D(Li) = 1 if link
Li and Li+1 belong to different domains, D(Lk) = 0 if Li and Li+1 belong to different domains, D(Lk) = 0 if
link Lk and Lk+1 belong to the same domain. link Lk and Lk+1 belong to the same domain.
+ The number of border node in a path P is denoted by B(P), + The number of border node in a path P is denoted by B(P),
where B(P) = sum{D(Lpi),(i=1...K-1)}. where B(P) = sum{D(Lpi),(i=1...K-1)}.
+ Find a path P such that B(P) is minimized. + Find a path P such that B(P) is minimized.
There is one objective function that applies to a set of synchronized There is one objective function that applies to a set of
path computation requests to increase the domain diversity: synchronized path computation requests to increase the domain
diversity:
MCTD o MCTD
o Name: Minimize the number of Common Transit Domains * Name: Minimize the number of Common Transit Domains
o Objective Function Code - TBD13 (to be assigned by IANA) * Objective Function Code - TBD13 (to be assigned by IANA)
o Description: Find a set of paths such that it passes through the * Description: Find a set of paths such that it passes through
least number of common transit domains. the least number of common transit domains.
+ A network comprises a set of N domains {Di, (i=1...N)}. + A network comprises a set of N domains {Di, (i=1...N)}.
+ A path P passes through K unique domains {Dpi,(i=1...K)}. + A path P passes through K unique domains {Dpi,(i=1...K)}.
+ A set of paths {P1...Pm} have L transit domains that are + A set of paths {P1...Pm} have L transit domains that are
common to more than one path {Dpi,(i=1...L)}. common to more than one path {Dpi,(i=1...L)}.
+ Find a set of paths such that the value of L is minimized. + Find a set of paths such that the value of L is minimized.
3.3.2. OF Object 3.4.2. OF Object
The OF (Objective Function) object [RFC5541] is carried within a The OF (Objective Function) object [RFC5541] is carried within a
PCReq message so as to indicate the desired/required objective PCReq message so as to indicate the desired/required objective
function to be applied by the PCE during path computation. As per function to be applied by the PCE during path computation. As per
Section 3.2 of [RFC5541] a single OF object may be included in a path Section 3.2 of [RFC5541] a single OF object may be included in a path
computation request. computation request.
The new OF codes described in Section 3.3.1 are applicable at the The new OF codes described in Section 3.4.1 are applicable at the
inter-domain path computation performed by the parent PCE, it is inter-domain path computation performed by the parent PCE, it is
also necessary to specify the OF code that may be applied for the also necessary to specify the OF code that may be applied for the
intra-domain path computation performed by the child PCE. To intra-domain path computation performed by the child PCE. To
accommodate this, the OF-List TLV (described in Section 2.1. of accommodate this, the OF-List TLV (described in Section 2.1. of
[RFC5541]) is included in the OF object as an optional TLV. [RFC5541]) is included in the OF object as an optional TLV.
The OF-List TLV allows encoding of multiple OF codes. When this TLV The OF-List TLV allows encoding of multiple OF codes. When this TLV
is included inside the OF object, only the first OF-code in the is included inside the OF object, only the first OF-code in the
OF-LIST TLV is considered. The parent PCE MUST use this OF code in OF-LIST TLV is considered. The parent PCE MUST use this OF code in
the OF object when sending the intra domain path computation request the OF object when sending the intra domain path computation request
skipping to change at page 14, line 28 skipping to change at page 14, line 21
Objective Functions defined in this document, the OF Code inside the Objective Functions defined in this document, the OF Code inside the
OF List TLV MUST NOT include an H-PCE Objective Function. If this OF List TLV MUST NOT include an H-PCE Objective Function. If this
condition is not met, the PCEP speaker MUST respond with a PCErr condition is not met, the PCEP speaker MUST respond with a PCErr
message with Error-Type=10 (Reception of an invalid object) and message with Error-Type=10 (Reception of an invalid object) and
Error-Value=TBD15 (Incompatible OF codes in H-PCE). Error-Value=TBD15 (Incompatible OF codes in H-PCE).
If the Objective Functions defined in this document are unknown or If the Objective Functions defined in this document are unknown or
unsupported by a PCE, then the procedure as defined in [RFC5541] unsupported by a PCE, then the procedure as defined in [RFC5541]
is followed. is followed.
3.4. Metric Object 3.5. Metric Object
The METRIC object is defined in Section 7.8 of [RFC5440], comprising The METRIC object is defined in Section 7.8 of [RFC5440], comprising
of metric-value, metric-type (T field) and flags. This document of metric-value, metric-type (T field) and flags. This document
defines the following types for the METRIC object for H-PCE: defines the following types for the METRIC object for H-PCE:
o T=TBD6: Domain count metric (number of domains crossed); o T=TBD6: Domain count metric (number of domains crossed);
o T=TBD7: Border Node count metric (number of border nodes crossed). o T=TBD7: Border Node count metric (number of border nodes crossed).
The domain count metric type of the METRIC object encodes the number The domain count metric type of the METRIC object encodes the number
of domain crossed in the path. The border node count metric type of of domains crossed in the path. The border node count metric type of
the METRIC object encodes the number of border nodes in the path. If the METRIC object encodes the number of border nodes in the path. If
a domain is re-entered, then domain should be double counted. a domain is re-entered, then domain should be double counted.
A PCC or child PCE MAY use these metric in PCReq message for an A PCC or child PCE MAY use the metric in a PCReq message for an
inter-domain path computation meeting the number of domain or border inter-domain path computation, meeting the number of domain or border
nodes crossing requirement. As per [RFC5440], in this case, the B bit nodes crossing requirement. As per [RFC5440], in this case, the B bit
is set to suggest a bound (a maximum) for the metric that must not be is set to suggest a bound (a maximum) for the metric that must not be
exceeded for the PCC to consider the computed path as acceptable. exceeded for the PCC to consider the computed path as acceptable.
A PCC or child PCE MAY also use this metric to ask the PCE to A PCC or child PCE MAY also use this metric to ask the PCE to
optimize the metric during inter-domain path computation. In this optimize the metric during inter-domain path computation. In this
case, the B flag is cleared, and the C flag is set. case, the B flag is cleared, and the C flag is set.
The Parent PCE MAY use these metric in a PCRep message along with a The Parent PCE MAY use the metric in a PCRep message along with a
NO-PATH object in the case where the PCE cannot compute a path NO-PATH object in the case where the PCE cannot compute a path
meeting this constraint. A PCE MAY also use this metric to send the meeting this constraint. A PCE MAY also use this metric to send the
computed end to end metric value in a reply message. computed end to end metric value in a reply message.
3.5. SVEC Object 3.6. SVEC Object
[RFC5440] defines SVEC object which includes flags for the potential [RFC5440] defines SVEC object which includes flags for the potential
dependency between the set of path computation requests (Link, Node dependency between the set of path computation requests (Link, Node
and SRLG diverse). This document defines a new flag O for domain and SRLG diverse). This document defines a new flag O for domain
diversity. diversity.
The following new bit is added to the Flags field: The following new bit is added to the Flags field:
o O (Domain diverse) bit - TBD14 : when set, this indicates that the o O (Domain diverse) bit - TBD14 : when set, this indicates that the
computed paths corresponding to the requests specified by the computed paths corresponding to the requests specified by the
skipping to change at page 15, line 32 skipping to change at page 15, line 25
common. common.
The Domain Diverse O-bit can be used in Hierarchical PCE path The Domain Diverse O-bit can be used in Hierarchical PCE path
computation to compute synchronized domain diverse end to end path or computation to compute synchronized domain diverse end to end path or
diverse domain sequences. diverse domain sequences.
When domain diverse O bit is set, it is applied to the transit When domain diverse O bit is set, it is applied to the transit
domains. The other bit in SVEC object (N, L, S etc.) MAY be set and domains. The other bit in SVEC object (N, L, S etc.) MAY be set and
MUST still be applied in the ingress and egress shared domain. MUST still be applied in the ingress and egress shared domain.
3.6. PCEP-ERROR Object 3.7. PCEP-ERROR Object
3.6.1. Hierarchy PCE Error-Type 3.7.1. Hierarchy PCE Error-Type
A new PCEP Error-Type [RFC5440] is used for the H-PCE extension as A new PCEP Error-Type [RFC5440] is used for the H-PCE extension as
defined below: defined below:
+------------+-----------------------------------------+ +------------+-----------------------------------------+
| Error-Type | Meaning | | Error-Type | Meaning |
+------------+-----------------------------------------+ +------------+-----------------------------------------+
| TBD8 | H-PCE error | | TBD8 | H-PCE error |
| | Error-value=1: H-PCE capability | | | Error-value=1: H-PCE capability |
| | was not advertised | | | was not advertised |
| | Error-value=2: parent PCE capability | | | Error-value=2: parent PCE capability |
| | cannot be provided | | | cannot be provided |
+------------+-----------------------------------------+ +------------+-----------------------------------------+
Figure 4: H-PCE error Figure 4: H-PCE error
3.7. NO-PATH Object 3.8. NO-PATH Object
To communicate the reason(s) for not being able to find a multi- To communicate the reason(s) for not being able to find a multi-
domain path or domain sequence, the NO-PATH object can be used in the domain path or domain sequence, the NO-PATH object can be used in the
PCRep message. [RFC5440] defines the format of the NO-PATH object. PCRep message. [RFC5440] defines the format of the NO-PATH object.
The object may contain a NO-PATH-VECTOR TLV to provide additional The object may contain a NO-PATH-VECTOR TLV to provide additional
information about why a path computation has failed. information about why a path computation has failed.
Three new bit flags are defined to be carried in the Flags field in Three new bit flags are defined to be carried in the Flags field in
the NO-PATH-VECTOR TLV carried in the NO-PATH Object. the NO-PATH-VECTOR TLV carried in the NO-PATH Object.
o Bit number TBD9: When set, the parent PCE indicates that o Bit number TBD9: When set, the parent PCE indicates that
skipping to change at page 16, line 36 skipping to change at page 16, line 29
The H-PCE path computation procedure is described in [RFC6805]. The H-PCE path computation procedure is described in [RFC6805].
4.1. OPEN Procedure between Child PCE and Parent PCE 4.1. OPEN Procedure between Child PCE and Parent PCE
If a child PCE wants to use the peer PCE as a parent, it MUST set the If a child PCE wants to use the peer PCE as a parent, it MUST set the
P (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the P (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the
OPEN object carried in the Open message during the PCEP session OPEN object carried in the Open message during the PCEP session
initialization procedure. initialization procedure.
The child PCE MAY also report its list of domain IDs to the parent The child PCE MAY also report its list of domain IDs, to the parent
PCE by specifying them in the Domain-ID TLVs in the OPEN object PCE, by specifying them in the Domain-ID TLVs in the OPEN object.
carried in the Open message during the PCEP session initialization This object is carried in the OPEN message during the PCEP session
procedure. initialization procedure
The OF codes defined in this document can be carried in the OF-list The OF codes defined in this document can be carried in the OF-list
TLV of the OPEN object. If the OF-list TLV carries the OF codes, it TLV of the OPEN object. If the OF-list TLV carries the OF codes, it
means that the PCE is capable of implementing the corresponding means that the PCE is capable of implementing the corresponding
objective functions. This information can be used for selecting a objective functions. This information can be used for selecting a
proper parent PCE when a child PCE wants to get a path that satisfies proper parent PCE when a child PCE wants to get a path that satisfies
a certain Objective Function. a certain Objective Function.
When a specific child PCE sends a PCReq to a peer PCE that requires When a child PCE sends a PCReq to a peer PCE, which requires parental
parental activity and H-PCE capability flags TLV was not included in activity and H-PCE capability flags TLV but which were not included
the session establishment procedure as described above, the peer PCE in the session establishment procedure described above, the peer PCE
should send a PCErr message to the child PCE and specify the error- should send a PCErr message to the child PCE and should specify the
type=TBD8 (H-PCE error) and error-value=1 (H-PCE capability was error-type=TBD8 (H-PCE error) and error-value=1 (H-PCE capability was
not advertised) in the PCEP-ERROR object. not advertised) in the PCEP-ERROR object.
When a specific child PCE sends a PCReq to a peer PCE that requires When a specific child PCE sends a PCReq to a peer PCE, that requires
parental activity and the peer PCE does not want to act as the parent parental activity and the peer PCE does not want to act as the parent
for it, the peer PCE should send a PCErr message to the child PCE and for it, the peer PCE should send a PCErr message to the child PCE and
specify the error-type=TBD8 (H-PCE error) and error-value=2 (Parent specify the error-type=TBD8 (H-PCE error) and error-value=2 (Parent
PCE capability cannot be provided) in the PCEP-ERROR object. PCE capability cannot be provided) in the PCEP-ERROR object.
4.2. Procedure to Obtain Domain Sequence 4.2. Procedure to Obtain Domain Sequence
If a child PCE only wants to get the domain sequence for a multi- If a child PCE only wants to get the domain sequence for a multi-
domain path computation from a parent PCE, it can set the Domain Path domain path computation from a parent PCE, it can set the Domain Path
Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq
message. The parent PCE which receives the PCReq message tries to message. The parent PCE which receives the PCReq message tries to
compute a domain sequence for it (instead of the E2E path). If the compute a domain sequence for it (instead of the E2E path). If the
domain path computation succeeds the parent PCE sends a PCRep message domain path computation succeeds the parent PCE sends a PCRep message
which carries the domain sequence in the ERO to the child PCE. Refer which carries the domain sequence in the Explicit Route Object (ERO)
[RFC7897] for more details about domain sub-objects in the ERO. to the child PCE. Refer to [RFC7897] for more details about domain
Otherwise, it sends a PCReq message which carries the NO-PATH object sub-objects in the ERO. Otherwise, it sends a PCReq message which
to the child PCE. carries the NO-PATH object to the child PCE.
5. Error Handling 5. Error Handling
A PCE that is capable of acting as a parent PCE might not be A PCE that is capable of acting as a parent PCE might not be
configured or willing to act as the parent for a specific child PCE. configured or willing to act as the parent for a specific child PCE.
This fact could be determined when the child sends a PCReq that This fact could be determined when the child sends a PCReq that
requires parental activity, and could result in a negative response requires parental activity, and could result in a negative response
in a PCEP Error (PCErr) message and indicate the hierarchy PCE error- in a PCEP Error (PCErr) message and indicate the hierarchy PCE error-
type=TBD8 (H-PCE error) and suitable error-value. (Section 3.6) type=TBD8 (H-PCE error) and suitable error-value. (Section 3.7)
Additionally, the parent PCE may fail to find the multi-domain path Additionally, the parent PCE may fail to find the multi-domain path
or domain sequence due to one or more of the following reasons: or domain sequence due to one or more of the following reasons:
o A child PCE cannot find a suitable path to the egress; o A child PCE cannot find a suitable path to the egress;
o The parent PCE do not hear from a child PCE for a specified time; o The parent PCE does not hear from a child PCE for a specified
time;
o The Objective Functions specified in the path request cannot be o The Objective Functions specified in the path request cannot be
met. met.
In this case, the parent PCE MAY need to send a negative path In this case, the parent PCE MAY need to send a negative path
computation reply specifying the reason. This can be achieved by computation reply specifying the reason. This can be achieved by
including NO-PATH object in the PCRep message. Extension to NO-PATH including NO-PATH object in the PCRep message. Extension to NO-PATH
object is needed to include the aforementioned reasons described in object is needed to include the aforementioned reasons described in
Section 3.7. Section 3.7.
skipping to change at page 22, line 4 skipping to change at page 21, line 48
This document requests that a new sub-registry, named "H-PCE-FLAGS This document requests that a new sub-registry, named "H-PCE-FLAGS
TLV Flag Field", is created within the "Path Computation Element TLV Flag Field", is created within the "Path Computation Element
Protocol (PCEP) Numbers" registry to manage the Flag field in the H- Protocol (PCEP) Numbers" registry to manage the Flag field in the H-
PCE-FLAGS TLV of the PCEP RP object. New values are to be assigned PCE-FLAGS TLV of the PCEP RP object. New values are to be assigned
by Standards Action [RFC8126]. Each bit should be tracked with the by Standards Action [RFC8126]. Each bit should be tracked with the
following qualities: following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC
o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
----------------------------------------------- -----------------------------------------------
31 S (Domain This I.D. 31 S (Domain This I.D.
Sequence bit) Sequence bit)
30 D (Disallow Domain This I.D. 30 D (Disallow Domain This I.D.
Re-entry bit) Re-entry bit)
7.5. OF Codes 7.5. OF Codes
skipping to change at page 24, line 36 skipping to change at page 24, line 35
EMail: zhang.xian@huawei.com EMail: zhang.xian@huawei.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
10. References 10.Acknowledgements
10.1. Normative References The authors would like to thank Mike McBride for his detailed review,
comments and suggestions which helped improve this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
skipping to change at page 26, line ? skipping to change at page 25, line 20
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009, DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>. <https://www.rfc-editor.org/info/rfc5541>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 11.2. Informative References
[RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed.,
"Requirements for Inter-Area MPLS Traffic Engineering", "Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, DOI 10.17487/RFC4105, June 2005, RFC 4105, DOI 10.17487/RFC4105, June 2005,
<https://www.rfc-editor.org/info/rfc4105>. <https://www.rfc-editor.org/info/rfc4105>.
[RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, DOI 10.17487/RFC4216, November 2005, RFC 4216, DOI 10.17487/RFC4216, November 2005,
<https://www.rfc-editor.org/info/rfc4216>. <https://www.rfc-editor.org/info/rfc4216>.
 End of changes. 61 change blocks. 
104 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/