RFC 4674
Requirements for Path Computation Element (PCE) Discovery
RFC 4674: Requirements for Path Computation Element (PCE) Discovery 💖
Okay bestie, this is RFC 4674 📜, and it's all about how a Path Computation Client (PCC) finds Path Computation Elements (PCEs) on its own. It came from the Network Working Group ✨, written by J.L. Le Roux, Ed. from France Telecom 🇫🇷. It's Informational and dated October 2006 🎀. It doesn't list any RFCs it obsoletes or updates, so it's a standalone glow-up 🦋.
Status of This Memo 🌸
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💅.
Copyright Notice 🔐
Copyright (C) The Internet Society (2006).
Abstract ✨
This doc lays out a set of requirements for a PCE discovery mechanism. The goal is that a PCC can discover a bunch of PCEs dynamically and automatically, plus some info it needs to pick the right one 🧚. The intention is that any solution, whether it's new procedures and protocols or extensions to existing protocols, should satisfy these requirements 💜.
Table of Contents 🍓
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Problem Statement and Requirements Overview .....................4
2.1. Problem Statement ..........................................4
2.2. Requirements Overview ......................................5
3. Example of Application Scenario .................................6
4. Detailed Requirements ...........................................7
4.1. PCE Information to Be Disclosed ............................7
4.1.1. General PCE Information (Mandatory Support) .........8
4.1.1.1. Discovery of PCE Location ..................8
4.1.1.2. Discovery of PCE Domains and
Inter-domain Functions .....................8
4.1.2. Detailed PCE Information (Optional Support) .........9
4.1.2.1. Discovery of PCE Capabilities ..............9
4.1.2.2. Discovery of Alternate PCEs ...............10
4.2. Scope of PCE Discovery ....................................10
4.2.1. Inter-AS Specific Requirements .....................10
4.3. PCE Information Synchronization ...........................11
4.4. Discovery of PCE Deactivation .............................11
4.5. Policy Support ............................................12
4.6. Security Requirements .....................................12
4.7. Extensibility .............................................13
4.8. Scalability ...............................................13
4.9. Operational Orders of Magnitudes ..........................13
4.10. Manageability Considerations .............................14
4.10.1. Configuration of PCE Discovery Parameters .........14
4.10.2. PCE Discovery MIB Modules .........................14
4.10.2.1. PCC MIB Module ...........................14
4.10.2.2. PCE MIB module ...........................15
4.10.3. Monitoring Protocol Operations ....................15
4.10.4. Impact on Network Operations ......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Contributors ...................................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................171. Introduction ✨
Okay so the PCE-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity that can compute TE-LSP paths based on a network graph and apply computational constraints 🦋. A PCE handles path computation requests that come in from Path Computation Clients (PCC) 💖.
A PCC is a client application that asks a PCE to do a path computation 🫶. That could be an LSR asking for a path for a TE-LSP it's the head-end of, or a PCE asking another PCE to compute a path (inter-PCE communication) 🧚. The conversation between a PCC and a PCE needs a client-server protocol, and the generic requirements for that are listed in [RFC4657] 📋.
The PCE-based architecture needs a PCC to know where one or more PCEs are in its domain 🏠. Sometimes it also needs to know about PCEs in other domains, like for inter-domain path computation 🌈.
So it would be super desirable to have a mechanism for automatic and dynamic PCE discovery 💅. That would let PCCs find a set of PCEs automatically, figure out extra info needed for PCE selection, and notice new PCEs or any changes to PCE info as they happen ✨. This covers a PCC discovering one or more PCEs in its own domain and potentially in other domains too. The other-domain part is especially useful for inter-domain path computation, for example 👑.
This document lists functional requirements for that kind of automatic and dynamic PCE discovery mechanism 📜. Section 2 covers the problem statement 🔍, Section 3 shows an application scenario 🎬, and Section 4 gets into the detailed requirements 💜.
It is intended that solutions which specify procedures, protocols, or protocol extensions for PCE discovery satisfy these requirements 🫶. The document doesn't mean to specify solution-specific requirements, and it doesn't make any assumptions about which protocols might be used for discovery 🙈.
Note that the requirements here apply equally to PCEs that compute paths in MPLS-TE-enabled networks, PCEs that compute paths in GMPLS-enabled networks, and PCEs that can do both 🌸.
It's also important to know that the idea of a PCC includes a PCE acting as a PCC when it asks another PCE for a path computation (inter-PCE communication) 🔥. So this document doesn't split PCE discovery by PCCs from PCE discovery by PCEs. It's all one vibe 💖.
1.1. Conventions Used in This Document 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 🎀.
1.2. Terminology 📖
Here's the terminology used in this doc, bestie 🧠:
- LSR: Label Switch Router.
- TE-LSP: Traffic Engineered Label Switched Path.
- PCE: Path Computation Element. An entity (component, application, or network node) that can compute a network path or route based on a network graph and apply computational constraints 🦋.
- PCC: Path Computation Client. Any client application that requests a path computation to be performed by a Path Computation Element 💅.
- Interior Gateway Protocol (IGP) Area: OSPF Area or ISIS level/area.
- ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router).
- AS: Autonomous System.
- ASBR: AS Border Router.
- Intra-area TE LSP: A TE LSP whose path does not cross IGP area boundaries.
- Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas.
- Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASs or sub-ASs (BGP confederations) 🌐.
- Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP areas and Autonomous Systems 🏡.
2. Problem Statement and Requirements Overview 🔍
2.1. Problem Statement 🧩
In practice, a routing domain can contain multiple PCEs 🌸:
- The path computation load may be balanced among a set of PCEs to improve scalability ⚖️.
- For redundancy, primary and backup PCEs may be used 🛟.
- PCEs may have distinct path computation capabilities (multi-constrained path computation, backup path computation, etc.) ✨.
- In an inter-domain context, there can be several PCEs with distinct inter-domain functions (inter-area, inter-AS, inter-layer), with each PCE responsible for path computation in one or more domains 🌍.
To make PCE selection work well, meaning a PCC picks the right PCE based on its capabilities and balances requests efficiently, a PCC needs to know where the PCEs in its domain are, plus some info relevant to selection 🎯. It may also need to know where some PCEs in other domains are, for inter-domain path computation 🌈.
That PCE info could be learned through manual configuration on each PCC, listing the set of PCEs and their capabilities 🛠️. Manual configuration may be enough, and even preferred in some situations (for example, inter-AS PCE discovery, where manual configuration of neighbor PCEs may be preferred for security reasons 🔐). But it obviously runs into several limitations 🙃:
- It may imply a substantial configuration overhead 😩.
- It would not let a PCC dynamically detect that a new PCE is available, that an existing PCE is no longer available, or that there's a change in a PCE's information 🚫.
Plus, as with any manual configuration approach, there's a risk of configuration errors 💀.
Here's an example. Imagine a multi-area network with one backbone area and N peripheral areas, where inter-area MPLS-TE path computation relies on multiple-PCE path computation with ABRs acting as PCEs. The backbone area would then have at least N PCEs, and configuring the PCCs would be way too cumbersome (in existing multi-area networks, N can be beyond fifty) 😱.
So an automated PCE discovery mechanism that lets a PCC dynamically discover a set of PCEs is highly desirable 🫶.
2.2. Requirements Overview 📋
A PCE discovery mechanism that satisfies the requirements in this document MUST allow a PCC to automatically discover the location of one or more of the PCEs in its domain 🏠.
Where inter-domain path computation is required and policy permits, the PCE discovery method MUST allow a PCC to automatically discover the location of PCEs in other domains that can help with inter-domain path computation 🌈.
A PCE discovery mechanism MUST allow a PCC to discover the set of one or more domains where a PCE has TE topology visibility and can compute paths 👀. It MUST also allow the discovery of the potential inter-domain path computation functions of a PCE (inter-area, inter-AS, inter-layer, etc.) 🧠.
A PCE discovery mechanism MUST allow control of the discovery scope, which is the set of one or more domains (areas, ASs) where information related to a given PCE has to be disclosed 🎚️.
A PCE discovery mechanism MUST allow PCCs in a given discovery scope to dynamically discover that a new PCE has appeared or that there's a change in a PCE's information 🆕.
A PCE discovery mechanism MUST allow PCCs to dynamically discover that a PCE is no longer available 👋.
A PCE discovery mechanism MUST support security procedures. In particular, key consideration MUST be given to how to establish a trust model for PCE discovery 🔐🔥.
OPTIONALLY, a PCE discovery mechanism MAY be used to disclose a set of detailed PCE capabilities, so the PCC can make advanced and informed choices about which PCE to use 👑💖.
3. Example of Application Scenario ✨
okay so let's picture a real network to see how this all plays out 🗺️
<----------------AS1--------------------> <----AS2---
Area 1 Area 0 Area 2
R1---------R3-----R5-------R6-----------R9----------R11----R13
| | | |
| | | |
R2---------R4-----R7-------R8-----------R10---------R12----R14
|
|
--
|S1|
-- Figure 1so Figure 1 shows a multi-area and multi-AS network with a bunch of PCEs 🌸 here's who's doing what:
- ABR R3 is a PCE that can take part in inter-area path computation 🦋 it can compute paths in area 1 and area 0.
- ABR R6 is a PCE that can take part in inter-area path computation 💜 it can compute paths in area 0 and area 2.
- ASBR R9 is a PCE that can take part in inter-AS path computation 🧚 it's responsible for path computation in AS1 towards AS2.
- ASBR R12 is a PCE that can take part in inter-AS path computation 🫶 it's responsible for path computation in AS2 towards AS1.
- Server S1 is a PCE that can be used to compute diverse paths and backup paths in area 1 🔥
ngl the whole point is that if the requirements in this document are met, the PCE discovery mechanism lets everyone find each other 🥹 specifically:
- each PCC in areas 1 and 0 can dynamically discover R3 as a PCE for inter-area path computation, and R3 can compute paths in area 0 and area 1 💖
- each PCC in areas 0 and 2 can dynamically discover R6 as a PCE for inter-area path computation, and R6 can compute paths in area 2 and area 0 🌈
- each PCC in AS1 and one or more PCCs in AS2 can dynamically discover R9 as a PCE for inter-AS path computation in AS1 towards AS2 🎀
- each PCC in AS2 and one or more PCCs in AS1 can dynamically discover R12 as a PCE for inter-AS path computation in AS2 towards AS1 ⭐
- each PCC in area 1 can dynamically discover S1 as a PCE for intra-area path computation in area 1, and optionally discover its path computation capabilities (diverse path computation and backup path computation) 🍓
4. Detailed Requirements 💅
4.1. PCE Information to Be Disclosed
okay so there are two levels of PCE info that a discovery mechanism can disclose 👀
- General information. Disclosure MUST be supported by the PCE discovery mechanism.
- Detailed information. Disclosure MAY be supported by the PCE discovery mechanism.
the discovery mechanism MUST allow disclosure of general PCE info so PCCs can pick the right PCEs 💖 this covers the PCE's location, the PCE domains it supports, and its inter-domain functions.
the discovery mechanism MAY also allow disclosure of detailed PCE info 🔍 this can be any or all of the path computation capabilities and alternate PCEs. this info isn't technically part of PCE discovery, it's extra stuff that can help a PCC choose a PCE. supporting the exchange of it is optional in the context of the discovery mechanism itself. that doesn't mean the info is optional in the PCE-based architecture though 🙈 it could be obtained through other mechanisms too, like the PCC-PCE communication protocol.
4.1.1. General PCE Information (Mandatory Support) 🌸
4.1.1.1. Discovery of PCE Location 📍
the discovery mechanism MUST allow discovery, for a given PCE, of the IPv4 and/or IPv6 address used to reach it 💅 this address is usually one that's always reachable, as long as there's any connectivity to the PCE.
PCCs will use this address to talk to a PCE through a PCC-PCE communication protocol 🫶
4.1.1.2. Discovery of PCE Domains and Inter-domain Functions 🗺️
inter-domain path computation is a huge deal in the PCE-based architecture 👑 it can work with multiple PCEs, where the PCEs in each domain compute part of the end-to-end path and work together to find the whole thing. it can also work with a single PCE that can see inside multiple domains and compute an entire end-to-end inter-domain path (that's a path from the inter-domain TE-LSP head-end to the inter-domain TE-LSP tail end).
so the discovery mechanism MUST allow discovery of the set of one or more domains where a PCE has visibility and can compute paths 🌈 these domains can be identified with a domain identifier. for example, an IGP area can be identified by its Area ID (OSPF or ISIS), and an AS can be identified by its AS number.
the discovery mechanism MUST also allow discovery of a PCE's inter-domain functions 🎀 that means whether a PCE can be used to compute, or take part in computing, end-to-end paths across domain borders. these functions include, non-exhaustively, inter-area, inter-AS and inter-layer path computation. and they aren't mutually exclusive, so a PCE can have more than one 💅
the inter-domain functions aren't always inferred from the set of domains a PCE can see 🧠 for example, a PCE might only have visibility into one domain but still take part in inter-domain paths by working with PCEs in other domains. and the reverse is true too: a PCE might see multiple domains, but the operator might not want it used for inter-domain path computations.
the PCE discovery mechanisms MUST also allow discovery of the set of one or more domains toward which a PCE can compute paths 🦋 for example, in an inter-AS context, there may be several PCEs in an AS, and each one is responsible for taking part in inter-AS paths toward a set of one or more destination ASs. a PCC may need to discover which destination ASs each PCE is responsible for.
4.1.2. Detailed PCE Information (Optional Support) 🍓
4.1.2.1. Discovery of PCE Capabilities 🧩
when there are several PCEs with different capabilities, a PCC has to pick one or more appropriate PCEs 💭
for that, the PCE discovery mechanism MAY support disclosing some detailed PCE capabilities ✨
for example (just to illustrate), these path-computation-related capabilities could be included:
- The link constraints supported: e.g., bandwidth, affinities.
- The path constraints supported: maximum IGP/TE cost, maximum hop count.
- The objective functions supported: e.g., shortest path, widest path.
- The capability to compute multiple correlated paths: e.g., diverse paths, load balanced paths.
- The capability to compute bidirectional paths.
- The GMPLS-technology-specific constraints supported: e.g., the supported interface switching capabilities, encoding types.
and these specific PCE capabilities could also be included:
- The capability to handle request prioritization.
- The maximum size of a request message.
- The maximum number of path requests in a request message.
- The PCE computation power (static parameters to be used for weighted load balancing of requests).
a PCC can then use this kind of info to pick a good PCE from a list of candidates 🛍️
just a heads-up: the exact definition and description of PCE capabilities are out of scope for this document 🙅♀️ that'll be covered in one or more separate documents, which may be application specific.
4.1.2.2. Discovery of Alternate PCEs 🔁
if a PCE fails, a PCC has to switch to another PCE, if one is available 😭 so it can be really useful for a PCE to name a set of one or more alternate PCEs it can be swapped with if it goes down.
so the PCE discovery mechanism MAY allow discovery, for a given PCE, of the location of one or more assigned alternate PCEs 💜
the PCE discovery mechanism MAY also allow discovery, for a given PCE, of the set of one or more PCEs that it acts as an alternate PCE for 🫧
4.2. Scope of PCE Discovery 🔭
the PCE discovery mechanism MUST allow control of the scope of PCE information disclosure on a per-PCE basis 💅 in other words, it MUST allow control over which PCC, or group of PCCs, the info about a PCE may be disclosed to.
the discovery scope for a given PCE MUST include at least these settings:
- All PCCs in a single IGP area.
- All PCCs in a set of adjacent IGP areas.
- All PCCs in a single AS.
- All PCCs in a set of ASs.
- A set of one or more PCCs in a set of one or more ASs.
this also means the PCE discovery mechanism MUST allow discovery of PCE info across IGP areas and across AS boundaries 🌍
the discovery scope MUST be configurable on a per-PCE basis 🎛️
it MUST be possible to deactivate PCE discovery on a per-PCE basis 🙅♀️
4.2.1. Inter-AS Specific Requirements 🌉
when a PCE-based approach is used for inter-AS path computation, a PCC in one AS may need to learn about inter-AS-capable PCEs in other ASs 👀 so as mentioned in the previous section, the PCE discovery mechanism MUST allow disclosure of info about inter-AS-capable PCEs across AS boundaries.
⚠️ this kind of inter-AS discovery has to be carefully controlled! for security and confidentiality reasons, especially in an inter-provider context, the discovery mechanism MUST allow the discovery scope to be limited to a set of ASs, and MUST also provide control over the PCE info disclosed across ASs. this is done by applying policies (see also Section 4.4). it means being able to contain a PCE advertisement to a restricted set of one or more ASs, and to filter and translate any PCE parameter (PCE domains, PCE inter-domain functions, PCE capabilities, etc.) in disclosures that cross AS borders.
for example, it might make sense to disclose detailed PCE info (like detailed capabilities) locally within the PCE's own AS, but only general info (like location and supported domains) in other ASs 🫶
4.3. PCE Information Synchronization 🔄
the PCE discovery mechanism MUST allow a PCC to discover any change in info about a PCE it has already discovered 💫 this covers changes to general info (for example, a change in the PCE domains supported) and to detailed info, if that's supported (for example, a change to the PCE's capabilities).
also, the PCE discovery mechanism MUST allow dynamic discovery of new PCEs in a given discovery scope 🌱
there's no requirement for real-time detection of these changes 🙌 the PCE discovery mechanism SHOULD rather allow discovery of these changes within a range of 60 seconds, and the operator should be able to configure the discovery delay ⏱️
last thing: PCE info is relatively static, so it's expected to be pretty stable and not change very often 🥰
4.4. Discovery of PCE Deactivation 💀
okay so the PCE discovery mechanism MUST let a PCC find out when a PCE it has already discovered is no longer alive or has been deactivated 🫶. This can help cut down on, or avoid, path computation service disruption ✨.
Note that there is no requirement for real-time detection of PCE failure or deactivation 🙈. The PCE discovery mechanism SHOULD rather allow that detection within a range of 60 seconds, and the operator should be able to configure the discovery delay 💅.
4.5. Policy Support 🎀
The PCE discovery mechanism MUST allow policies that do three things: restrict the discovery scope to a set of authorized domains, control and restrict the type and nature of the information that gets disclosed, and filter and translate some information at domain borders 👑. It MUST be possible to apply these policies on a per-PCE basis 💖.
Note that the discovery mechanisms MUST allow disclosing policy information so that the disclosure policies can be controlled at domain boundaries 🧚.
Also, it MUST be possible to apply different policies when disclosing PCE information to different domains 🌸.
4.6. Security Requirements 🔐😭
The five major threats related to PCE discovery mechanisms are:
- impersonation of PCE;
- interception of PCE discovery information (sniffing);
- falsification of PCE discovery information;
- information disclosure to non-authorized PCCs (PCC spoofing);
- Denial of Service (DoS) Attacks.
Note that security of the PCE discovery procedures is especially important in an inter-AS context 🚨, where PCE discovery may increase the vulnerability to attacks and the consequences of those attacks.
Hence, mechanisms MUST be defined to ensure authenticity, integrity, confidentiality, and containment of PCE discovery information:
- There MUST be a mechanism to authenticate discovery information.
- There MUST be a mechanism to verify discovery information integrity.
- There MUST be a mechanism to encrypt discovery information.
- There MUST be a mechanism to restrict the scope of discovery to a set of authorized PCCs and to filter PCE information disclosed at domain boundaries (as per defined in Section 4.5).
A PCE and PCC MUST be identified by a globally unique ID 🪪, which may be, for instance, a combination of AS number and IP address.
Mechanisms MUST be defined in order to limit the impact of a DoS attack on the PCE discovery procedure (e.g., filter out excessive PCE information change and flapping PCEs) 🛡️. Note also that DoS attacks may be either accidental (caused by a misbehaving PCE system) or intentional. As discussed in [RFC4657], such mechanisms may include packet filtering, rate limiting, no promiscuous listening, and where applicable use of private addresses spaces.
Also, key consideration MUST be given to how to establish a trust model for PCE discovery 🤝. The PCE discovery mechanism MUST explicitly support a specific set of one or more trust models.
4.7. Extensibility 🌈
The PCE discovery mechanism MUST be flexible and extensible, so that it can easily include additional PCE information that could be defined in the future ✨.
4.8. Scalability 📈
The PCE discovery mechanism MUST be designed to scale well with an increase of any of the following parameters:
- Number of PCCs discovering a given PCE.
- Number of PCEs to be discovered by a given PCC.
- Number of domains in the discovery scope.
The PCE discovery mechanism MUST NOT have an adverse effect on the performance of other protocols (especially routing and signaling) already operating in the network 🙅♀️.
Note that there is no scalability requirement with regards to the amount of information to be exchanged.
Information disclosed in the PCE discovery mechanism is relatively static 🧊. Changes in PCE information may occur as a result of PCE configuration updates, PCE deployment/activation, or PCE deactivation/suppression, and should not occur as a result of the PCE activity itself. Hence, this information is quite stable and will not change frequently 💅.
4.9. Operational Orders of Magnitudes 🔢
This section gives minimum order of magnitude estimates of what the PCE discovery mechanism should support.
- Number of PCCs discovering a given PCE: 1000
- Number of PCEs to be discovered by a given PCC: 100
4.10. Manageability Considerations 🛠️
Mechanisms are REQUIRED to manage PCE discovery operations. This includes the configuration of PCE discovery functions and policies, as well as the monitoring of the discovery protocol activity 👀.
4.10.1. Configuration of PCE Discovery Parameters ⚙️
It MUST be possible to enable and disable the PCE discovery function at a PCC and at a PCE.
On the PCC, it MUST be possible for an operator to activate or deactivate automatic PCE discovery. The activation of automatic discovery MUST not prevent static configuration of PCE information that may supplement discovered information 🫶.
On the PCE, it MUST be possible for an operator to control the application of discovery policies by which the specific PCE is discovered. As described in Section 4.5, this control MUST include the ability to:
- restrict the discovery scope to a set of authorized domains;
- define the type and nature of the information disclosed;
- specify the filtering and translation to be applied to the PCE information disclosed at domain borders.
These configuration options MAY be supported through an implementation-specific local configuration interface, or MAY be supported via a standardised interface (such as a MIB module, as below) 🎀.
4.10.2. PCE Discovery MIB Modules 📚
PCE discovery MIB modules MUST be specified for the control of the function on PCCs and PCEs.
4.10.2.1. PCC MIB Module 🧑💻
The MIB module that will run on PCCs MUST include at least the following:
- A control to disable automatic discovery by the PCC,
- The set of known PCEs,
- The number of known PCEs, and the number of discovered PCEs.
For each PCE reported in the MIB module, the following information MUST be available:
- Information advertised by the PCE (i.e., discovered information),
- Information locally configured about the PCE,
- The time since the PCE was discovered,
- The time since any change to the discovered information for the PCE.
Note that when a PCE is no longer alive (see Section 4.4), it SHOULD no longer be reported in the PCC MIB module 👋.
The MIB module SHOULD also provide the average and maximum rates of arrival, departure, and modification of PCE discovery, so the protocols can be analysed effectively 📊. Furthermore, the MIB module SHOULD report on the operation of the discovery protocol by counting the number of unacceptable and incomprehensible information exchanges.
The PCC MIB module SHOULD also be used to provide notifications when thresholds (e.g., on the maximum rate of change, on the number of unacceptable messages) are crossed, or when important events occur (e.g., the number of discovered PCEs decreases to zero) 🚨.
4.10.2.2. PCE MIB module 🛰️
The MIB module that will run on PCEs MUST include at least:
- a control to disable automatic discovery announcements by the PCE;
- information to be advertised by the PCE, although this information MAY be present as read-only;
- the discovery policies active on the PCE, although this information MAY be present as read-only.
The MIB module SHOULD also include:
- the time since the last change to the advertised PCE information;
- the time since the last change to the advertisement policies;
- control of on which interfaces the PCE issues advertisements where this is applicable to the protocol solution selected.
Note that a PCE MAY also be configured to discover other PCEs. In this case, it SHOULD operate the MIB module described in Section 4.10.2.1 as well as the module described here 🧠.
4.10.3. Monitoring Protocol Operations 🔍
It MUST be possible to monitor the operation of any PCE discovery protocol. Where an existing protocol is used to support the PCE discovery function, this monitoring SHOULD be achieved using the techniques already defined for that protocol, enhanced by the MIB modules described above. Where those techniques are inadequate, new techniques MUST be developed.
Monitoring of the protocol operation demands support for at least the following functions:
- Correlation of information advertised against information received.
- Counts of dropped, corrupt, and rejected information elements.
- Detection of 'segmented' networks, that is, the ability to detect and diagnose the failure of a PCE advertisement to reach a PCC.
4.10.4. Impact on Network Operations 🌊
Frequent changes in PCE information may have a significant impact on PCCs that receive the advertisements. They might destabilize the operation of the network by causing the PCCs to swap between PCEs, and might harm the network through excessive advertisement traffic 😬. Hence, it MUST be possible to apply at least the following controls:
- Configurable limit on the rate of announcement of changed parameters at a PCE.
- Control of the impact on PCCs such as through discovery messages rate-limiting.
- Configurable control of triggers that cause a PCC to swap to another PCE.
5. Security Considerations 🔐
This document is a requirement document and hence does not raise by itself any particular security issue 🙂.
A set of security requirements that MUST be addressed when considering the design and deployment of a PCE discovery mechanism has been identified in Section 4.6. Please go read that section 🫶🔥.
6. Acknowledgements 💜
We would like to thank, in chronological order, Benoit Fondeviole, Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil Bitar, and Kenji Kumaki.
Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley and Sam Hartman for their review and constructive discussions during the final stages of publication 👏.
7. Contributors 🦋
The following are the authors who contributed to the present document:
Jean-Louis Le Roux (France Telecom)
Paul Mabey (Qwest Communications)
Eiji Oki (NTT)
Richard Rabbat (Fujitsu)
Ting Wo Chung (Bell Canada)
Raymond Zhang (BT Infonet)8. References 📖
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.8.2. Informative References
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.Contributors' Addresses 📬
Paul Mabey
Qwest Communications
950 17th Street
Denver, CO 80202
USA
EMail: pmabey@qwest.com
Eiji Oki
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585
JAPAN
EMail: oki.eiji@lab.ntt.co.jp
Richard Rabbat
Fujitsu Laboratories of America
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
USA
EMail: richard@us.fujitsu.com
Ting Wo Chung
Bell Canada
181 Bay Street, Suite 350
Toronto, Ontario, M5J 2T3
CANADA
EMail: ting_wo.chung@bell.ca
Raymond Zhang
BT Infonet
2160 E. Grand Ave.
El Segundo, CA 90025
USA
EMail: raymond_zhang@infonet.comEditor's Address 💌
okay so the editor of this doc is Jean-Louis Le Roux 💅 and he was at France Telecom when this was written. here's where to find him 🧚
Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
EMail: jeanlouis.leroux@orange-ft.comFull Copyright Statement 🎀
bestie, the legal bit is next and it's giving serious paperwork energy 😭 but it's important so let's go 🫶
Copyright (C) The Internet Society (2006). 🌈
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💜
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property 🦋
ngl this part is about who owns what 👑 so the IETF doesn't pick a side on whether any patents or other rights cover the tech in this doc, or whether you can get a license for them. it also hasn't done its own digging to find any of that stuff. if you want the rules on rights in RFCs, check out BCP 78 and BCP 79 🌸
copies of IPR disclosures sent to the IETF Secretariat, any licence assurances, and the results of trying to get a general license or permission to use those rights are all available from the IETF's online IPR repository at http://www.ietf.org/ipr. 🔥
and the IETF is literally asking anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to let them know. just email ietf-ipr@ietf.org 💖
Acknowledgement 🫶
last one, and it's a quick shoutout 🧚 funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). the people keeping these docs running deserve all the flowers 💐✨
📦 where this page comes from
- ietf: rfc4674 2006-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms