RFC 7399

Unanswered Questions in the Path Computation Element Architecture

📅 published October 2014, from ietf

RFC 7399: Unanswered Questions in the Path Computation Element Architecture 🎀

okay bestie, here's the vibe check on this one 💅

Request for Comments: 7399
Title: Unanswered Questions in the Path Computation Element Architecture
Authors: A. Farrel (Juniper Networks) and D. King (Old Dog Consulting)
Category: Informational (so it's not a standard, just for info) 🦋
ISSN: 2070-1721
Date: October 2014
Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates, and the Abstract says it does not update the architecture documents 🌸

Abstract ✨

okay so the Path Computation Element (PCE) architecture got its origin story in RFC 4655 🌸. then it got a glow-up for multi-layer networking with the Virtual Network Topology Manager (VNTM) in RFC 5623, and it got generalized to Hierarchical PCE (H-PCE) in RFC 6805 🔥.

these three architectural views of PCE deliberately leave some key questions unanswered 🙈, especially about how the architectural components interact with each other. this document pulls those questions out and talks through them in an architectural context, looking at other architectural components, existing protocols, and recent IETF efforts 💜.

the document does not update the architecture documents, and it does not define how protocols or components have to be used 🫶. what it does do is suggest how the architectural components might be combined to unlock advanced PCE function ⭐.

Status of This Memo 💅

this one is not an Internet Standards Track specification. it's published purely for informational purposes ✨.

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🧚.

want the current status, any errata, or a way to send feedback? head to http://www.rfc-editor.org/info/rfc7399 🦋.

Copyright Notice 🌈

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 in effect on the date of publication. please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈. any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🔥.

Table of Contents 🦋

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. What Is Topology Information? ...................................4
   3. How Is Topology Information Gathered? ...........................5
   4. How Do I Find My PCE? ...........................................6
   5. How Do I Select between PCEs? ...................................7
   6. How Do Redundant PCEs Synchronize TEDs? .........................8
   7. Where Is the Destination? .......................................9
   8. Who Runs or Owns a Parent PCE? .................................10
   9. How Do I Find My Parent PCE? ...................................11
   10. How Do I Find My Child PCEs? ..................................11
   11. How Is the Parent PCE Domain Topology Built? ..................12
   12. Does H-PCE Solve the Internet? ................................12
   13. What are Sticky Resources? ....................................13
   14. What Is a Stateful PCE for? ...................................14
   15. How Is the LSP-DB Built? ......................................14
   16. How Do Redundant Stateful PCEs Synchronize State? .............15
   17. What Is an Active PCE? What Is a Passive PCE? .................16
   18. What is LSP Delegation? .......................................17
   19. Is an Active PCE with LSP Delegation Just a Fancy NMS? ........18
   20. Comparison of Stateless and Stateful PCE ......................18
   21. How Does a PCE Work with a Virtual Network Topology? ..........19
   22. How Does PCE Communicate with VNTM ............................21
   23. How Does Service Scheduling and Calendering Work? .............21
   24. Where Does Policy Fit In? .....................................22
   25. Does PCE Play a Role in SDN? ..................................23
   26. Security Considerations .......................................23
   27. References ....................................................25
      27.1. Normative References .....................................25
      27.2. Informative References ...................................25
   Acknowledgements ..................................................29
   Authors' Addresses ................................................29

1. Introduction ✨

so the Path Computation Element (PCE) architecture was written down in [RFC4655], and a lot of new people have joined the PCE working group since then and want to use or understand it 🌸. a lot of them missed the early discussions in the group, so they don't know about the questions that came up while the documentation was being written 🙈.

the base architecture has also been extended to handle other situations and requirements. it got extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) [RFC5623], and it got generalized to include Hierarchical PCE (H-PCE) [RFC6805] 🔥.

the document does not update the architecture documents, and it does not define how protocols or components have to be used 🫶. it does, however, suggest how the architectural components might be combined to provide advanced PCE function ⭐.

1.1. Terminology 🧚

readers are assumed to be thoroughly familiar with the terminology defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], and [RFC6805] 📚. if you want more on terms related to stateful PCE, check [STATEFUL-PCE] 💖.

throughout this document, the term "area" is used to refer equally to an OSPF area and an IS-IS level. it's assumed you can map the small differences between those two use cases yourself 💅.

2. What Is Topology Information? 💜

okay so [RFC4655] says a PCE does its path computations based on a view of the available network resources and network topology 🧠. all of that info gets collected into a Traffic Engineering Database (TED) 🗂️.

but [RFC4655] doesn't go super deep on what's actually in the TED 🙈. it just says that the TED "contains the topology and resource information of the domain." what has to be in a TED really depends on the type of network and the kind of computation being done 💅. as a basic minimum, the TED has to hold the nodes and links that form the domain, and it has to identify the connectivity in the domain 🔥.

for most traffic-engineering needs (for example, MPLS Traffic Engineering - MPLS-TE), the TED would also contain a basic metric for each link, plus knowledge of the available (unallocated) resources on each link ✨.

more advanced use cases might need the TED to hold extra data that's more qualitative, such as:

link delay
link jitter
node throughput capabilities
optical impairments
switching capabilities
limited node cross-connect capabilities

there's also an important info element for computing paths, especially for protected services: the Shared Risk Group (SRG) 🫶. this shows which resources in the TED have a common risk of failure. in other words, they share a risk of failing from a single event 💀.

in short, the TED needs to contain as much information as it takes to satisfy path computation requests, subject to the objective functions (OFs) 👑. that alone can be a non-trivial problem in some network technologies 😭. for example, in some optical networks, computing a path for a new Label Switched Path (LSP) may mean considering how turning up a new laser would affect the optical signals already riding the fibers 🌈. that info might be abstracted as parameters of the optical links and nodes in the TED, but it could be easier to capture it through a database of existing LSPs (see Sections 14 and 15) 🦋.

3. How Is Topology Information Gathered? 🌸

clearly the info in the TED we talked about in Section 2 has to be gathered and maintained somehow 🧚. [RFC4655] just says "The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means." in this context, "fed" means built and maintained 🍓.

so one way the PCE can build its TED is by participating in the IGP running in the network 💜. in an MPLS-TE network, that would depend on OSPF TE [RFC3630] and IS-IS TE [RFC5305] 🔥. in a GMPLS network, it would use the GMPLS extensions to OSPF and IS-IS, [RFC4203] and [RFC5307] ✨.

but participating in an IGP, even as a passive receiver of IGP info, can put a serious load on the PCE 😭. the IGP can get super "chatty" when the use of the network changes often, which means the PCE has to dedicate a lot of processing to parsing protocol messages and updating the TED 💀. and to be truly useful, a PCE implementation would also need to support OSPF and IS-IS 🙈.

an alternative feed from the network to the PCE's TED is BGP-LS [LS-DISTRIB] 🫶. this lets you use an in-network BGP speaker (like an Autonomous System Border Router or a Route Reflector) that already has to participate in the IGP and is specifically built to filter IGP advertisements 🧠. the BGP speaker filters and aggregates topology info according to configured policy, then advertises it "north-bound" to the PCE to update the TED 🗂️. the PCE implementation only has to support a simplified subset of BGP instead of two full IGPs 👑.

but BGP might not be convenient in every network (for example, where BGP isn't run, like in an optical network or a BGP-free core) 🙈. plus, not all the relevant info is available through standard TE extensions to the IGPs 💅. in those cases, the TED has to be built or supplemented from other sources, such as the Network Management System (NMS), inventory management systems, and directly configured data 🌈.

it's also been proposed that the PCE Communication Protocol (PCEP) [RFC5440] could be extended to act as an information collection protocol, supplying info from network devices to a PCE 🦋. the logic is that network devices may already speak PCEP, so the protocol could easily be used to report details about the resources and state in the network, including the LSP state we'll get into in Sections 14 and 15 💖.

and note that a PCE responsible for more than one domain has to collect TE information from each domain to build its TED or TEDs 🫶💜

4. How Do I Find My PCE? ✨

okay so a Path Computation Client (PCC) needs to know who and where its PCE is before it can even ask for anything 🧚 bc PCEP is a transaction-based protocol carried over TCP, and the architecture from Section 6.4 of RFC 4655 means PCC-PCE chats have to be targeted 💅

As described in [RFC4655], a PCC could be configured with its PCE's IP address. ngl this is pretty lightweight compared to everything else a router already has to be configured with 🎀 but it's super open to typos and config errors 🙈 and it doesn't hit the minimal-configuration vibe we want. Plus, configuring talks with multiple PCEs gets onerous fast, and if PCE identities change or something fails, a configured system has a hard time keeping up 💀

[RFC4655] lets PCEs advertise themselves in the IGP 🦋 this was developed in [RFC4674] and made possible in OSPF and IS-IS through [RFC5088] and [RFC5089]. Generally, these mechanisms are enough for PCCs in a network that runs an IGP, where the PCE is part of that IGP too 🫶

Note, however, that not every PCE will participate in the IGP (see Section 3) 😭 In those cases, configuration isn't a good discovery method, so some other server announcement/discovery function might be needed. Examples are DNS [RFC4848], which is used to find the Local Location Information Server (LIS) [RFC5986], and the Application-Layer Traffic Optimization (ALTO) discovery function [ALTO-SERVER-DISC] 🌈

5. How Do I Select between PCEs? 👑

when more than one PCE is discovered or configured, the PCC has to pick one 💖 it can use any arbitrary algorithm (like first-listed or round robin), but it's also possible that different PCEs have different capabilities and path computation scope 👀 in that case, the PCC will want the PCE most likely to handle any given request. The first requirement, obviously, is that the PCE can compute paths for the relevant domain 💅

PCE advertisement in OSPF or IS-IS per [RFC5088] and [RFC5089] lets a PCE announce its capabilities as required in [RFC4657], and a PCC can pick between PCEs based on what they've announced ✨ BUT these capabilities are expressed as flags in the PCE advertisement, so only the core capabilities show up 🙈 there's no room for detailed stuff (like support for specific objective functions) in the advertisement.

More complex PCE capabilities, including the ability to do point-to-multipoint (P2MP) path computations [RFC6006], can be announced by the PCE as optional PCEP type-length-value (TLV) Type Indicators in the Open message described in [RFC5440] 🦋 this isn't limited to flags, so detailed capability info can be sent in sub-TLVs 🎀

Note that this capability exchange is an announcement, not a negotiation 😤 So a PCC that wants a specific function from a PCE has to look at the advertised capabilities and pick the PCE that fits that specific request. There's no way for a PCC to ask a PCE to support features or functions it doesn't offer or announce. not me being like "just support it bestie" and the PCE going "no" 💀

A PCC may also change which PCE it uses based on congestion info the PCEs report using the Notification Object and Notification Type [RFC5440]. But here's the tea 🫠 in a heavily overloaded PCE system, if one PCE says it's overloaded, all the PCCs might switch to another PCE, which then becomes overloaded immediately 😭 So PCCs should use a certain amount of discretion and queueing theory 🧠 before picking a PCE based purely on reported load.

Note that a PCC could send all its requests to every PCE it knows about 🌸 then it can pick between the results, maybe just going with the first one it gets back. BUT this is very likely to overload all the PCEs in the network 💀 which is kinda the whole opposite of why you have multiple PCEs in the first place, since one of the reasons is to share the load 😩

6. How Do Redundant PCEs Synchronize TEDs? 🔥

A network can have more than one PCE, as the previous sections talked about 🌈 These PCEs might give you redundancy for load-sharing, resilience, or partitioning of computation features.

To get some consistency between the results of different PCEs, it's desirable that they work from the same TE information 🫶

The TED reflects the actual state of the network. It's not a resource reservation or booking scheme 📋 So a PCE-based system doesn't stop competition for network resources during the provisioning phase. Still, a "sticky resources" process, where resources are temporarily reduced in the TED after a computation, can be applied purely as a local implementation feature ✨

One option for making sure multiple PCEs use the same TE information is just to drive all of the PCEs from the same TED 💜 In implementations, this could be done with a shared database, but it's unlikely to be efficient 😬

What's more likely is that each PCE builds its own TED independently, using the techniques from Section 3 🦋 If the PCEs participate in the IGP, they'll probably attach at different points in the network, so there may be minor and temporary inconsistencies between their TEDs caused by IGP convergence issues 🌀 If the PCEs gather TE information via BGP-LS [LS-DISTRIB] from different sources, the same inconsistencies may show up. However, if the PCEs attach to the same BGP speaker, it may be possible to get consistency between TEDs, modulo the BGP-LS process itself 🎀

A final option is an explicit synchronization process between the TED of a "master" PCE and the TEDs of the other PCEs. This could be done with BGP-LS or a database synchronization protocol (which would allow check-pointing and sequential updates) 🧚 But this approach is fraught with issues around selecting the master PCE and handling failures 😵 It's basically a mirrored database scenario, which is a well-known problem with plenty of work already out there 📚

Here's the thing though 💅 provisioning protocols like RSVP-TE [RFC3209] already handle contention for resources. Also, the differences between TEDs are likely to be pretty small with moderate arrival rates for new services, and contention in all but the busiest networks is relatively unlikely. So there may be no value in any attempt to synchronize TEDs between PCEs 🙌

However, see Section 16 for a discussion of synchronizing other state between redundant PCEs 🫶

7. Where Is the Destination? 🗺️

Path computation gives you an end-to-end path between a source and a destination 🦋 If the destination is in the source domain, the PCE will know where it is and there are no issues to solve. But in a multi-domain system, a path has to be found to a remote domain that contains the destination, and that's only possible if you know where the destination is, or at least know the next domain on the path toward the domain that has it 😳

The simplest solution is when a PCE can see into multiple domains. This might be the case in a multi-area network where the PCE is aware of the contents of all of the IGP areas. This approach is only likely to be appropriate where the number of nodes is manageable, and it's unlikely to extend over administrative boundaries 🚧

The per-domain path computation method for establishing inter-domain traffic engineering LSPs [RFC5152] just requires a PCE to compute a path to the next domain toward the destination 🎀 As LSP setup (through signaling) moves domain by domain, the Label Switching Router (LSR) at the entry point to each domain asks its local PCE to compute the next segment of the path, which is from that LSR to the next domain in the sequence toward the destination 💖 So no PCE (except the last one) needs to know which domain the destination is in 🙌 BUT in this approach, each PCE has to somehow figure out the next domain toward the destination, and it's not obvious how that happens 😩

[RFC5152] suggests that, in an IP/MPLS network, it's good enough to use the IP reachability info distributed by BGP and assume TE reachability can follow the same Autonomous System (AS) path 🌸 This might not guarantee the optimal TE path and, of course, might result in no path being found in degenerate cases 💀 Also, in many network technologies (like optical networks operated by GMPLS), there may be limited or no end-to-end IP connectivity 🫠

The Backward Recursive PCE-based Computation (BRPC) procedure [RFC5441] can get a more optimal end-to-end path than the per-domain method 👑 but it depends on knowing both the domain where the destination is located and the sequence of domains toward it. [RFC5441] describes this information as being known a priori. Clearly, though, that info isn't always known a priori, and it may be hard for the PCE serving the source PCC to discover the necessary details 🥺 There are a few ways to figure out the domain sequence (for example, BRPC trial and error, or H-PCE [RFC6805]), but none of them address how to determine where the destination lies 🤷‍♀️

A common argument is that an end-to-end connection expressed as an LSP is a feature of a service agreement between source and destination. If that's true, the argument goes, the location of the destination must be known to the source node in the same way the source figured out the destination's IP address 💅 Presumably, that would happen through a commercial process or an administrative protocol 📄

[RFC4974] introduced the concept of Calls and Connections for LSPs ✨ A Call doesn't provide the actual connectivity for sending user traffic. It builds a relationship that allows subsequent Connections to be made. A Call might be considered an agreement to support an end-to-end LSP made between the endpoint nodes 🫶 Call messages are sent and routed as normal IP messages, so the sender doesn't need to know where the destination is 🦋

Also, Call requests get responded to, and the Call Response can carry info (such as the identity of the domain containing the destination) for the Call initiator to use 🎀 So GMPLS Calls might give us a way to discover the destination's location 🌈 okay that's the vibe, bestie 💜

8. Who Runs or Owns a Parent PCE? 👑

okay so a parent PCE [RFC6805] is the one in charge of selecting inter-domain path 💅 by coordinating with its child PCEs and keeping a domain topology map 🗺️

if you're dealing with multi-domains (e.g., IGP areas or multiple ASes) inside one service provider network, the service provider is most likely the one managing the parent PCE 🏢

now if you've got multiple ASes spread across different service provider networks, a third party may need to manage the parent PCEs, based on the commercial and policy agreements from each participating service provider 🤝 and the H-PCE architecture doesn't require disclosing the internals of a child domain to the parent PCE 🙈 so there's loads of room for a parent PCE to be run by one of the connected service providers or by a third party without any commercial issues getting messy 🫶 honestly, each service provider could run its own parent PCE while letting its child PCEs be contacted by outside parent PCEs, according to configured policy and security 🔐 iconic 😭

9. How Do I Find My Parent PCE? 🧭

so [RFC6805] says a child PCE has to be configured with the address of its parent PCE so they can actually talk to each other 📮 there's no way for parent PCEs to advertise that they exist 🙅‍♀️ but directory systems could be used, like DNS [RFC4848] as used in the ALTO discovery function [ALTO-SERVER-DISC], as described in Section 4 🔍

also, per [RFC6805], the child PCE must also be authorized to peer with the parent PCE 🎟️ we'll look at this from the parent PCE's side in Section 10 👀 and the child PCE may need to take part in a key distribution protocol so it can properly authenticate its identity to the parent PCE 🗝️ bestie that's a whole vibe

10. How Do I Find My Child PCEs? 🧚

within the hierarchical PCE framework [RFC6805], the parent PCE must only accept path computation requests from authorized child PCEs 🚫 if a parent PCE gets a request from an unauthorized child PCE, the request should be dropped 🗑️ no cap, that's a hard boundary

this means a parent PCE has to be configured with the identities and security credentials of all of its child PCEs 🪪 or there has to be some form of shared secret that lets an unknown child PCE get authorized by the parent PCE 🤫 literally the security main character energy 💜

11. How Is the Parent PCE Domain Topology Built? 🏗️

the parent PCE keeps a domain topology map of the child domains and how they're interconnected 🌸 this map doesn't include any visibility into the child domains 👁️‍🗨️ and where inter-domain connectivity is provided by TE links, the parent PCE may also know the capabilities of those links ✨

the parent PCE keeps a TED for the parent domain in the same way that any PCE does 💅 the nodes in the parent domain are going to be abstractions of the child domains (connected by real or virtual TE links), but the parent domain may also include real nodes and links 🦋

building the parent TED is probably going to lean really heavily on administrative configuration and commercial issues 💼 which makes sense because the network was likely split into domains specifically to deal with those things 🙃 still, in some configurations (for example, collections of small optical domains), a separate instance of a routing protocol (probably an IGP) may be run within the parent domain to advertise the domain interconnectivity 📡 also, inter-domain TE links can be advertised by the IGPs running in the child domains, so that info could get exported to the parent PCE either by the child PCEs or through a north-bound export mechanism like BGP-LS [LS-DISTRIB] 🚀

12. Does H-PCE Solve the Internet? 🌐

ngl the hierarchical relationship between domains was introduced by the model in [RFC6805] 💖 it's a fit for environments with small groups of domains where visibility from the ingress LSRs is limited 🎯 applying the hierarchical PCE model to large groups of domains such as the Internet is not considered feasible or desirable 🙅‍♀️ sorry internet, not this time 😭

now that opens up a harder question: how many domains can an H-PCE system handle? 🤔 like, what even counts as a small group of domains? the answer isn't clear and might be "I know it when I see it." 👀 for now, a rough guide might be around 20 domains as a maximum 🔢

and then there's the question of how many hierarchy levels H-PCE can handle 🪜 architecturally, the answer is that there's no limit, but it's hard to come up with practical examples where more than two or possibly three levels are needed 🧠 iykyk

13. What are Sticky Resources? 📌

when a PCE computes a path, it has a pretty good idea that an LSP will be set up and that resources will get allocated within the network 🛠️ if computation requests come in faster than the LSP setup rate combined with the IGP convergence time, it's quite possible that the PCE will do its next computation before the TED has been updated to reflect the setup of the previous LSP 😬 that can lead to LSP setup failures if there's contention for resources 💀 this is especially likely during recovery from network failures, when a large number of LSPs might need new paths 🌪️

so a PCE may choose to make a provisional assignment of the resources an LSP would need, and reduce the available resources in its TED to help mitigate the problem ✨ these resources are informally called "sticky resources" 📌

but using sticky resources brings a bunch of other problems that can make managing the TED difficult 🥴 for example:

when the TED gets updated because of new information from the IGP, how does the PCE know whether the reduction in available resources is due to the successful setup of the LSP it's holding sticky resources for, or due to some other network event (such as the setup of another LSP)? this problem may be especially obvious if there are multiple PCEs that don't synchronize their sticky resources, or if not all LSPs use PCE computation 🙃
when LSP setup fails, how are the sticky resources released? the PCE doesn't know about the LSP setup failure, so it needs some other mechanism to release them 😵
what happens if a path computation was made only to investigate the potential for an LSP, but not to actually set one up? 🤷‍♀️
what if the path used by the LSP doesn't match the one the PCE provided (for example, because the control plane routes around some problem)? 🚧

some of these issues can be mitigated by using a Stateful PCE (see Section 14) or by timers ⏰

14. What Is a Stateful PCE for? 🗃️

a Stateless PCE can perform path computations that take into account the existence of other LSPs, as long as the paths of those LSPs are supplied on the computation request 🧩 this is super useful when arranging protection paths so that a working LSP and a protection LSP don't share any links or nodes 🛡️ it can also be used when a group of LSPs are going to be reoptimized at the same time, in the process known as Global Concurrent Optimization (GCO) [RFC5557] ✨

however, this mechanism can be quite a burden on the protocol messages, especially when large numbers of LSP paths need to be reported 📦😩

a Stateful PCE [STATEFUL-PCE] maintains a database of LSPs (the LSP-DB) that are active in the network, meaning they've been provisioned so they use network resources, even if they might or might not be carrying traffic 🗄️ this database lets a PCC refer to an LSP using only its identifier, because all the other details can be retrieved by the PCE from the LSP-DB 🪪 slay

a Stateful PCE can use the LSP-DB for lots of other functions too, like balancing the distribution of LSPs across the network ⚖️ the PCE can also correlate LSPs with network resource availability, so it places new LSPs more cleverly 🧠

a Stateful PCE that is also an Active PCE (see Section 17) can respond to changes in network resource availability and predicted demands by rerouting the LSPs it knows about 🔁

Section 20 offers a brief comparison of the different modes of PCE, with reference to stateful and stateless PCE 📊

15. How Is the LSP-DB Built? 🧱

the LSP-DB holds information about the LSPs that are active in the network, as mentioned in Section 14 💖 the PCE can build this state information from info it gets from a bunch of sources, including provisioning tools and the network itself 🛰️ but no matter how the info is gleaned, a Stateful PCE needs to synchronize its LSP-DB with the state in the network 🔄 just like Section 13 said, the PCE can't rely on knowledge of its previous computations, it has to find out the actual LSPs in the network 🕵️‍♀️

a simple solution is for all ingress LSRs to report all LSPs to the PCE as they're set up, modified, or torn down 📣 since PCEP already has the facility to fully describe LSP routes and resources in its protocol messages, this isn't a difficult problem, and the LSP State Report (PCRpt) message has been defined for exactly this purpose [STATEFUL-PCE] 🎀

it gets more complex, though, if there are ingress LSRs that don't support PCEP, support PCEP but not the PCRpt, or are unaware of the requirement to report LSPs to the PCE 😩 this might happen if the LSRs can compute paths themselves, or if they receive LSP setup instructions with pre-computed paths from an NMS 🙈

another approach is to notice that any LSR on the path of an LSP can probably see the whole path (through the Record Route object in RSVP-TE signaling [RFC3209]) and knows the bandwidth reserved for the LSP 🦋 so any LSR could report the LSP to the PCE, and it won't hurt (beyond additional message processing and potential overload of the PCE or the network) for the LSP to be reported multiple times, because it's clearly identified 💅 honestly this would also give you a cross-check mechanism, which is so smart 🧠✨

still, it's possible that some LSPs will only traverse LSRs that aren't aware of the PCE's need to learn LSP state and build an LSP-DB 😶 in those cases, the Stateful PCE either has to have only limited knowledge of the LSPs in the network, or it has to learn about LSPs through some other mechanism (such as reading the MPLS and GMPLS MIB modules [RFC3812] [RFC4802]) 📚

ultimately, there may be no substitute for all LSRs being aware of Stateful PCEs and able to respond to requests for reports on all LSPs they know about 🌈 this lets a Stateful PCE build its LSP-DB from scratch (which it may need to do at start of day), and verify its LSP-DB against the network (which may be important if the PCE has suffered some form of outage) 🫶

16. How Do Redundant Stateful PCEs Synchronize State? ✨

Okay so, two PCEs running in the same network need to have a similar view of what resources are available 👀. Basically they should have the same TEDs, or at least super similar ones 💖. That's honestly pretty easy to get: either both PCEs build their TEDs from the network in the same way, or one PCE copies its TED from the other using a TED export protocol like BGP-LS [LS-DISTRIB] or the Network Configuration Protocol (NETCONF) [RFC6241] (see Section 6) 🎀.

Syncing the LSP-DB is trickier, ngl 😭. As we covered in Section 15, building an LSP-DB is a whole process, so it's best if multiple PCEs don't each try to build one from the network 🙅‍♀️. BUT, where several PCEs are running (either as distributed PCEs or with one acting as a backup for the other), their LSP-DBs still need to stay in sync 🫶.

So there's probably going to be a need for some protocol mechanism that lets one PCE update its LSP-DB using another PCE's. This is just a normal database-synchronization problem 🧚, and it could use existing mechanisms or a brand-new protocol. One twist though: when distributed PCEs are also Active PCEs (see Section 17), each one is creating entries in its own LSP-DB 🔥. That means the sync has to be incremental and bidirectional, not just a database dump 💅.

It helps to clarify what "redundant" means here 🤔. One take is that a redundant PCE only exists as a backup, so it only does anything if the primary PCE fails 😴. Honestly that sounds like a waste of expensive gear, and it'd make way more sense for the redundant PCE to share the computation load all the time ✨. The catch is that having two (or more) active PCEs creates exactly that state synchronization problem we just talked about 💀.

People have also suggested setups where one PCE is the main computation server for a group of PCCs, and only handles requests from other PCCs if some other PCE fails 🌸. Even so, this still raises questions about needing synchronized state when nothing has failed, if the LSPs computed by the different PCEs might go through the same network resources 👑.

17. What Is an Active PCE? What Is a Passive PCE? 🦋

A Passive PCE is the chill one 😌. It only responds to path computation requests and takes no autonomous actions at all 💜. A Passive PCE may be stateless or stateful.

An Active PCE is the one that's a little more proactive 🔥. It issues provisioning "recommendations" to the network, which might be new routes for existing LSPs or routes for brand-new LSPs (so an Active PCE may recommend instantiating new LSPs 🌈). An Active PCE may be stateless or stateful. But if it wants to reroute existing LSPs effectively, it's likely to hold state for at least the LSPs it's going to reroute 🧠.

Plenty of people think the PCE itself can't be Active 🙅‍♀️. In their view, a PCE's whole job is just computing paths. In that worldview, the "Active PCE" is really a regular passive PCE combined with a separate architectural component that's in charge of issuing commands or recommendations to the network 🎀.

In some setups, the VNTM (discussed in Sections 21 and 22) is what provides that extra component ✨.

Section 20 gives a quick comparison of the different PCE modes, looking at passive and active PCE 💅.

18. What is LSP Delegation? 🎀

LSP delegation [STATEFUL-PCE] is when a PCC (usually an ingress LSR) hands over responsibility for triggering updates to an LSP's attributes, like its bandwidth or path, to the PCE 🫶. For that to work, the PCE has to be both Stateful and Active 👑.

Delegation lets an LSP get set up under the control of the ingress LSR, and that LSR can use a PCE's services while it's doing it 🧚. Once the LSP is up, the LSR (which is a PCC) tells the PCE about it by sharing the path details and the resources it's using 📡. Then it delegates responsibility for that LSP to the PCE, so the PCE can make adjustments whenever the TED changes or the policies at the PCE say so 🔥. When the PCE wants to make a change, it sends a new path to the LSR along with the instruction/recommendation that the LSP be re-signaled 💖.

Here's the tea ☕: there's some debate about whether the PCE actually "owns" the LSP after delegation 🤔. Like, if the PCE hands over a new path, does the ingress LSR have to act on it, or can it just take the info "under advisement"? It might be too early to answer that definitively 😭. Still, there's definitely an expectation that the LSR will act on the advice it gets 🌸. It's kind of like going to the doctor: the doctor expects you to take the medicine, but you still have free will 💀.

It's important, though, to tell apart an LSP that was set up in the network and later delegated to a PCE from an LSP that got created because an Active PCE recommended instantiating it 🦋.

Section 20 gives a quick comparison of the PCE modes, this time looking at LSP delegation 💜.

19. Is an Active PCE with LSP Delegation Just a Fancy NMS? 🤭

Ngl, in a lot of ways the answer is "yes" 😂. But the PCE architecture is part of a whole new way of thinking about network operation and management ✨. In this new view, the network runs more dynamically and is controlled by software applications, without operators having to step in directly all the time 🌈. That doesn't mean the operator has no say, though 🫶. It means the operator sets policies (see Section 24), and new components (like an Active PCE) are responsible for acting on those policies to control the network dynamically 👑.

There's a subtle difference between an NMS and an Active PCE with LSP delegation 🧐. An NMS is in charge of the LSPs in the network, and it can command that they get set up, modified, or torn down 💅. An Active PCE can only make suggestions about LSPs that a PCC has delegated to it, or make recommendations for instantiating new LSPs 🦋.

If you want the full picture, check out the discussion of an architecture for Application-Based Network Operation (ABNO) in [NET-OPS] 🌸.

20. Comparison of Stateless and Stateful PCE 📊

Table 1 compares stateless and stateful PCEs 💖. It shows how they might be instantiated as passive or active PCEs, with or without control of LSPs 🎀. The terms used tie back to the concepts from the previous sections, and the entries in the table point to the notes that come after it 🔥.

                        | Stateless |  Stateful |
------------------------+-----------+-----------+
Passive                 |     1     |     2     |
Active delegated LSPs   |     3     |     4     |
Active suggest new LSPs |     5     |     6     |
Active instantiate LSPs |     7     |     7     |

Notes:

Passive is the normal mode for a stateless PCE 😌.
A passive mode stateful PCE may have value for more complex environments and for computing protected services 🛡️.
Delegation of LSPs to a stateless PCE is relatively pointless, but could add value at moment of delegation 🤷‍♀️.
This is the normal mode for a stateful PCE 💅.
There is only marginal potential for a stateless PCE to recommend new LSPs, because without a view of existing LSPs, the PCE cannot determine when new ones might be needed 🙈.
This mode has potential for recommending the instantiation of new LSPs 🌈.
These modes are out of scope for PCE as currently described. That is, the PCE can recommend instantiation, but cannot actually instantiate the LSPs 🚫.

           Table 1 : Comparing Stateless and Stateful PCE

21. How Does a PCE Work with a Virtual Network Topology? 🦋

okay so a Virtual Network Topology (VNT) is described in [RFC4397] as a set of Hierarchical LSPs that is created (or could be created) in a particular network layer to give the other layers some network flexibility (data links) 💅. the TE topology of a network can be built from TE links that are just data links, from TE links that are supported by LSPs in another layer of the network, or from TE links that could be supported by LSPs ("potential LSPs") that would be set up on demand in another network layer. that third type is called a Virtual TE Link in [RFC5212] 🌸

[RFC5212] also gives a more detailed explanation of a VNT, and it's worth knowing that the network topology in a packet network could be supported by LSPs in a number of different lower-layer networks ✨. for example, the TE links in the packet network could be achieved by connections (LSPs) in underlying Synchronous Optical Network or Synchronous Digital Hierarchy (SONET/SDH) and photonic networks. and because MPLS is hierarchical, the TE links in a packet network may also be achieved by setting up packet LSPs in that same packet network 🧚

a PCE obviously works with the TED, which has info about the TE links in the network 🎀. those links might already be established or they might be virtual TE links. in a simple TED there's no distinction between the types of TE link 🙈. however, there may be advantages to picking TE links based on real data links over ones based on dynamic LSPs in lower layers, because data links may be more stable 💜. but the TE links based on dynamic LSPs may be able to be repaired dynamically, which gives better resilience 🔥. similarly, a PCE may prefer a TE link supported by a data link or an existing LSP instead of a virtual TE link, because the virtual one may need to be set up (which takes time) and that setup could potentially fail 😭. so a PCE might want to use additional metrics or indicators to help it view the TED and pick the right path for LSPs 👑

if a PCE uses a virtual TE link, then some action is needed to establish the LSP that supports that link 🫶. some models (like the one in [RFC5212]) trigger the setup of the lower-layer LSPs on demand during the signaling of the upper-layer LSP. so when the upper layer comes to use the virtual TE link, the upper-layer signaling is paused and the lower-layer LSP gets established ⭐. another view, described in [RFC5623], says that when the PCE computes a path that will use a virtual TE link, it should trigger the setup of the lower-layer LSP to properly create the TE link, so the path it returns is sure to be viable 🌈. this later mode can be extended so the PCE can spot the need for additional TE links and trigger LSPs in lower layers to create them 💖

of course, this kind of "interference" in a lower-layer network by a PCE responsible for a higher-layer network depends heavily on policy 🙈. to make a clean architectural separation and to make policy control easier, [RFC5623] introduces the Virtual Network Topology Manager (VNTM) as a functional element that manages and controls the VNT 🍓. [RFC5623] notes that the PCE and the VNT Manager are distinct functional elements that may or may not be collocated. indeed, there will be a PCE for the upper layer, a PCE for each lower layer, and a VNTM responsible for coordinating between the PCEs and for triggering LSP setup in the lower layers. so all the PCEs and the VNTM together end up working functionally similar to an Active, multi-layer PCE 🔥

see [TE-INFO] for more discussion on building networks with virtual and potential links 📚

22. How Does PCE Communicate with VNTM 🗣️

the VNTM from Section 21 and [RFC5623] has several interfaces (see also [NET-OPS]) 💅.

in order to decide whether to create new TE links, the VNTM needs to learn from the upper-layer PCE about resource shortages and the need for more TE links. then it can make policy-based decisions about whether to create new TE links and how to support them through existing or new LSPs 💖
the VNTM will need to coordinate with the PCEs in the lower layers, but that's just a normal use of PCEP 🧚
the VNTM will need to issue provisioning requests/commands (through the Provisioning Manager described in [NET-OPS]) to the lower-layer networks, so LSPs get set up to act as TE links in the higher layer network 🎀. a bunch of potential protocols exist for this, as described in [NET-OPS]. but it makes a lot of sense for this interface to be the same one an Active PCE uses when providing paths to the network 🫶

23. How Does Service Scheduling and Calendering Work? 📅

LSP scheduling (or calendaring) is when LSPs get planned ahead of time and only set up when they're actually needed ⏰. the challenge is making sure the resources an LSP needed (and that were available when its path was computed) are still available when the LSP actually gets set up. and that has to happen using a mechanism that lets those resources be used in the meantime 😭

earlier discussion of this topic suggested that LSPs should be pre-signaled so each LSR along the path could make a "temporal reservation" of resources. but that approach gets super complicated, since every network node ends up storing multi-dimensional state 🙈

a much easier vibe is a centralized database of resources and LSPs (like the one a Stateful PCE maintains), which can be enhanced with a time-based booking system 💜. if the PCE is also Active, then when it's time for the LSP to be set up (or later, when it's time to tear it down), the PCE can issue recommendations to the network 👑

in a busy network (and why would anyone bother with a scheduling service in a network that isn't busy?) 💅, the computation algorithm can get pretty complex. it may also be necessary to reposition existing or planned LSPs as new bookings come in 🌀

and the booking database holding both the scheduled LSPs and their impact on network resources can get really big 🐘. depending on the implementation, a very important factor in the size of the active database may be the timeslices available in the calendering process ⏳

24. Where Does Policy Fit In? 📜

policy is critical to how a network runs 👑. in a PCE context, it's what controls and manages how a PCE selects network resources for use by different PCEs 🎀

[RFC5394] introduced the idea of PCE-based policy-enabled path computation 🌸. it's based on the Policy Core Information Model (PCIM) [RFC3060] as extended by [RFC3460], and it provides a framework for supporting path computation policy ✨

policy shows up in every part of using a PCE, starting from the very decision to use a PCE to offload computation from the LSRs 🫶

each PCC has to select which computations will be delegated to a PCE 🦋
each PCC has to select which PCEs it will use 💖
each PCE has to figure out which PCCs are allowed to use its services and for which computations 👑
the PCE has to determine how to collect the information in its TED, who to trust for that information, and how to refresh/update it 🧚
each PCE has to determine which objective functions and which algorithms to apply 🔥
inter-domain computations (and H-PCE ones especially) will need to be sensitive to commercial and reliability information about domains and how they interact 💰
Stateful PCEs have to determine what state to hold, when to refresh it, and which network elements to trust for supplying state information 🌈
an Active PCE needs a policy relationship with its LSRs to determine which LSPs can be modified or triggered, and what LSP delegation is supported 💜
multi-layer interactions (especially those using virtual or dynamic TE links) need policy control to stop server layer LSPs (which are fat and expensive by definition 🍔) from being set up on a whim to address micro-flows or speculative computations in higher layers 🙅‍♀️
a PCE may supply policy information along with a computed path, and that information should be signaled during LSP setup for use by the LSRs along the path 🎀

so, it's giving "a PCE is basically a policy engine that computes paths" 💅. also, configured policy can seriously narrow the options available to the PCC, and that can also significantly cut down how many optional parameters are needed in the PCEP messages 🫶

25. Does PCE Play a Role in SDN? 🌐

Software-Defined Networking (SDN) is the latest shiny thing in networking ✨. it separates the control elements from the forwarding components, so software running in a centralized system called a controller can program the devices in the network to behave in specific ways 🧠

a required element in an SDN architecture is a component that plans how network resources get used and how devices get programmed 📋. you can think of this component as doing specific computations to place flows within the network, based on knowing which network resources are available, how other forwarding devices are programmed, and how other flows are routed 🍓. honestly, this is the same function a PCE might offer in a network run on a dynamic control plane 👑. so a PCE could totally form part of the infrastructure for an SDN 🦋

a view of how a PCE fits into a wider network control system (SDN included) is presented in [NET-OPS] 📚💖

26. Security Considerations 🔐💅

okay bestie, this section is SO important and I need you to take it seriously 😭 so, PCE-based architecture and its impact on network security have to be considered alongside the routing and signaling protocols and techniques that already exist 🫶 the whole multi-domain thing, plus setting up relationships between PCCs and PCEs, can make the network more vulnerable to attacks 💀 BUT, and this is the lowkey iconic part, this document is informational and doesn't define any new protocol elements or mechanisms ✨ so it doesn't introduce any new security issues, and security is officially a "previously answered question" 💅 even if the answers we already have aren't perfect 🙈

previous PCE RFCs did put real thought into security 🌸 for PCE itself (RFC 4655), PCE discovery (RFC 4674, RFC 5088, and RFC 5089), and PCEP (RFC 4657 and RFC 5440) 🧚

also, PCEP runs over TCP, so the security issues for routing protocols that use TCP (PCEP included) are analyzed in [RFC6952] 🦋 and [PCE-PCEPS] talks about an experimental way to get secure transport for PCEP 🔥

a bunch of the questions this document raises and answers should be looked at through a security lens 👑 some are called out explicitly (Sections 8 and 10), but security matters for every part of using PCE, so keep your eyes open ✨ for example:

topology and other network information has to stay private and protected from modification or forgery 🔒 so access to the TED, LSP-DB, and so on needs to be secured, and the mechanisms used to gather topology and other information (Sections 2, 11, 14, and 15) need to include security 💖
PCE discovery (Sections 4, 5, 9, and 10) needs to guard against impersonation or misconfiguration 🎀 so PCCs can be sure they're getting correct paths, and PCEs can be sure they only serve legitimate computation requests 🫶
synchronization of information and state between PCEs (Sections 6 and 16) has the same security requirements 💜 the info exchanged is sensitive, so it has to be protected against interception and modification 😭
a PCE computes paths for components that may provision the network 🦋 those components are responsible for the security of the provisioning mechanisms, however, if a PCE operates as a provisioning protocol (Sections 17, 18, 19, and 25) 👑
a PCE may also need to interface with other network components (Sections 19, 21, 22, and 25) 🌈 and if those communications happen outside an implementation, they also need to be secure 🔐

27. References 📚

27.1. Normative References 🧚

[RFC4655]      Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
               Computation Element (PCE)-Based Architecture", RFC
               4655, August 2006,
               <http://www.rfc-editor.org/info/rfc4655>.

[RFC5440]      Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
               Computation Element (PCE) Communication Protocol
               (PCEP)", RFC 5440, March 2009,
               <http://www.rfc-editor.org/info/rfc5440>.

[RFC5623]      Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
               "Framework for PCE-Based Inter-Layer MPLS and GMPLS
               Traffic Engineering", RFC 5623, September 2009,
               <http://www.rfc-editor.org/info/rfc5623>.

[RFC6805]      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 and
               GMPLS", RFC 6805, November 2012,
               <http://www.rfc-editor.org/info/rfc6805>.

27.2. Informative References 📚✨

okay, these are the extra-credit reads, bestie. not required to implement the thing, but they give you the whole backstory 🧚

[ALTO-SERVER-DISC] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", Work in Progress, draft-ietf-alto-server-discovery-10, September 2013.

[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Work in Progress, draft-ietf-idr-ls-distribution-06, September 2014.

[NET-OPS] King, D., and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", Work in Progress, draft-farrkingel-pce-abno-architecture-13, October 2014.

[PCE-PCEPS] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-02, October 2014.

[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001, <http://www.rfc-editor.org/info/rfc3060>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.

[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003 <http://www.rfc-editor.org/info/rfc3460>.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.

[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004, <http://www.rfc-editor.org/info/rfc3812>.

[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.

[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006, <http://www.rfc-editor.org/info/rfc4397>.

[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006, <http://www.rfc-editor.org/info/rfc4657>.

[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006, <http://www.rfc-editor.org/info/rfc4674>.

[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.

[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>.

[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007, <http://www.rfc-editor.org/info/rfc4848>.

[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007, <http://www.rfc-editor.org/info/rfc4974>.

[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008, <http://www.rfc-editor.org/info/rfc5088>.

[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008, <http://www.rfc-editor.org/info/rfc5089>.

[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.

[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008, <http://www.rfc-editor.org/info/rfc5212>.

[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.

[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>.

[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008, <http://www.rfc-editor.org/info/rfc5394>.

[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, <http://www.rfc-editor.org/info/rfc5441>.

[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, <http://www.rfc-editor.org/info/rfc5557>.

[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.

[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, <http://www.rfc-editor.org/info/rfc6006>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.

[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.

[STATEFUL-PCE] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", Work in Progress, draft-ietf-pce-stateful-pce-10, October 2014.

[TE-INFO] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D, and X. Zhang, "Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks", Work in Progress, draft-farrel-interconnected-te-info-exchange-07, September 2014.

Acknowledgements 🫶

thank you SO much to Fatai Zhang, Oscar Gonzalez de Dios, Xian Zhang, Cyril Margaria, Denis Ovsienko, Ina Minei, Dhruv Dhody, and Qin Wu for the constructive comments. you all are literally the best 💖

this work was supported in part by the FP-7 IDEALIST project under grant agreement number 317999. 🌸

this work also received funding from the European Union's Seventh Framework Programme for research, technological development and demonstration through the PACE project under grant agreement no. 619712. 🇪🇺✨

Authors' Addresses 💌

Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk

Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk

📦 where this page comes from

ietf: rfc7399 2014-10
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms