RFC 6007
Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations
RFC 6007: Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations 🦋
Bestie, here's the header tea ☕: this one is by I. Nishioka (NEC Corp.) and D. King (Old Dog Consulting). It's Informational (so it's not a Standards Track spec, just vibes and clarity 💅), it's from September 2010, and it's published under ISSN 2070-1721. The header doesn't list anything it obsoletes or updates. Okay, on to the good stuff!
Abstract
okay so a Path Computation Element (PCE) sometimes has to do dependent path computations 🧩. These are requests that have to be synchronized so they hit specific goals. The classic example is a PCE picking a bunch of services that have to be diverse (aka disjointed) from each other, like they can't share the same route. When a PCE handles sets of dependent requests at the same time, the Synchronization VECtor (SVEC) list is required so everything is linked up properly 🔗. The SVEC object is optional, and it rides inside the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message 📨.
This doc does not define the PCEP SVEC object or its procedure, so no new rules here 🙅♀️. What it does do is explain how to use SVEC lists for synchronized path computations when you're dealing with dependent requests. It also walks through a bunch of usage scenarios in both single-domain and multi-domain setups. It's giving clarity, periodt ✨.
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🧐.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6007 🔎.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
Heads up, this part is serious: the document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙏.
Table of Contents
1. Introduction ....................................................3
1.1. SVEC Object ................................................4
1.2. Application of SVEC Lists ..................................5
2. Terminology .....................................................6
3. SVEC Association Scenarios ......................................7
3.1. Synchronized Computation for Diverse Path Requests .........7
3.2. Synchronized Computation for Point-to-Multipoint
Path Requests ..............................................8
4. SVEC Association ................................................9
4.1. SVEC List ..................................................9
4.2. Associated SVECs ...........................................9
4.3. Non-Associated SVECs ......................................10
5. Processing of SVEC List ........................................10
5.1. Single-PCE, Single-Domain Environments ....................10
5.2. Multi-PCE, Single-Domain Environments .....................11
5.3. Multi-PCE, Multi-Domain Environments ......................11
6. End-to-End Diverse Path Computation ............................13
6.1. Disjoint VSPT .............................................13
6.2. Disjoint VSPT Encoding ....................................14
6.3. Path Computation Procedure ................................15
7. Manageability Considerations ...................................15
7.1. Control of Function and Policy ............................15
7.2. Information and Data Models (MIB Modules) .................15
7.3. Liveness Detection and Monitoring .........................15
7.4. Verifying Correct Operation ...............................15
7.5. Requirements on Other Protocols and Functional
Components ................................................16
7.6. Impact on Network Operation ...............................16
8. Security Considerations ........................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
10. Acknowledgements ..............................................181. Introduction ✨
okay so [RFC5440] is the spec for the Path Computation Element Communication Protocol (PCEP) 💻. PCEP handles the chat between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs, based on the PCE architecture in [RFC4655]. PCEP conversations include path computation requests and path computation replies 📬.
A PCE might have to handle both independent and dependent path computation requests. Requests are independent when they have nothing to do with each other, so they don't need to be synchronized 🙋♀️. Dependent requests are the opposite. You can't compute them separately, so they have to be synchronized 🔗. The Synchronization VECtor (SVEC) with a list of path computation request identifiers (carried in the request message) lets the PCC or PCE say "hey, these multiple requests must be synchronized" 💖. Section 1.1 ("SVEC Object") explains the SVEC object, and Section 1.2 ("Application of SVEC Lists") shows how SVEC lists get used in certain scenarios.
This informational doc clarifies how to handle dependent and synchronized path computation requests with the SVEC list, building on the PCE architecture in [RFC4655] and PCEP in [RFC5440] 🦋. It also describes usage scenarios for SVEC lists in single-domain and multi-domain environments. What it's not trying to do is specify the procedure for using SVEC lists with dependent and synchronized path computation requests. That's not its job 🙅♀️.
1.1. SVEC Object 💅
Here's the vibe: when a PCC or PCE sends path computation requests to a PCE, one PCEP Path Computation Request (PCReq) message can carry multiple requests. Each one has its own unique path computation request identifier 🧾. The SVEC, which is a list of those request identifiers carried in the message, lets the PCC or PCE group multiple requests that must be synchronized. It also lets you specify any dependency relationships between the paths 🕸️. The path computation requests listed in the SVEC must be handled in a specific relation to each other (i.e., synchronized) 🎯.
[RFC5440] defines two synchronous path computation modes for dependent or independent path computation requests. Which mode you get depends on the dependency flags in the SVEC, meaning the Node, Link, or Shared Risk Link Group (SRLG) diverse flags 🚦:
- A set of independent and synchronized path computation requests.
- A set of dependent and synchronized path computation requests.
For more on dependent, independent, and synchronous path computation, go read [RFC5440] 📖.
These two computation modes are exclusive to each other in a single SVEC 🚫. If any one of the dependency flags in an SVEC is set, that means the set of synchronous path computation requests has a dependency, and the SVEC doesn't allow any other path computation requests. So if you want to synchronize with other path computation requests that have a dependency, you have to associate them 🔗.
The whole point of the SVEC object in a PCReq message is to ask for synchronization of M path computation requests 🎀. Every request is uniquely identified by its Request-ID-number, which is carried in the respective Request Parameters (RP) object. The SVEC object also has a set of flags that specify the synchronization type 🚩. The SVEC object itself is defined in Section 7.13 ("SVEC Object") of [RFC5440] 🙌.
Part 1 of 4 is done! 🎀 Part 2 picks up at Section 2 (Terminology) and keeps the vibes going ✨.
1.2. Application of SVEC Lists 🎀
Okay so it's super important for the PCE to sync up its path computation requests whenever they depend on each other 🫶 Picture two protected end-to-end services:
- It would be beneficial for each back-up path to be disjointed so they do not share the same links and nodes as the working path. 🛡️
- Two diverse path computation requests would be needed to compute the working and disjointed protected paths. 👯♀️
If the diverse path requests get computed one after the other, the first one might get finished without any thought for the second one or its disjoint constraint 😬 Then the PCE could end up giving sub-optimal disjoint results for the protected path, or it could fail to meet the end-to-end disjoint requirement altogether. Not me having a whole plan that falls apart 💀
SVEC can also be used for end-to-end diverse path computations that go across multiple domains ✨ [RFC5441] describes two approaches for this across a chain of domains: synchronous (i.e., simultaneous) and 2-step. The path computation procedure is specified for the 2-step approaches in [RFC5521], but no guidelines are provided for the synchronous approach described in this document.
The following scenarios are specifically described within this document:
- Single-domain, single-PCE, dependent and synchronized path computation request. 🦋
- Single-domain, multi-PCE, dependent and synchronized path request. 🌸
- Multi-domain, dependent and synchronized path computation request, including end-to-end diverse path computation. 🌈
This document also covers the association among multiple SVECs for multiple sets of synchronized dependent path computations, plus the disjoint Virtual Shortest Path Tree (VSPT) encoding rule for end-to-end diverse path computation across domains 💜 Path computation algorithms for these scenarios are out of the scope of this document, so don't come looking for them here 🙈
The clarifications and use cases in this document apply to the Global Concurrent Optimization (GCO) path computation mechanism specified in [RFC5557] 👑 The GCO application lets you optimize a set of services within the network so that network resources get used as efficiently as possible. A single objective function (OF) or a set of OFs can be applied to a GCO. To compute a set of these traffic-engineered paths for the GCO application, PCEP supports the synchronous and dependent path computation requests required in [RFC4657] 🔥
The SVEC association and the disjoint VSPT described here do not need any extension to PCEP messages and object formats when computing a GCO for multiple or end-to-end diverse paths 🙌 Also, using multiple SVECs isn't limited to only the SRLG, node, and link diversity currently defined in the SVEC object [RFC5440]. It's also available for other dependent path computation requests 💅
The SVEC association and disjoint VSPT are available to both single-PCE path computation and multi-PCE path computation ✨
2. Terminology 📚
This document uses PCE terminology defined in [RFC4655], [RFC4875], and [RFC5440] 🧚
- Associated SVECs: A group of multiple SVECs (Synchronization VECtors), defined in this document, to indicate a set of synchronized or concurrent path computations. 🔗
- Disjoint VSPT: A set of VSPTs, defined in this document, to indicate a set of virtual diverse path trees. 🌳
- GCO (Global Concurrent Optimization): A concurrent path computation application, defined in [RFC5557], where a set of traffic engineered (TE) paths is computed concurrently in order to efficiently utilize network resources. ⚡
- Synchronized: Describes a set of path computation requests that the PCE associates and that the PCE does not compute independently of each other. 🫂
- VSPT: Virtual Shortest Path Tree, defined in [RFC5441]. 🍓
3. SVEC Association Scenarios 🌷
This section clarifies several path computation scenarios where SVEC association can be applied 💖 Any combination of the scenarios described here could also be applicable, so mix and match babe 😭
3.1. Synchronized Computation for Diverse Path Requests 💫
A PCE may compute two or more point-to-point diverse paths concurrently, in order to increase the probability of meeting primary and secondary path diversity (or disjointness) objectives and network resource optimization objectives 🧠
There are two scenarios to consider for the SVEC association of point-to-point diverse paths:
- Two or more end-to-end diverse paths 🎯
When concurrent path computation of two or more end-to-end diverse paths is requested, SVEC association is needed among the diverse path requests. Here's the tea: each diverse path request is made up of primary, secondary, and tertiary (and beyond) path requests, and all of those path requests are grouped under one SVEC association 🍵
Say you've got two end-to-end services that need to stay separate using diverse paths. The path computation requests would need to be associated so the diversity could be assured 🥹 Now say each of those services also needs a backup path that can protect against any failure in the primary path. These backup paths have to be computed using requests that are associated with the primary paths, which gives you a set of four associated requests. Four requests, all linked, all dependent. Iconic 👑
- End-to-end primary path and its segmented secondary paths 🧩
When concurrent path computation for segment recovery paths, as shown in Figure 1, is requested, SVEC association is needed between a primary path and several segmented secondary paths 🪄
<------------ primary ----------->
A------B------C---D------E------F
\ / \ /
P---Q---R X---Y---Z
<--secondary1--> <--secondary2-->
Figure 1. Segment Recovery PathsIn this scenario, we assume that the primary path may be pre-computed and used for specifying the segment for secondary paths 🌟 Otherwise, the segment for secondary path requests is specified in advance, using Exclude Route Object (XRO) and/or Include Route Object (IRO) constraints in the primary request 📝
3.2. Synchronized Computation for Point-to-Multipoint Path Requests 🦄
For point-to-multipoint path requests, SVEC association can be applied too 🌈
- Two or more point-to-multipoint paths 🌊
If a point-to-multipoint path computation request is represented as a set of point-to-point paths [RFC6006], two or more point-to-multipoint path computation requests can be associated for concurrent path computation, in order to optimize network resources 💎
- Point-to-multipoint paths and their secondary paths 🎀
When concurrent path computation of a point-to-multipoint path and its point-to-point secondary paths [RFC4875], or of a point-to-multipoint path and its point-to-multipoint secondary paths, is requested, SVEC association is needed among these requests 💕 For this scenario, we use the same assumption as the "end-to-end primary path and its segmented secondary paths" scenario in Section 3.1 🫶
4. SVEC Association 🧁
This section describes the associations among SVECs in a SVEC list 💜
4.1. SVEC List 🌸
PCEP can carry one or more SVEC objects in a PCReq message, and this set of SVEC objects within the PCReq message is called a SVEC list 🎁 Each SVEC object in the SVEC list contains a distinct group of path computation requests. When you want to request association among those distinct groups, the associated SVECs described in this document are used 🔗
4.2. Associated SVECs 🦋
"Associated SVECs" means there are relationships among multiple SVECs in a SVEC list ✨ Heads up: there's no automatic association in [RFC5440] between the members of one SVEC and the members of another SVEC in the same SVEC list. That's why the associated SVEC was introduced, especially for correlating SVECs with dependency flags 🧐
Request identifiers in the SVEC objects are what show the association among SVEC objects 🪪 If the same request-IDs exist in SVEC objects, those SVEC objects are associated. When you're associating SVEC objects, at least one request identifier must be shared between associated SVECs. SVEC objects can be associated regardless of the dependency flags in each SVEC object, but it is recommended to use a single SVEC if the dependency flags are not set in all SVEC objects 💅 Similarly, when associating SVEC objects with dependency flags, it is recommended to build them using a minimum set of associated SVECs, which avoids complex relational associations 🙏
Here's an example of associated SVECs. In this one, the first SVEC is associated with the other SVECs, and all of the path computation requests in the associated SVECs (i.e., Request-IDs #1, #2, #3, #4, #X, #Y, and #Z) must be synchronized 🫂
<SVEC-list>
<SVEC> without dependency flags
Request-ID #1, Request-ID #3, Request-ID #X
<SVEC> with one or more dependency flags
Request-ID #1, Request-ID #2
<SVEC> with one or more dependency flags
Request-ID #3, Request-ID #4
<SVEC> without dependency flag
Request-ID #X, Request-ID #Y, Request-ID #Z4.3. Non-Associated SVECs 🌙
"Non-associated SVECs" means there are no relationships among SVECs 🙅♀️ If none of the SVEC objects in the SVEC list on a PCReq message contains a common request-ID, there is no association between the SVECs, and so there's no association between the requests in one SVEC and the requests in another SVEC 💀
Here's an example of non-associated SVECs that don't contain any common request-IDs:
<SVEC-list>
<SVEC> with one or more dependency flags
Request-ID #1, Request-ID #2
<SVEC> with one or more dependency flags
Request-ID #3, Request-ID #4
<SVEC> without dependency flags
Request-ID #X, Request-ID #Y, Request-ID #Z5. Processing of SVEC List 🩷
5.1. Single-PCE, Single-Domain Environments 🎀
Okay so this one's the simplest 💖 there's just one PCE in the domain.
When a PCE gets PCReq messages with more than one SVEC object in the SVEC list, PCEP has to check the request-IDs in all the SVEC objects first 🔍 to figure out which ones are associated with each other. It's like a detective move, iykyk.
If none of the request-IDs match across the SVEC objects, those SVEC objects are not associated, and each set of path computation requests in them gets computed separately. Main character energy, going solo 🦋
If the request-IDs do match, then the SVEC objects are associated, and all the path computation requests in them get treated in a synchronous manner for GCO application. Lowkey the best part 👑
If a PCE can't handle an associated SVEC and finds common request-IDs in multiple SVEC objects, the PCE should cancel the path computation request and respond to the PCC with the PCErr message Error-Type="Capability not supported". Not me being like "I can't do this rn" 💀
Now, in the case that M path computation requests are sent across multiple PCReq messages, the PCE may start a SyncTimer, as recommended in Section 7.13.3 ("Handling of the SVEC Object") of [RFC5440] ⏱️ Here the associated SVECs should also be handled as described in [RFC5440], which means that after receiving the entire set of M path computation requests associated by SVECs, the computation should start at one. If the SyncTimer has expired, or the subsequent PCReq messages are malformed, the PCE should cancel the path computation request and respond to the PCC with the relevant PCErr message. Periodt 🫶
5.2. Multi-PCE, Single-Domain Environments 🌸
Now we've got multiple PCEs in a domain, and PCCs can talk to them directly and pick an appropriate PCE for load-balanced path computation requests. It's giving options ✨ In this environment, it's possible that dependent path computation requests end up going to different PCEs.
Here's the tea though 🍓 If a PCC sends path computation requests to one PCE, and then sends a further request to a different PCE using the SVEC list to show that the further request depends on the first ones, there's no method for the PCE to correlate those dependent requests. No SVEC object correlation function between PCEs is specified in [RFC5440]. No mechanism exists to resolve this problem, and the issue is open for future study. So, a PCC must not send dependent path computation requests associated by SVECs to different PCEs. Big no-no 🙅♀️
5.3. Multi-PCE, Multi-Domain Environments 🌈
This one's a whole journey 🧚 There are multiple domains, PCEs are located in each domain, and end-to-end dependent paths (aka diverse paths) get computed using multiple PCEs. Note that we assume a chain of PCEs is predetermined, and the Backward-Recursive PCE-Based Computation (BRPC) procedure [RFC5441] is in use.
SVECs can be applied to end-to-end diverse path computations that traverse multiple domains. [RFC5441] describes two approaches for end-to-end diverse path computation across a chain of domains: a synchronous (aka simultaneous) approach and a 2-step approach. In the 2-step approaches described in [RFC5521], it's not necessary to use the associated SVECs if any of the dependency flags in an SVEC object are not set. On the flip side, the simultaneous approach may require the associated SVEC, because at least one of the dependency flags is required to be set in an SVEC object. So a use case of the simultaneous approach is what we're describing in this environment ✨
When a chain of PCEs located in separate domains is used for simultaneous path computations, extra path computation processing is required, as described in Section 6 of this document 🔥
If the PCReq message contains multiple associated SVEC objects, and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain, the following procedures apply.
When the chain of PCEs is a unique sequence for all of the path computation requests in a PCReq message, it's not necessary to reconstruct associations among the SVEC objects. So the PCReq message is passed to the tail-end PCE. When a PCReq message contains more than one SVEC object with the dependency flag set, the contained SVECs may then be associated. PCEs receiving the associated SVECs must maintain their association, and must consider their relationship when performing path computations after receiving a corresponding PCReply (PCRep) message. 🫶
When the chain of PCEs is different, intermediate PCEs receiving such PCReq messages are required to be able to reconstruct associations among SVEC objects, and then send PCReq messages to corresponding PCEs located in neighboring domains. If the associated SVECs are reconstructed at the intermediate PCE, the PCE must not start its path computation until all PCRep messages have been received from all neighbor PCEs. However, a complex PCE implementation is required for SVEC reconstruction, and waiting mechanisms must be implemented. Therefore, it is not recommended to associate path computation requests with different PCE chains. This is an open issue, and it's currently being discussed in [H-PCE], which proposes a hierarchical PCE architecture 🧚♀️
6. End-to-End Diverse Path Computation ✨
In this section, the synchronous approach is provided to compute primary and secondary paths simultaneously. Two paths at once, bestie 👯♀️
6.1. Disjoint VSPT 💅
The BRPC procedure constructs a VSPT to inform the enquiring PCE of potential paths to the destination node.
In end-to-end diverse path computation, the diversity (or disjointness) information among the potential paths must be preserved in the VSPT, so that an end-to-end disjoint path is ensured. To preserve that diversity (or disjointness) information, disjoint VSPTs are sent in the PCEP PCRep message. A PCReq containing an SVEC object with the appropriate diverse flag set would signal that the PCE should compute a disjoint VSPT.
A disjoint VSPT is defined as a collection of VSPTs, where each VSPT contains a potential set of primary and secondary paths.
Okay, so here's an example network 🗺️ (Figure 2). Transit nodes in the domains aren't depicted, and PCE1 and PCE2 may be located in border nodes. In this network, there are three VSPTs for the potential set of diverse paths, shown in Figure 3, when the primary path and secondary path are requested from S1 to D1. These VSPTs consist of a disjoint VSPT, which is indicated in a PCRep to PCE1. When receiving the disjoint VSPT, PCE1 recognizes the disjoint request and the disjoint VSPT information. PCE1 will then continue to process the request and compute the diverse path using the BRPC procedure [RFC5441]. Encoding for the disjoint VSPT is described in Section 6.2.
Domain1 Domain2
+----------+ +----------+
| PCE1 | | PCE2 | S1: Source node
| BN1---BN4 | D1: Destination node
| S1 BN2---BN5 D1 | BN1-BN6: Border nodes
| BN3---BN6 |
+----------+ +----------+
Figure 2. Example Network for Diverse Path Computation VSPT1: VSPT2: VSPT3:
D1 D1 D1
/ \ / \ / \
BN4 BN5 BN4 BN6 BN5 BN6
Figure 3. Disjoint VSPTs from PCE2 to PCE16.2. Disjoint VSPT Encoding 🎀
Encoding for the disjoint VSPT follows the definition of PCEP message encoding in [RFC5440]. Same rules, no drama 🙌
The PCEP PCRep message returns a disjoint VSPT as <path list> for each RP object (Request Parameter object). The order of <path> in <path list> among <responses> implies a set of primary Explicit Route Objects (EROs) and secondary EROs. Order matters, babe 📋
A PCE sending a PCRep with a disjoint VSPT can reply with a partial disjoint VSPT based on its network operation policy, but the order of <path> in <path list> must be aligned correctly.
If confidentiality is required between domains, the path key mechanism defined in [RFC5520] is used for a disjoint VSPT. 🔐
Below are the details of the disjoint VSPT encoding (in Figure 3), when a primary path and a secondary path are requested from S1 to D1. 👀
o Request ID #1 (Primary)
- ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO3 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
o Request ID #2 (Secondary)
- ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO6 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]6.3. Path Computation Procedure 🧠
For end-to-end diverse path computation, the same mode of operation as the BRPC procedure can be applied (i.e., Step 1 to Step n in Section 4.2 of [RFC5441]). A question that must be considered is how to recognize disjoint VSPTs.
Recognition of disjoint VSPTs is achieved by the PCE sending a PCReq to its neighbor PCE, which maintains the path computation request (PCReq) information. If the PCReq has one or more SVEC object(s) with the appropriate dependency flags, the received PCRep will contain the disjoint VSPT. If not, the received VSPT is a normal VSPT based on the shortest path computation.
Note that the PCE will apply a suitable algorithm for computing requests with disjoint VSPTs. The selection and application of the appropriate algorithm is out of scope in this document. That's a whole other spell 🪄
7. Manageability Considerations 🌷
This section describes manageability considerations specified in [PCE-MNG-REQS].
7.1. Control of Function and Policy 💜
In addition to [RFC5440], PCEP implementations should allow the PCC to be responsible for mapping the requested paths to computation requests. The PCC should construct the SVECs to identify and associate SVEC relationships.
7.2. Information and Data Models (MIB Modules) 📚
There are currently no additional parameters for MIB modules. There would be value in a MIB module that details the SVEC association. This work is currently out of scope of this document.
7.3. Liveness Detection and Monitoring 👀
The associated SVEC in this document allows PCEs to compute optimal sets of diverse paths. This type of path computation may require more time to obtain its results. Therefore, it is recommended for PCEP to support the PCE monitoring mechanism specified in [RFC5886]. Keep an eye on those timers, bestie ⏱️
7.4. Verifying Correct Operation ✅
[RFC5440] provides a sufficient description for this document. There are no additional considerations.
7.5. Requirements on Other Protocols and Functional Components 🧩
This document does not require any other protocol and functional components.
7.6. Impact on Network Operation 🌐
[RFC5440] provides descriptions for the mechanisms discussed in this document. There is value in considering that large associated SVECs will require greater PCE resources, compared to non-associated SVECs. Additionally, the sending of large associated SVECs within multiple PCReq messages will require more network resources. Solving these specific issues is out of scope of this document. Big SVEC energy, big resource bill 💸
8. Security Considerations 🔐💅
okay bestie, this section is SERIOUS but also kind of iconic. 😭 So here's the tea: this document only describes how the SVEC list gets used. It doesn't add any extensions to PCEP 🎀 The security of everything in here depends on PCEP [RFC5440], so that's the foundation we're building on. ✨
BUT, and this is a big but, a PCE that supports associated SVECs might be open to Denial-of-Service (DoS) attacks from a rogue PCC. 💀 Like, a PCE could get forced to queue up a huge pile of requests while it waits for other requests that are never gonna show up. 🙈 And someone could also make a PCE try to compute really, really complicated associated SVEC stuff. Not it! 🫠
To mitigate these DoS attacks, the move is to use practical SVEC list limits, plus these three things:
- Applying provisioning to PCEs, for example by setting a limit on the number of simultaneous services. This one is recommended. 🎀
- Using a priority-based multi-queuing mechanism, where path computation requests with a smaller SVEC list get prioritized for path computation processing. Smol requests first, periodt. 🍓
- Specifying which PCCs are allowed to request large SVEC associations through PCE access policy control. 👑
9. References 📚
9.1. Normative References 🧠
- [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
- [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
- [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
- [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
- [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, 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 Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009.
- [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009.
9.2. Informative References 💡
- [H-PCE] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS", Work in Progress, December 2009.
- [PCE-MNG-REQS] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, July 2009.
- [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010.
- [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.
10. Acknowledgements 🫶
The authors would like to thank Adrian Farrel, Julien Meuric, and Filippo Cugini for their valuable comments. 💖
Authors' Addresses 🏡
Itaru Nishioka NEC Corp. 1753 Shimonumabe, Kawasaki, 211-8666, Japan
Phone: +81 44 396 3287 EMail: i-nishioka@cb.jp.nec.com
Daniel King Old Dog Consulting United Kingdom
Phone: +44 7790 775187 EMail: daniel@olddog.co.uk
📦 where this page comes from
- ietf: rfc6007 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms