< draft-ietf-pce-inter-area-as-applicability-07.txt   draft-ietf-pce-inter-area-as-applicability-08.txt >
PCE Working Group D. King PCE Working Group D. King
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Intended status: Informational H. Zheng Intended status: Informational H. Zheng
Expires: June 14, 2019 Huawei Technologies Expires: January 9, 2020 Huawei Technologies
December 13, 2018 July 8, 2019
Applicability of the Path Computation Element to Inter-Area and Applicability of the Path Computation Element to Inter-Area and
Inter-AS MPLS and GMPLS Traffic Engineering Inter-AS MPLS and GMPLS Traffic Engineering
draft-ietf-pce-inter-area-as-applicability-07 draft-ietf-pce-inter-area-as-applicability-08
Abstract Abstract
The Path Computation Element (PCE) may be used for computing services The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-AS Multiprotocol Label Switching that traverse multi-area and multi-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.
This document examines the applicability of the PCE architecture, This document examines the applicability of the PCE architecture,
protocols, and protocol extensions for computing multi-area and protocols, and protocol extensions for computing multi-area and
multi-AS paths in MPLS and GMPLS networks. multi-AS paths in MPLS and GMPLS networks.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 June 14, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
1. Introduction.................................................3 1. Introduction.................................................3
1.1. Domains.................................................4 1.1. Domains.................................................4
1.2. Path Computation........................................4 1.2. Path Computation........................................4
1.2.1 PCE-based Path Computation Procedure.................5 1.2.1 PCE-based Path Computation Procedure.................5
1.3. Traffic Engineering Aggregation and Abstraction.........6 1.3. Traffic Engineering Aggregation and Abstraction.........6
1.4. Traffic Engineered Label Switched Paths.................6 1.4. Traffic Engineered Label Switched Paths.................6
1.5. Inter-area and Inter-AS Capable PCE Discovery...........6 1.5. Inter-area and Inter-AS Capable PCE Discovery...........6
1.6. Objective Functions.....................................6 1.6. Objective Functions.....................................6
2. Terminology..................................................7 2. Terminology..................................................7
3. Issues and Considerations....................................7 3. Issues and Considerations....................................7
3.1 Multi-homing.............................................7 3.1 Multi-homing.............................................7
3.2 Domain Confidentiality ..................................4 3.2 Destination Location.....................................8
3.3 Destination Location.....................................4 3.3 Domain Confidentiality ..................................8
4. Domain Topologies............................................4 4. Domain Topologies............................................8
4.1 Selecting Domain Paths...................................4 4.1 Selecting Domain Paths...................................8
4.2 Domain Sizes.............................................9 4.2 Domain Sizes.............................................9
4.3 Domain Diversity.........................................9 4.3 Domain Diversity.........................................9
4.4 Synchronized Path Computations...........................9 4.4 Synchronized Path Computations...........................9
4.5 Domain Inclusion or Exclusion............................9 4.5 Domain Inclusion or Exclusion............................9
5. Applicability of the PCE to Inter-area Traffic Engineering...10 5. Applicability of the PCE to Inter-area Traffic Engineering...10
5.1. Inter-area Routing......................................11 5.1. Inter-area Routing......................................11
5.1.1. Area Inclusion and Exclusion..........................11 5.1.1. Area Inclusion and Exclusion..........................11
5.1.2. Strict Explicit Path and Loose Path...................11 5.1.2. Strict Explicit Path and Loose Path...................11
5.1.3. Inter-Area Diverse Path Computation...................11 5.1.3. Inter-Area Diverse Path Computation...................11
6. Applicability of the PCE to Inter-AS Traffic Engineering.....12 6. Applicability of the PCE to Inter-AS Traffic Engineering.....12
skipping to change at page 3, line 6 skipping to change at page 3, line 6
7.2 Pre-Planning and Management-Based Solutions..............14 7.2 Pre-Planning and Management-Based Solutions..............14
8. Domain Confidentiality.......................................15 8. Domain Confidentiality.......................................15
8.1 Loose Hops...............................................15 8.1 Loose Hops...............................................15
8.2 Confidential Path Segments and Path Keys.................15 8.2 Confidential Path Segments and Path Keys.................15
9. Point-to-Multipoint..........................................16 9. Point-to-Multipoint..........................................16
10. Optical Domains.............................................16 10. Optical Domains.............................................16
10.1 Abstraction and Control of TE Networks (ACTN)...........17 10.1 Abstraction and Control of TE Networks (ACTN)...........17
11. Policy......................................................17 11. Policy......................................................17
12. Manageability Considerations................................18 12. Manageability Considerations................................18
12.1 Control of Function and Policy...........................18 12.1 Control of Function and Policy...........................18
12.2 Information and Data Models..............................19 12.2 Information and Data Models..............................18
12.3 Liveness Detection and Monitoring........................19 12.3 Liveness Detection and Monitoring........................19
12.4 Verifying Correct Operation..............................19 12.4 Verifying Correct Operation..............................19
12.5 Impact on Network Operation..............................19 12.5 Impact on Network Operation..............................19
13. Security Considerations.....................................19 13. Security Considerations.....................................19
14. IANA Considerations.........................................19 13.1 Multi-domain Security....................................19
15. Acknowledgements............................................19 14. IANA Considerations.........................................20
15. Acknowledgements............................................20
16. References..................................................20 16. References..................................................20
16.1. Normative References....................................20 16.1. Normative References....................................20
16.2. Informative References..................................20 16.2. Informative References..................................21
17. Contributors................................................23 17. Contributors................................................24
18. Author's Addresses..........................................24 18. Author's Addresses..........................................25
1. Introduction 1. Introduction
Computing paths across large multi-domain environments may Computing paths across large multi-domain environments may
require special computational components and cooperation between require special computational components and cooperation between
entities in different domains capable of complex path computation. A entities in different domains capable of complex path computation.
number of issues exist for routing in multi-domain networks, these
include: Issues that may exist when routing in multi-domain networks include:
o Often there is a lack of full topology and TE information across o Often there is a lack of full topology and TE information across
domains; domains;
o No single node has the full visibility to determine an optimal or o No single node has the full visibility to determine an optimal or
even feasible end-to-end path across domains; even feasible end-to-end path across domains;
o How to evaluate and select the exit point and next domain boundary o How to evaluate and select the exit point and next domain boundary
from a domain? from a domain?
o How might the ingress node determine which domains should be used o How might the ingress node determine which domains should be used
for the end-to-end path? for the end-to-end path?
skipping to change at page 4, line 25 skipping to change at page 4, line 26
This document describes the processes and procedures available when This document describes the processes and procedures available when
using the PCE architecture and protocols, for computing inter-area using the PCE architecture and protocols, for computing inter-area
and inter-AS MPLS and GMPLS Traffic Engineered paths. and inter-AS MPLS and GMPLS Traffic Engineered paths.
This document scope does not include discussion on stateful PCE, This document scope does not include discussion on stateful PCE,
active PCE, remotely initiated PCE, or PCE as a central controller active PCE, remotely initiated PCE, or PCE as a central controller
(PCECC) deployment scenarios. (PCECC) deployment scenarios.
1.1 Domains 1.1 Domains
A domain can be defined as a separate administrative, geographic, or Generally, a domain can be defined as a separate administrative,
switching environment within the network. A domain may be further geographic, or switching environment within the network. A domain
defined as a zone of routing or computational ability. Under these may be further defined as a zone of routing or computational ability.
definitions a domain might be categorized as an Antonymous System Under these definitions a domain might be categorized as an
(AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726] Autonomous System (AS) or an Interior Gateway Protocol (IGP) area
and [RFC4655]). (as per [RFC4726] and [RFC4655]).
For the purposes of this document, a domain is considered to be a For the purposes of this document, a domain is considered to be a
collection of network elements within an area or AS that has a collection of network elements within an area or AS that has a
common sphere of address management or path computational common sphere of address management or path computational
responsibility. Wholly or partially overlapping domains are not responsibility. Wholly or partially overlapping domains are not
within the scope of this document. within the scope of this document.
In the context of GMPLS, a particularly important example of a domain In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork is the Automatically Switched Optical Network (ASON) subnetwork
[G-8080]. In this case, computation of an end-to-end path requires [G-8080]. In this case, computation of an end-to-end path requires
skipping to change at page 5, line 6 skipping to change at page 5, line 6
nodes may, in fact, be subnetworks. Furthermore, a domain might be an nodes may, in fact, be subnetworks. Furthermore, a domain might be an
ASON routing area [G-7715]. A PCE may perform the path computation ASON routing area [G-7715]. A PCE may perform the path computation
function of an ASON routing controller as described in [G-7715-2]. function of an ASON routing controller as described in [G-7715-2].
It is assumed that the PCE architecture is not applied to a large It is assumed that the PCE architecture is not applied to a large
group of domains, such as the Internet. group of domains, such as the Internet.
1.2 Path Computation 1.2 Path Computation
For the purpose of this document, it is assumed that the For the purpose of this document, it is assumed that the
path computation is the sole responsibility of the PCE as per the path computation is the sole responsibility of the PCE as per the
architecture defined in [RFC4655]. When a path has required the Path architecture defined in [RFC4655]. When a path is required the Path
Computation Client (PCC) will send a request to the PCE. The PCE Computation Client (PCC) will send a request to the PCE. The PCE
will apply the required constraints and compute a path and return a will apply the required constraints and compute a path and return a
response to the PCC. In the context of this document it may be response to the PCC. In the context of this document it may be
necessary for the PCE to co-operate with other PCEs in adjacent necessary for the PCE to co-operate with other PCEs in adjacent
domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE
(as per [RFC6805]). (as per [RFC6805]).
It is entirely feasible that an operator could compute a path across It is entirely feasible that an operator could compute a path across
multiple domains without the use of a PCE if the relevant domain multiple domains without the use of a PCE if the relevant domain
information is available to the network planner or network management information is available to the network planner or network management
skipping to change at page 8, line 9 skipping to change at page 8, line 9
Gateway Protocol (IGP) extensions or potentially by other means. Gateway Protocol (IGP) extensions or potentially by other means.
3. Issues and Considerations 3. Issues and Considerations
3.1 Multi-homing 3.1 Multi-homing
Networks constructed from multi-areas or multi-AS environments Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid computations may need to use different interconnect points to avoid
a single point failure disrupting both primary and backup services. a single point failure disrupting both primary and backup services.
3.2 Domain Confidentiality 3.2 Destination Location
The PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. If the PCC is aware
of the destination domain, it may supply the destination domain
information as part of the path computation request. However, if the
PCC does not know the destination domain this information must be
determined by another method.
3.3 Domain Confidentiality
Where the end-to-end path crosses multiple domains, it may be Where the end-to-end path crosses multiple domains, it may be
possible that each domain (AS or area) are administered by separate possible that each domain (AS or area) are administered by separate
Service Providers, it would break confidentiality rules for a PCE Service Providers, it would break confidentiality rules for a PCE
to supply a path segment to a PCE in another domain, thus disclosing to supply a path segment to a PCE in another domain, thus disclosing
AS-internal topology information. AS-internal topology information.
If confidentiality is required between domains (ASes and areas) If confidentiality is required between domains (ASes and areas)
belonging to different Service Providers, then cooperating PCEs belonging to different Service Providers, then cooperating PCEs
cannot exchange path segments or else the receiving PCE or PCC will cannot exchange path segments or else the receiving PCE or PCC will
be able to see the individual hops through another domain. be able to see the individual hops through another domain.
3.3 Destination Location This topic is discussed further in Section 8 of this document.
The PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. If the PCC is aware
of the destination domain, it may supply the destination domain
information as part of the path computation request. However, if the
PCC does not know the destination domain this information must be
determined by another method.
4. Domain Topologies 4. Domain Topologies
Constraint-based inter-domain path computation is a fundamental Constraint-based inter-domain path computation is a fundamental
requirement for operating traffic engineered MPLS [RFC3209] and requirement for operating traffic engineered MPLS [RFC3209] and
GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain) GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain)
environments. Path computation across multi-domain networks is environments. Path computation across multi-domain networks is
complex and requires computational co-operational entities like the complex and requires computational co-operational entities like the
PCE. PCE.
skipping to change at page 9, line 16 skipping to change at page 9, line 18
end-to-end path will have to navigate a mesh of small domains end-to-end path will have to navigate a mesh of small domains
(especially typical in optical networks), the optimum path may be (especially typical in optical networks), the optimum path may be
derived through the application of a Hierarchical PCE [RFC6805]. derived through the application of a Hierarchical PCE [RFC6805].
4.2 Domain Sizes 4.2 Domain Sizes
Very frequently network domains are composed of dozens or hundreds of Very frequently network domains are composed of dozens or hundreds of
network elements. These network elements are usually interconnected network elements. These network elements are usually interconnected
in a partial-mesh fashion, to provide survivability against dual in a partial-mesh fashion, to provide survivability against dual
failures, and to benefit from the traffic engineering capabilities failures, and to benefit from the traffic engineering capabilities
from MPLS and GMPLS protocols. The node degree (the number of from MPLS and GMPLS protocols. Network operator feedback in the
neighbors per node) typically ranges from 3 to 10 (4-5 is quite development of the document highlighted that node degree (the number
of neighbors per node) typically ranges from 3 to 10 (4-5 is quite
common). common).
4.3 Domain Diversity 4.3 Domain Diversity
Domain and path diversity may also be required when computing Domain and path diversity may also be required when computing
end-to-end paths. Domain diversity should facilitate the selection end-to-end paths. Domain diversity should facilitate the selection
of paths that share ingress and egress domains, but do not share of paths that share ingress and egress domains, but do not share
transit domains. Therefore, there must be a method allowing the transit domains. Therefore, there must be a method allowing the
inclusion or exclusion of specific domains when computing end-to-end inclusion or exclusion of specific domains when computing end-to-end
paths. paths.
skipping to change at page 10, line 13 skipping to change at page 10, line 17
specific domains to be included or excluded in the domain sequence specific domains to be included or excluded in the domain sequence
using the Include Route Object (IRO) [RFC5440] and Exclude Route using the Include Route Object (IRO) [RFC5440] and Exclude Route
Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an
abstract node representing a domain is defined in [RFC3209]. abstract node representing a domain is defined in [RFC3209].
[RFC7897] specifies new sub-objects to include or exclude domains [RFC7897] specifies new sub-objects to include or exclude domains
such as an IGP area or a 4-Byte AS number. such as an IGP area or a 4-Byte AS number.
An operator may also need to avoid a path that uses specified nodes An operator may also need to avoid a path that uses specified nodes
for administrative reasons, or if a specific connectivity for administrative reasons, or if a specific connectivity
service required to have a 1+1 protection capability, two service required to have a 1+1 protection capability, two
completely disjoint paths must be established, Shared Risk Link completely disjoint paths must be established. A mechanism known as
Group (SRLG) information may be provided to ensure path diversity. Shared Risk Link Group (SRLG) information may be used to ensure
path diversity.
5. Applicability of the PCE to Inter-area Traffic Engineering 5. Applicability of the PCE to Inter-area Traffic Engineering
As networks increase in size and complexity, it may be required to As networks increase in size and complexity, it may be required to
introduce scaling methods to reduce the amount of information introduce scaling methods to reduce the amount of information
flooded within the network and make the network more manageable. An flooded within the network and make the network more manageable. An
IGP hierarchy is designed to improve IGP scalability by dividing the IGP hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of information to within area boundaries. This restricts visibility of
the area to routers in a single area. If a router needs to compute the area to routers in a single area. If a router needs to compute
skipping to change at page 10, line 42 skipping to change at page 10, line 47
other relevant information) is limited to the area boundaries. other relevant information) is limited to the area boundaries.
Per-domain path computation [RFC5152] exists to provide a method of Per-domain path computation [RFC5152] exists to provide a method of
inter-area path computation. The per-domain solution is based on inter-area path computation. The per-domain solution is based on
loose hop routing with an Explicit Route Object (ERO) expansion on loose hop routing with an Explicit Route Object (ERO) expansion on
each Area Border Router (ABR). This allows an LSP to be established each Area Border Router (ABR). This allows an LSP to be established
using a constrained path, however at least two issues exist: using a constrained path, however at least two issues exist:
o This method does not guarantee an optimal constrained path. o This method does not guarantee an optimal constrained path.
o The method may require several crankback signaling messages o The method may require several crankback signaling messages, as per
increasing signaling traffic and delaying the LSP setup. [RFC4920], increasing signaling traffic and delaying the LSP setup.
The PCE-based architecture [RFC4655] is designed to solve inter-area The PCE-based architecture [RFC4655] is designed to solve inter-area
path computation problems. The issue of limited topology visibility path computation problems. The issue of limited topology visibility
is resolved by introducing path computation entities that are able to is resolved by introducing path computation entities that are able to
cooperate in order to establish LSPs with source and destinations cooperate in order to establish LSPs with source and destinations
located in different areas. located in different areas.
5.1. Inter-area Routing 5.1. Inter-area Routing
An inter-area TE-LSP is an LSP that transits through at least two An inter-area TE-LSP is an LSP that transits through at least two
skipping to change at page 11, line 25 skipping to change at page 11, line 29
The BRPC method [RFC5441] of path computation provides a more optimal The BRPC method [RFC5441] of path computation provides a more optimal
method to specify inclusion or exclusion of an ABR. Using the BRPC method to specify inclusion or exclusion of an ABR. Using the BRPC
procedure an end-to-end path is recursively computed in reverse from procedure an end-to-end path is recursively computed in reverse from
the destination domain, towards the source domain. Using this method, the destination domain, towards the source domain. Using this method,
an operator might decide if an area must be included or excluded from an operator might decide if an area must be included or excluded from
the inter-area path computation. the inter-area path computation.
5.1.2. Strict Explicit Path and Loose Path 5.1.2. Strict Explicit Path and Loose Path
A strict explicit Path is defined as a set of strict hops, while a A strict explicit Path is defined as a set of strict hops, while a
loose path is defined as a set of at least one loose hop and zero, loose path is defined as a set of at least one loose hop and zero or
one or more strict hops. It may be useful to indicate, during the more strict hops. It may be useful to indicate, during the
path computation request, if a strict explicit path is required or path computation request, if a strict explicit path is required or
not. An inter-area path may be strictly explicit or loose (e.g., a not. An inter-area path may be strictly explicit or loose (e.g., a
list of ABRs as loose hops). list of ABRs as loose hops).
A PCC request to a PCE does allow the indication of whether a strict A PCC request to a PCE does allow the indication of whether a strict
explicit path across specific areas ([RFC7897]) is required or explicit path across specific areas ([RFC7897]) is required or
desired, or if the path request is loose. desired, or if the path request is loose.
5.1.3. Inter-Area Diverse Path Computation 5.1.3. Inter-Area Diverse Path Computation
It may be necessary (for protection or load-balancing) to compute It may be necessary to compute a path that is partially or entirely
a path that is partially or entirely diverse, from a previously diverse, from a previously computed path, to avoid fate sharing of
computed path. There are various levels of diversity in the context a primary service with a corresponding backup service. There are
of an inter-area network: various levels of diversity in the context of an inter-area network:
o Per-area diversity (intra-area path segments are link, node or o Per-area diversity (intra-area path segments are link, node or
SRLG disjoint. SRLG disjoint.
o Inter-area diversity (end-to-end inter-area paths are link, o Inter-area diversity (end-to-end inter-area paths are link,
node or SRLG disjoint). node or SRLG disjoint).
Note that two paths may be disjoint in the backbone area but non- Note that two paths may be disjoint in the backbone area but non-
disjoint in peripheral areas. Also, two paths may be node disjoint disjoint in peripheral areas. Also, two paths may be node disjoint
within areas but may share ABRs, in which case path segments within within areas but may share ABRs, in which case path segments within
skipping to change at page 14, line 37 skipping to change at page 14, line 41
topology and link status between child domains. This information may topology and link status between child domains. This information may
be learnt by a BGP-LS speaker and provided to the parent PCE, be learnt by a BGP-LS speaker and provided to the parent PCE,
furthermore link-state performance including delay, available furthermore link-state performance including delay, available
bandwidth and utilized bandwidth may also be provided to the parent bandwidth and utilized bandwidth may also be provided to the parent
PCE for optimal path link selection. PCE for optimal path link selection.
7.2 Pre-Planning and Management-Based Solutions 7.2 Pre-Planning and Management-Based Solutions
Offline path computation is performed ahead of time, before the LSP Offline path computation is performed ahead of time, before the LSP
setup is requested. That means that it is requested by, or performed setup is requested. That means that it is requested by, or performed
as part of, an OSS management application. This model can be seen as part of, an Operation Support System (OSS) management application.
in Section 5.5 of [RFC4655]. This model can be seen in Section 5.5 of [RFC4655].
The offline model is particularly appropriate to long-lived LSPs The offline model is particularly appropriate to long-lived LSPs
(such as those present in a transport network) or for planned (such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning. normally a feature of LSP provisioning.
The management system may also use a PCE and BRPC to pre-plan an AS The management system may also use a PCE and BRPC to pre-plan an AS
sequence, and the source domain PCE and per-domain path sequence, and the source domain PCE and per-domain path
computation to be used when the actual end-to-end path is computation to be used when the actual end-to-end path is
required. This model may also be used where the operator required. This model may also be used where the operator
skipping to change at page 19, line 31 skipping to change at page 19, line 38
12.5 Impact on Network Operation 12.5 Impact on Network Operation
[RFC5440] states that in order to avoid any unacceptable impact on [RFC5440] states that in order to avoid any unacceptable impact on
network operations, a PCEP implementation should allow a limit to be network operations, a PCEP implementation should allow a limit to be
placed on the number of sessions that can be set up on a PCEP placed on the number of sessions that can be set up on a PCEP
speaker, it may also be practical to place a limit on the rate speaker, it may also be practical to place a limit on the rate
of messages sent by a PCC and received my the PCE. of messages sent by a PCC and received my the PCE.
13. Security Considerations 13. Security Considerations
PCEP security is defined [RFC5440]. Any multi-domain operation PCEP Security considerations are discussed in [RFC5440] and [RFC6952]
necessarily involves the exchange of information across domain Potential vulnerabilities include spoofing, snooping, falsification
boundaries. This does represent significant security and and using PCEP as a mechanism for denial of service attacks.
confidentiality risk. PCEP allows individual PCEs to maintain
confidentiality of their domain path information using path-keys
As PCEP operates over TCP, it may also make use of TCP security As PCEP operates over TCP, it may make use of TCP security
mechanisms, such as Transport Layer Security (TLS) and TCP encryption mechanisms, such as Transport Layer Security (TLS) and TCP
Authentication Option (TCP-AO). Usage of these security mechanisms Authentication Option (TCP-AO). Usage of these security mechanisms
for PCEP is described in [RFC8253]. for PCEP is described in [RFC8253], and recommendations and best
current practices in [RFC7525].
For further considerations of the security issues related to PCEP 13.1 Multi-domain Security
and to inter-domain path computation, see [RFC6952] and [RFC5376].
Any multi-domain operation necessarily involves the exchange of
information across domain boundaries. This does represent
significant security and confidentiality risk.
It is expected that PCEP is used between PCCs and PCEs belonging to
the same administrative authority, and using one of the
aforementioned encryption mechanisms. Furthermore, PCEP allows
individual PCEs to maintain confidentiality of their domain path
information using path-keys.
14. IANA Considerations 14. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
15. Acknowledgements 15. Acknowledgements
The author would like to thank Adrian Farrel for his review, and The author would like to thank Adrian Farrel for his review, and
Meral Shirazipour and Francisco Javier Jimenex Chico for their Meral Shirazipour and Francisco Javier Jimenex Chico for their
comments. comments.
16. References 16. References
16.1. Normative References 16.1. Normative References
16.2. Informative References
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A.
Westerinen, "Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths",
RFC5441, April 2009.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
April 2009.
[RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding
of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, December 2008.
[RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS & GMPLS", RFC6805, July
2010.
16.2. Informative References
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A.
Westerinen, "Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003. 3630, September 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005. 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi- Extensions in Support of Generalized Multi-
Protocol Label Switching (GMPLS)", RFC Protocol Label Switching (GMPLS)", RFC
4203, October 2005. 4203, October 2005.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter- [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
Autonomous System (AS) Traffic Engineering (TE) N., and G. Ash, "Crankback Signaling Extensions for MPLS
Requirements", RFC 4216, November 2005. and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008. Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-Protocol Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, Label Switching (GMPLS)", RFC 5307,
October 2008. October 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", December 2008. Traffic Engineering", December 2008.
[RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path
Computation Element Communication Protocol (PCECP)", RFC
5376, November 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009. Traffic Engineering", RFC 5392, January 2009.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
December 2008. December 2008.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths",
RFC5441, April 2009.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) Path Computation Element Communication Protocol (PCEP)
for Route Exclusions", RFC 5521, April 2009. for Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding
of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, December 2008.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path ComputationElement (PCE)-Based Monitoring Tools for Path ComputationElement (PCE)-Based
Architecture", RFC 5886, June 2010. Architecture", RFC 5886, June 2010.
[RFC6007] Nishioka, I., King, D., "Use of the Synchronization [RFC6007] Nishioka, I., King, D., "Use of the Synchronization
VECtor (SVEC) List for Synchronized Dependent Path VECtor (SVEC) List for Synchronized Dependent Path
Computations", RFC6007, September 2010. Computations", RFC6007, September 2010.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON). the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture [G-7715] ITU-T Recommendation G.7715 (2002), Architecture
and Requirements for the Automatically Switched and Requirements for the Automatically Switched
Optical Network (ASON). Optical Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing
architecture and requirements for remote route query. architecture and requirements for remote route query.
[RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS & GMPLS", RFC6805, July
2010.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013. Guide", RFC 6952, May 2013.
[RFC7334] Zhao, Q., Dhody, D., Ali Z., King, D., [RFC7334] Zhao, Q., Dhody, D., Ali Z., King, D.,
Casellas, R., "PCE-based Computation Casellas, R., "PCE-based Computation
Procedure To Compute Shortest Constrained Procedure To Compute Shortest Constrained
P2MP Inter-domain Traffic Engineering Label Switched P2MP Inter-domain Traffic Engineering Label Switched
Paths", August 2014. Paths", August 2014.
[RFC7420] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE [RFC7420] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE
Communication Protocol (PCEP) Management Information Communication Protocol (PCEP) Management Information
Base", December 2014. Base", December 2014.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
[RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and TE S. Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", March 2016. Information using BGP", March 2016.
[RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects
for the Path Computation Element Communication Protocol for the Path Computation Element Communication Protocol
(PCEP)", June 2016. (PCEP)", June 2016.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for "PCEPS: Usage of TLS to Provide a Secure Transport for
the Path Computation Element Communication Protocol the Path Computation Element Communication Protocol
(PCEP)", RFC 8253, October 2017. (PCEP)", RFC 8253, October 2017.
[RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC8453, Abstraction and Control of TE Networks (ACTN)", RFC8453,
August 2018. August 2018.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A [PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
 End of changes. 36 change blocks. 
112 lines changed or deleted 130 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/