RFC 4105

Requirements for Inter-Area MPLS Traffic Engineering ✨

Part 1 of 4 🎀

Title block, bestie 💖

• Working group: Network Working Group
• RFC number: 4105
• Title: Requirements for Inter-Area MPLS Traffic Engineering
• Category: Informational
• Date: June 2005
• Authors: J.-L. Le Roux, Ed. (France Telecom), J.-P. Vasseur, Ed. (Cisco Systems, Inc.), and J. Boyle, Ed. (PDNETs)
• Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 📝

Status of This Memo 🌸

This memo gives information to the Internet community. It is not a standard of any kind 🙈 Anyone can share it freely, with no limits.

Copyright Notice 💜

Copyright (C) The Internet Society (2005).

Abstract 🦋

Okay so this doc is basically a detailed checklist 📋 of what any solution for inter-area MPLS Traffic Engineering (inter-area MPLS TE) needs to do. The whole point is that people designing those solutions, with their procedures and protocol extensions, should be able to tick off every item on the list ✅

Table of Contents 📑

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................3
   3. Terminology .....................................................3
   4. Current Intra-Area Uses of MPLS Traffic Engineering .............4
      4.1. Intra-Area MPLS Traffic Engineering Architecture ...........4
      4.2. Intra-Area MPLS Traffic Engineering Applications ...........4
           4.2.1. Intra-Area Resource Optimization ....................4
           4.2.2. Intra-Area QoS Guarantees ...........................5
           4.2.3. Fast Recovery within an IGP Area ....................5
      4.3. Intra-Area MPLS TE and Routing .............................6
   5. Problem Statement, Requirements, and Objectives of Inter-Area ...6
      5.1. Inter-Area Traffic Engineering Problem Statement ...........6
      5.2. Overview of Requirements for Inter-Area MPLS TE ............7
      5.3. Key Objectives for an Inter-Area MPLS-TE Solution ..........8
           5.3.1. Preserving the IGP Hierarchy Concept ................8
           5.3.2. Preserving Scalability ..............................8
   6. Application Scenario.............................................9
   7. Detailed Requirements for Inter-Area MPLS TE ...................10
      7.1. Inter-Area MPLS TE Operations and Interoperability ........10
      7.2. Inter-Area TE-LSP Signaling ...............................10
      7.3. Path Optimality ...........................................11
      7.4. Inter-Area MPLS-TE Routing ................................11
      7.5. Inter-Area MPLS-TE Path Computation .......................12
      7.6. Inter-Area Crankback Routing ..............................12
      7.7. Support of Diversely-Routed Inter-Area TE LSPs ............13
      7.8. Intra/Inter-Area Path Selection Policy ....................13
      7.9. Reoptimization of Inter-Area TE LSP .......................13
      7.10. Inter-Area LSP Recovery ..................................14
            7.10.1. Rerouting of Inter-Area TE LSPs ..................14
            7.10.2. Fast Recovery of Inter-Area TE LSP ...............14
      7.11. DS-TE support ............................................15
      7.12. Hierarchical LSP Support .................................15
      7.13. Hard/Soft Preemption .....................................15
      7.14. Auto-Discovery of TE Meshes ..............................16
      7.15. Inter-Area MPLS TE Fault Management Requirements .........16
      7.16. Inter-Area MPLS TE and Routing ...........................16
   8. Evaluation criteria ............................................17
      8.1. Performances ..............................................17
      8.2. Complexity and Risks ......................................17
      8.3. Backward Compatibility ....................................17
   9. Security Considerations ........................................17
   10. Acknowledgements ..............................................17
   11. Contributing Authors ..........................................18
   12. Normative References ..........................................19
   13. Informative References ........................................19

1. Introduction ✨

Okay bestie, so there's a whole set of MPLS Traffic Engineering pieces 🧚 defined in [RSVP-TE], [OSPF-TE], and [ISIS-TE]. They meet the requirements in [TE-REQ], and lots of network operators use them today to hit the big Traffic Engineering goals from [TE-OVW]. Those goals are:

• Aggregated Traffic measurement
• Optimization of network resources utilization
• Support for services requiring end-to-end QoS guarantees
• Fast recovery against link/node/Shared Risk Link Group (SRLG) failures

Also, [TE-APP] talks about how MPLS can be used for traffic engineering in IP networks, which is very relevant 💅

So far, MPLS Traffic Engineering has only worked inside a single Interior Gateway Protocol (IGP) area 🌈 This document is about the requirements for an inter-area MPLS Traffic Engineering mechanism, one that could get the same goals done across multiple IGP areas ✨

Basically, it would be super useful to stretch MPLS TE across IGP areas. That way you could do inter-area resource optimization, give strict QoS guarantees between two edge routers that sit in different areas, and protect inter-area traffic if an Area Border Router (ABR) goes down 🫶

Here's how the doc flows. First it covers how MPLS TE is used today within one IGP area. Then it lists a set of functional requirements that a solution must or should satisfy to support inter-area MPLS Traffic Engineering. The requirements vary from operator to operator, so some are mandatory (MUST) and others are optional (SHOULD) 💜 Last but not least, it gives a set of evaluation criteria for any solution that meets these requirements 🎀

2. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119]. Those words are a big deal, so please don't skip this part 🙈

3. Terminology 🍓

Here's the glossary, so everyone's speaking the same language:

   LSR:               Label Switching Router

   LSP:               Label Switched Path

   TE LSP:            Traffic Engineering Label Switched Path

   Inter-area TE LSP: TE LSP whose head-end LSR and tail-end LSR do not
                      reside within the same IGP area or whose head-end
                      LSR and tail-end LSR are both in the same IGP area
                      although the TE-LSP transiting path is across
                      different IGP areas.

   IGP area:          OSPF area or IS-IS level.

   ABR:               Area Border Router, a router used to connect two
                      IGP areas (ABR in OSPF, or L1/L2 router in IS-IS).

   CSPF:              Constraint-based Shortest Path First.

   SRLG:              Shared Risk Link Group.

4. Current Intra-Area Uses of MPLS Traffic Engineering 🌸

This section is all about MPLS TE inside a single IGP area: how it's built, what it can do, and the different ways people hook it into routing. It starts with the current MPLS-TE architecture, then covers the MPLS-TE capabilities, and ends with the approaches for integrating MPLS TE into routing. The whole point is to set up the requirements for MPLS-TE extensions across multiple IGP areas 🦋

4.1. Intra-Area MPLS Traffic Engineering Architecture 🏗️

So the MPLS-TE control plane lets you set up explicitly routed MPLS LSPs, where the paths follow a set of TE constraints. It's how you hit the big TE goals like resource usage optimization, QoS guarantees, and fast failure recovery 🔥 It has three main parts:

• The routing component, which is in charge of discovering the TE topology. That's handled by extensions to link state IGPs: [ISIS-TE] and [OSPF-TE].
• The path computation component, which decides where the LSP goes. It runs on the head-end LSR using a CSPF algorithm, which takes the TE topology and the LSP constraints as input.
• The signaling component, which sets up the LSP (explicit routing, label distribution, and resource reservation) along the computed path. That's done with RSVP-TE [RSVP-TE] 💅

4.2. Intra-Area MPLS Traffic Engineering Applications 🎀

4.2.1. Intra-Area Resource Optimization 💰

MPLS TE can be used inside an area to steer aggregated flows away from overused resources in the network. On a small scale, you can just configure a path between two routers by hand 🙈 On a bigger scale, you can set up a mesh of LSPs between central points in the network. LSP paths can either be defined statically in configuration, or worked out by an algorithm that finds the shortest path given administrative constraints like bandwidth. So basically, MPLS TE gives you much more control over how traffic demands get routed across the topology and how the network's resources get used 🧚

Also, TE LSPs make it easy to measure the traffic matrix in a simple, scalable way. The aggregated traffic rate between two LSRs can be measured just by counting the traffic sent onto a TE LSP provisioned between those two LSRs 📊

4.2.2. Intra-Area QoS Guarantees 💖

The DiffServ IETF working group defined a set of mechanisms in [DIFF-ARCH], [DIFF-AF], and [DIFF-EF] or [MPLS-DIFF]. They can be turned on at the edge of, or across, a DiffServ domain to help enforce a QoS policy (or set of policies). Those policies can be expressed in terms of maximum one-way transit delay, inter-packet delay variation, loss rate, and so on. Lots of operators already have some or full DiffServ deployments in their networks, either across the whole network or at least at the edge 🌈

Sometimes strict QoS bounds are needed, and then admission control inside the network backbone may be required on top of the current DiffServ mechanisms. When the propagation delay can be bounded, performance targets like maximum one-way transit delay can be guaranteed by providing bandwidth guarantees along the DiffServ-enabled path ✨

MPLS TE can simply be used together with DiffServ. In that case, it only ensures aggregate QoS guarantees for all the traffic. It can also be combined more closely with DiffServ to do per-class-of-service admission control and resource reservation. That requires extensions to MPLS TE called DiffServ-Aware TE, which are defined in [DSTE-PROTO]. DS-TE lets you ensure strict end-to-end QoS guarantees. For example, an EF DS-TE LSP can be provisioned between voice gateways within the same area to give strict QoS to VoIP traffic 🫶

MPLS TE also lets you compute intra-area shortest paths that satisfy various constraints, including bandwidth. For the sake of illustration, if the IGP metrics reflect the propagation delay, MPLS TE can find a minimum propagation delay path that still satisfies constraints such as bandwidth 👑

4.2.3. Fast Recovery within an IGP Area ✨

okay so as quality-sensitive apps keep getting deployed, one of the biggest requirements is fast recovery 💨 like, traffic recovery has to be guaranteed on the order of tens of msecs when a network element fails 😭. and ngl you can't get there by just relying on classical IGP rerouting. not it 💀

Various recovery mechanisms can be used to protect traffic carried onto TE LSPs, and they're defined in [MPLS-RECOV] 🎀. Protection works by provisioning backup LSPs that recover traffic when a protected LSP fails. Among those, local protection (aka Fast Reroute) is meant to hit sub-50ms recovery when a link, node, or SRLG fails along the LSP path [FAST-REROUTE] ⭐. Fast Reroute is already used by a lot of operators to protect sensitive traffic inside an IGP area, iconic 👑.

[FAST-REROUTE] defines two modes for backup LSPs. The first one, one-to-one backup, means setting up one detour LSP per protected LSP and per element to protect. The second one, facility backup, means setting up one or several bypass LSPs to protect a given facility (a link or a node). When something fails, all the protected LSPs get nested into the bypass LSPs, which is the MPLS label stacking property doing its thing 🧚💜

---

4.3. Intra-Area MPLS TE and Routing

there are a few different ways to steer traffic into intra-area TE LSPs 🦋:

1. Static routing to the LSP destination address or any other addresses.
2. IGP routes beyond the LSP destination, from an IGP SPF perspective (IGP shortcuts).
3. BGP routes announced by a BGP peer (or an MP-BGP peer) that is reachable through the TE LSP, either by a single static route to the corresponding BGP next-hop address (option 1) or by IGP shortcuts (option 2). This is often called BGP recursive routing.
4. The LSP can be advertised as a link into the IGP so it becomes part of the IGP database for all nodes, and can be taken into account during SPF for all nodes. Note that even though it's similar in concept, this is different from Forwarding-Adjacency, as defined in [LSP-HIER]. Forwarding-Adjacency is when the LSP is advertised as a TE-link into the IGP-TE so it becomes part of the TE database and is taken into account in CSPF 🫶

---

5. Problem Statement, Requirements, and Objectives of Inter-Area MPLS TE 🌈

5.1. Inter-Area Traffic Engineering Problem Statement

as described in Section 4, MPLS TE is deployed today by many operators to optimize network bandwidth usage, provide strict QoS guarantees, and ensure sub-50ms recovery when a link, node, or SRLG fails 💅

but MPLS-TE mechanisms are currently limited to a single IGP area 🙈. The limitation comes more from the Routing and Path computation components than from the signaling component. This is basically because the hierarchy limits the topology visibility of head-end LSRs to their IGP area, so head-end LSRs can no longer run a CSPF algorithm to compute the shortest constrained path to the tail-end, since CSPF needs the whole topology to compute an end-to-end shortest constrained path. it's giving "stuck" energy 😭

several operators have multi-area networks, and many operators that are still on a single IGP area may have to migrate to a multi-area environment as their network grows and single-area scalability limits get close 📈

so those operators may need inter-area traffic engineering to:

• Perform inter-area resource optimization.
• Provide inter-area QoS guarantees for traffic between edge nodes located in different areas.
• Provide fast recovery across areas, to protect inter-area traffic in case of link or node failure, including ABR node failures.

for instance, an operator running a multi-area IGP may have voice gateways located in different areas. Such VoIP transport needs inter-area QoS guarantees and inter-area fast protection 🎧

one possible approach for inter-area traffic engineering could be deploying MPLS TE on a per-area basis, but that approach has several limitations 🥲:

• Traffic aggregation at the ABR levels implies some constraints that do not lead to efficient traffic engineering. Actually, this per-area TE approach might lead to sub-optimal resource utilization, by optimizing resources independently in each area. What many operators want is to optimize their resources as a whole; in other words, as if there was only one area (flat network).
• This does not allow computing an inter-area constrained shortest path and thus does not ensure end-to-end QoS guarantees across areas.
• Inter-area traffic cannot be protected with local protection mechanisms such as [FAST-REROUTE] in case of ABR failure.

so existing MPLS TE mechanisms have to be enhanced to support inter-area TE LSPs 🔥

5.2. Overview of Requirements for Inter-Area MPLS TE

for the reasons above, it is highly desired to extend the current set of MPLS-TE mechanisms across multiple IGP areas, so the intra-area applications described in Section 4 can work across areas too 🦋

The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs whose path crosses at least two IGP areas. 👑

Inter-area MPLS-TE extensions are highly desired in order to provide:

• Inter-area resources optimization.
• Strict inter-area QoS guarantees.
• Fast recovery across areas, particularly to protect inter-area traffic against ABR failures.

it may be desired to compute inter-area shortest paths that satisfy some bandwidth constraints or any other constraints, just like you can within a single IGP area. For the sake of illustration, if the IGP metrics reflect the propagation delay, it may be necessary to be able to find the optimal (shortest) path satisfying some constraints (e.g., bandwidth) across multiple IGP areas. Such a path would be the inter-area path offering the minimal propagation delay ⭐

so the solution SHOULD provide the ability to compute inter-area shortest paths satisfying a set of constraints (i.e., bandwidth) 🫶

5.3. Key Objectives for an Inter-Area MPLS-TE Solution

any solution for inter-area MPLS TE should be designed with preserving the IGP hierarchy concept, and preserving routing and signaling scalability as key objectives 🧚

5.3.1. Preserving the IGP Hierarchy Concept

the absence of a full link-state topology database makes it impossible for the head-end LSR to compute an end-to-end optimal path without further signaling and routing extensions. There are several reasons network operators choose to break their network up into different areas 🏡. These often include scalability and containment of routing information. The latter can help isolate most of a network from receiving and processing updates that have no consequence to its routing decisions. Containment of routing information MUST not be compromised to allow inter-area traffic engineering. Information propagation for path-selection MUST continue to be localized. In other words, the solution MUST entirely preserve the concept of IGP hierarchy 💜

5.3.2. Preserving Scalability

achieving the requirements listed in this document MUST be performed while preserving IGP scalability, which is of the utmost importance 💖. The hierarchy preservation objective from the section above is actually one of the things that preserves IGP scalability.

The solution also MUST not increase IGP load unreasonably, which could compromise IGP scalability. In particular, a solution satisfying those requirements MUST not require the IGP to carry an unreasonable amount of extra information and MUST not unreasonably increase the IGP flooding frequency 📉

likewise, the solution MUST also preserve scalability of RSVP-TE ([RSVP-TE]) 🌸

also, the base specification of MPLS TE is architecturally structured and relatively free of excessive state propagation in terms of routing or signaling. Its strength in extensibility can also be seen as an Achilles heel, because there is no real limit to what is possible with extensions. It is paramount to keep architectural vision and discretion when adapting it for inter-area MPLS TE. Additional information carried within an area, or propagated outside of an area (via routing or signaling), should be neither excessive, patchwork, nor non-relevant 🧩

particularly, as mentioned in Section 5.2, it may be desired for some inter-area TE LSP carrying highly sensitive traffic to compute a shortest inter-area path that satisfies a set of constraints such as bandwidth. This may require an additional routing mechanism, since base CSPF at the head-end can no longer be used due to the lack of topology and resource information. Such a routing mechanism MUST not compromise the scalability of the overall system 🙈

6. Application Scenario 🗺️

   ---area1--------area0------area2--
    ------R1-ABR1-R2-------ABR3-------
   |       \   |  /        |         |
   | R0     \  | /         |      R4 |
   | R5      \ |/          |         |
    ---------ABR2----------ABR4-------

• ABR1, ABR2: Area0-Area1 ABRs
• ABR3, ABR4: Area0-Area2 ABRs
• R0, R1, R5: LSRs in area 1
• R2: an LSR in area 0
• R4: an LSR in area 2

although the terminology and examples in this document use OSPF terminology, this document applies equally to IS-IS 🎀

typically, an inter-area TE LSP will be set up between R0 and R4, where both LSRs belong to different IGP areas. Note that the solution MUST support the capability to protect such an inter-area TE LSP from the failure of any Link/SRLG/Node within any area and from the failure of any traversed ABR. For instance, if the TE LSP R0->R4 goes through R1->ABR1->R2, then it can be protected against ABR1 failure, thanks to a backup LSP (detour or bypass) that may follow the alternate path R1->ABR2->R2 🦋

for instance, R0 and R4 may be two voice gateways located in distinct areas. An inter-area DS-TE LSP with class-type EF is set up from R1 to R4 to route VoIP traffic classified as EF. Per-class inter-area constraint-based routing allows the DS-TE LSP to be routed over a path that will ensure strict QoS guarantees for VoIP traffic 📞✨

in another application, R0 and R4 may be two pseudo wire gateways residing in different areas. An inter-area LSP may be set up to carry pseudo wires 🌷

in some cases, it might also be possible to have an inter-area TE LSP from R0 to R5 transiting via the backbone area (or any other levels with IS-IS). There may be cases where there are no longer enough resources on any intra-area path from R0 to R5, and where there is a feasible inter-area path through the backbone area 🏃‍♀️💨

7. Detailed Requirements for Inter-Area MPLS TE 📋

7.1. Inter-Area MPLS TE Operations and Interoperability

The inter-area MPLS TE solution MUST be consistent with the requirements discussed in [TE-REQ], and the derived solution MUST interoperate seamlessly with current intra-area MPLS TE mechanisms and inherit its capability sets from [RSVP-TE] 🫶

The proposed solution MUST allow provisioning at the head-end with end-to-end RSVP signaling (potentially with loose paths) traversing across the interconnected ABRs, without further provisioning required along the transit path 🎀

7.2. Inter-Area TE-LSP Signaling 🎀

okay so the solution MUST allow for the signaling of inter-area TE LSPs, using RSVP-TE 💖

on top of the usual TE stuff (bandwidth, admin-groups 🦋), the proposed solution MUST let the head-end LSR spell out a set of LSRs explicitly, ABRs included, using strict or loose hops for the inter-area TE LSP. main character planning, honestly 👑

and ALSO, the proposed solution SHOULD give you a way to name certain resources that get explicitly excluded when the inter-area TE-LSP path is being set up. ngl that's a whole vibe 🫶

7.3. Path Optimality ✨

so in this requirement doc, an optimal path means the shortest path across multiple areas, using either the IGP or TE metric [METRIC]. basically it's the path you'd get from a CSPF algorithm if there were no multiple IGP areas at all 🧚

as we saw in Section 5.2, the solution SHOULD be able to compute an optimal path on the fly, while meeting a set of specified constraints (defined in [TE-REQ]) across multiple IGP areas 💅

but here's the tea: this doc does NOT say every inter-area TE LSP has to get the shortest inter-area path. some paths can be computed with methods that don't guarantee an optimal end-to-end path, while other paths carrying sensitive traffic could use mechanisms that do compute an optimal end-to-end path dynamically 🌸

and regular constraints like bandwidth, affinities, IGP/TE metric optimization, path diversity, etc., MUST be taken into account when computing an optimal end-to-end path. no skipping those, bestie 🍓

7.4. Inter-Area MPLS-TE Routing 🦋

as we said in Section 5.3, the IGP hierarchy doesn't let the head-end LSR compute an end-to-end optimal path on its own 🙈 so extra mechanisms are needed to compute one.

these mechanisms MUST not alter the IGP hierarchy principles. the whole point is keeping routing information contained and keeping IGP scalability intact, so the solution SHOULD avoid leaking any dynamic-TE-topology-related information across areas, even in summarized form. it's giving containment, it's giving scale 🔥

BUT (and this is a fun one) that doesn't rule out leaking non-topology-related info that isn't used during path selection, like static TE Node information (TE router ids or TE node capabilities) 💜

7.5. Inter-Area MPLS-TE Path Computation 🌈

several methods may be used for path computation, including the following:

• Per-area path computation based on ERO expansion on the head-end LSR and on ABRs, with two options for ABR selection:
  1. Static configuration of ABRs as loose hops at the head-end LSR.
  2. Dynamic ABR selection.
• Inter-area end-to-end path computation, which may be based on (for instance) a recursive constraint-based searching thanks to collaboration between ABRs.

any path computation method is fine, as long as it respects the key objectives from Section 5.3 ✨

and if a solution supports more than one method, it should let the operator pick the desired option by configuration, on a per-LSP basis 🎀

7.6. Inter-Area Crankback Routing 💅

crankback routing, as defined in [CRANKBACK], may be used for inter-area TE LSPs. for paths computed through ERO expansions with dynamic selection of downstream ABRs, crankback can kick in when there's no feasible path from a selected downstream ABR to the destination. then the upstream ABR or head-end LSR picks another downstream ABR and does ERO expansion again 🦋

heads up: this method gets you a feasible path, NOT an optimal one. and there can be 0(N^2) LSP setup failures before a feasible path turns up, where N is the average number of ABRs between two areas. that can have a non-negligible impact on LSP setup delay 💀

crankback can also help with inter-area LSP recovery. if a link/node/SRLG failure happens in the backbone or tail-end area, the ABR upstream of the failure computes an alternate path and reroutes the LSP locally 🧚

an inter-area MPLS-TE solution MAY support [CRANKBACK]. and a solution that does MUST let [CRANKBACK] be activated/deactivated via signaling, on a per-LSP basis 🔥

7.7. Support of Diversely-Routed Inter-Area TE LSPs 🌸

there are a bunch of cases where computing diversely-routed TE-LSP paths is super useful. like, for LSP protection, primary and backup LSPs should be diversely routed 🫶 another one: setting up multiple diversely-routed TE LSPs between a pair of LSRs in different IGP areas. for example, if no single TE LSP can satisfy the bandwidth constraint between two end-points, you set up multiple TE LSPs whose bandwidths add up to the requirement. in that case, diverse routing helps minimize the impact of a failure on traffic between the two end-points 🍓

so the solution MUST be able to establish diversely-routed inter-area TE LSPs when diverse paths exist. it MUST support all kinds of diversity: link, node, SRLG 👑

the solution SHOULD allow computing an optimal placement of diversely-routed LSPs. there are lots of criteria for "optimal" here. for example, placing two diversely-routed LSPs for load-balancing could mean minimizing their cumulative cost. placing two for protection could mean minimizing the cost of the primary LSP while bounding the cost or hop count of the backup LSP 💖

7.8. Intra/Inter-Area Path Selection Policy 🦋

for inter-area TE LSPs whose head-end and tail-end LSRs live in the same IGP area, there may be both intra-area and inter-area feasible paths. if the shortest path is inter-area, an operator might want to avoid crossing areas as much as possible, so they'd pick a sub-optimal intra-area path. or they might be happy to take the shortest path even if it crosses areas ✨

so the solution should let IGP area crossing be enabled/disabled, on a per-LSP basis, for TE LSPs whose head-end and tail-end are in the same IGP area 🎀

7.9. Reoptimization of Inter-Area TE LSP 💜

the solution MUST provide the ability to reoptimize an inter-area TE LSP in a minimally disruptive manner (make before break), should a more optimal path appear in any traversed IGP area. the operator should be able to set up that reoptimization on a timer or event-driven basis. it should also be possible to trigger it manually 🧚

the solution SHOULD provide the ability to reoptimize an inter-area TE LSP locally within an area, meaning while keeping the same set of transit ABRs. that reoptimization MAY be controlled by the head-end LSR of the inter-area LSP, or by an ABR. the ABR should check local optimality of the inter-area TE LSPs established through it on a timer or event-driven basis. a manual trigger to check optimality should also be provided 🌈

sometimes it's important to restrict reoptimization control to the Head-End LSR only. so the solution MUST allow ABR control of reoptimization to be activated/deactivated via signaling, on a per-LSP basis 🫶

the solution SHOULD also provide end-to-end reoptimization, which could change the set of transit ABRs. only the Head-End LSR can control that one 🔥

when the head-end LSR is in control of reoptimization, the solution SHOULD let the inter-area head-end LSR know when a more optimal path exists in a downstream area, and keep strict control over the reoptimization process. so once the inter-area head-end LSR knows about a more optimal path in some downstream IGP areas, it can decide whether to do a make-before-break reoptimization gracefully (or not), depending on the inter-area TE-LSP characteristics 💅

7.10. Inter-Area LSP Recovery 🎀

7.10.1. Rerouting of Inter-Area TE LSPs 🦋

the solution MUST support rerouting of an inter-area TE LSP in case of SRLG/link/node failure or preemption. that rerouting may be controlled by the Head-End LSR or by an ABR (see Section 7.6, on crankback) ✨

7.10.2. Fast Recovery of Inter-Area TE LSP 💖

the solution MUST be able to benefit from fast recovery, using the local protection techniques specified in [FAST-REROUTE], both for an intra-area network element failure (link/SRLG/node) and for an ABR node failure. different protection techniques SHOULD be usable in different parts of the network to protect an inter-area TE LSP. this matters A LOT, especially for an ABR node failure, since that node typically carries a ton of inter-area traffic 😭

the solution SHOULD also let you compute and set up a backup tunnel following an optimal path that offers bandwidth guarantees during failure, along with other potential constraints (like a bounded propagation delay increase along the backup path) 🌸

the solution SHOULD allow ABRs to be protected, while giving the same level of performance (recovery delay, bandwidth consumption) as today within an area 👑

some signaling approaches can impact FRR performance (recovery delay, bandwidth consumption). typically, when intra-area LSPs (LSP-Segment, FA-LSPs) are used to support the inter-area TE LSP, protecting an ABR with [FAST-REROUTE] may lead to higher bandwidth consumption and higher recovery delays. protecting ABRs with [FAST-REROUTE] does keep the same level of performance, but it currently requires a single end-to-end RSVP session (contiguous LSP) with no intra-area LSPs 🙈

so the solution MUST provide the ability, via signalling on a per-LSP basis, to allow or preclude the use of intra-area LSPs to support inter-area LSPs 🍓

7.11. DS-TE support 🧚

the proposed inter-area MPLS TE solution SHOULD also satisfy the core requirements documented in [DSTE-REQ] and interoperate seamlessly with the current intra-area MPLS DS-TE mechanism [DSTE-PROTO] 💜

7.12. Hierarchical LSP Support 🌈

for a large inter-area MPLS deployment, potentially involving lots of LSRs, it may be desirable or necessary to add some level of hierarchy to reduce the number of states on LSRs (though that comes with other challenges 🙈). so the proposed solution SHOULD allow inter-area TE-LSP aggregation (also called LSP nesting), so individual TE LSPs can be carried onto one or more aggregating LSPs. one such mechanism is described in [LSP-HIER] 🫶

7.13. Hard/Soft Preemption 🔥

as defined in [MPLS-PREEMPT], two preemption models apply to MPLS: Soft and Hard Preemption 💅

an inter-area MPLS-TE solution SHOULD support both models 🎀

with hard preemption, the preempted inter-area TE LSP should be rerouted, following the requirements in Section 7.10.1 🦋

with soft preemption, the preempted inter-area TE LSP should be re-optimized, following the requirements in Section 7.9 ✨

7.14. Auto-Discovery of TE Meshes 💜

okay bestie, so a TE mesh is a set of LSRs that are all fully interconnected by a full mesh of TE LSPs. 🫶 Because a TE mesh can get seriously big, it might be super helpful to have some discovery mechanisms, so an LSR can automatically find out which TE meshes it belongs to and who else is in them ✨. The discovery mechanism SHOULD be applicable across multiple IGP areas, and SHOULD not impact the IGP scalability, provided that IGP extensions are used for such a discovery mechanism.

---

7.15. Inter-Area MPLS TE Fault Management Requirements 🧚

The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-area MPLS TE.

The solution SHOULD support [LSP-PING] and [MPLS-TTL].

The solution SHOULD also support fault detection on backup LSPs, in case [FAST-REROUTE] is deployed.

---

7.16. Inter-Area MPLS TE and Routing 🦋

okay so with intra-area MPLS TE, there are already a few ways to route traffic into an intra-area TE LSP. They're listed in Section 4.2. 🍓

With inter-area MPLS TE, the solution MUST support static routing into the LSP, and also BGP recursive routing with a static route to the BGP next-hop address. no notes, it's giving strict 🔥

ABRs propagate IP reachability information (summary LSA in OSPF and IP reachability TLV in ISIS), which MAY be used by the head-end LSR to route traffic to a destination beyond the TE-LSP tail-head LSR (e.g., to an ASBR). 👀

The use of IGP shortcuts MUST be precluded when TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. It MAY be used when they reside in the same area. 🙈

The advertisement of an inter-area TE LSP as a link into the IGP, in order to attract traffic to an LSP source, MUST be precluded when TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. It MAY be used when they reside in the same area. 💅

---

8. Evaluation criteria 📊

8.1. Performances

The solution will be evaluated with respect to the following criteria:

1. Optimality of the computed inter-area TE-LSP primary and backup paths, in terms of path cost.
2. Capability to share bandwidth among inter-area backup LSPs protecting independent facilities.
3. Inter-area TE-LSP setup time (in msec).
4. RSVP-TE and IGP scalability (state impact, number of messages, message size).

8.2. Complexity and Risks ⚠️

The proposed solution SHOULD not introduce complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks. 🧠

8.3. Backward Compatibility 🎀

So, to allow for a smooth migration or co-existence, the deployment of inter-area MPLS TE SHOULD not affect existing MPLS TE mechanisms. In particular, the solution SHOULD allow the setup of an inter-area TE LSP among transit LSRs that do not support inter-area extensions, provided that these LSRs do not participate in the inter-area TE procedure. For illustration purposes, the solution MAY require inter-area extensions only on end-point LSRs, on ABRs, and, potentially, on Points of Local Repair (PLR) protecting an ABR. 🌸

---

9. Security Considerations 🔐

This document does not introduce new security issues beyond those inherent in MPLS TE [RSVP-TE] and an inter-area MPLS-TE solution may use the same mechanisms proposed for that technology. It is, however, specifically important that manipulation of administratively configurable parameters be executed in a secure manner by authorized entities. 😭 This is the part you cannot skip, bestie.

---

10. Acknowledgements 🫶

We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal Sharma, and Arthi Ayyangar for their useful comments and suggestions. 💖

---

11. Contributing Authors 🌸

This document was the collective work of several authors. The text and content of this document was contributed by the editors and the co-authors listed below (the contact information for the editors appears in Section 14 and is not repeated below):

Ting-Wo Chung                         Yuichi Ikejiri
Bell Canada                           NTT Communications Corporation
181 Bay Street, Suite 350,            1-1-6, Uchisaiwai-cho,
Toronto,                              Chiyoda-ku, Tokyo 100-8019
Ontario, Canada, M5J 2T3              JAPAN

EMail: ting_wo.chung@bell.ca          EMail: y.ikejiri@ntt.com


Raymond Zhang                         Parantap Lahiri
Infonet Services Corporation          MCI
2160 E. Grand Ave.                    22001 Loudoun Cty Pky
El Segundo, CA 90025                  Ashburn, VA 20147
USA                                   USA

EMail: raymond_zhang@infonet.com      EMail: parantap.lahiri@mci.com


Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460,
JAPAN

EMail: ke-kumaki@kddi.com

---

12. Normative References 📚

You need to read these to really get the doc:

[RFC2119]      Bradner, S., "Key words for use in RFCs to indicate
               requirements levels", RFC 2119, March 1997.

[TE-REQ]       Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
               J. McManus, "Requirements for Traffic Engineering Over
               MPLS", RFC 2702, September 1999.

[DSTE-REQ]     Le Faucheur, F. and W. Lai, "Requirements for Support
               of Differentiated Services-aware MPLS Traffic
               Engineering", RFC 3564, July 2003.

13. Informative References 🦋

These are the extra reads for when you want to go deeper 🧚

[TE-OVW]       Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
               X. Xiao, "Overview and Principles of Internet Traffic
               Engineering", RFC 3272, May 2002.

[RSVP-TE]      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.

[OSPF-TE]      Katz, D., Kompella, K., and D. Yeung, "Traffic
               Engineering (TE) Extensions to OSPF Version 2", RFC
               3630, September 2003.

[ISIS-TE]      Smit, H. and T. Li, "Intermediate System to
               Intermediate System (IS-IS) Extensions for Traffic
               Engineering (TE)", RFC 3784, June 2004.

[TE-APP]       Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche,
               D., Christian, B., and W. Lai, "Applicability
               Statement for Traffic Engineering with MPLS", RFC
               3346, August 2002.

[FAST-REROUTE] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
               "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
               RFC 4090, May 2005.

[LSP-PING]     Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
               G., Wadhwa, S., Bonica, R., "Detecting Data Plane
               Liveliness in MPLS", Work in Progress.

[MPLS-TTL]     Agarwal, P. and B. Akyol, "Time To Live (TTL)
               Processing in Multi-Protocol Label Switching (MPLS)
               Networks", RFC 3443, January 2003.

[LSP-HIER]     Kompella, K., and Y. Rekhter, "LSP Hierarchy with
               Generalized MPLS TE", Work in Progress.

[MPLS-RECOV]   Sharma, V. and F. Hellstrand, "Framework for Multi-
               Protocol Label Switching (MPLS)-based Recovery", RFC
               3469, February 2003.

[CRANKBACK]    Farrel, A., Ed., "Crankback Signaling Extensions for
               MPLS Signaling", Work in Progress.

[MPLS-DIFF]    Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
               Vaananen, P., Krishnan, R., Cheval, P., and J.
               Heinanen, "Multi-Protocol Label Switching (MPLS)
               Support of Differentiated Services", RFC 3270, May
               2002.

[DSTE-PROTO]   Le Faucheur, F., et al., "Protocol Extensions for
               Support of Differentiated-Service-aware MPLS Traffic
               Engineering",  Work in Progress.

[DIFF-ARCH]    Blake, S., Black, D., Carlson, M., Davies, E., Wang,
               Z., and W. Weiss, "An Architecture for Differentiated
               Service", RFC 2475, December 1998.

[DIFF-AF]      Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
               "Assured Forwarding PHB Group", RFC 2597, June 1999.

[DIFF-EF]      Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
               Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
               D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
               Behavior)", RFC 3246, March 2002.

[MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work
               in Progress.

[METRIC]       Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P.,
               and T. Telkamp, "Use of Interior Gateway Protocol
               (IGP) Metric as a second MPLS Traffic Engineering (TE)
               Metric", BCP 87, RFC 3785, May 2004.

---

14. Editors' Addresses 💌

Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France

EMail: jeanlouis.leroux@francetelecom.com


Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA - 01719
USA

EMail: jpv@cisco.com


Jim Boyle

EMail: jboyle@pdnets.com

---

Full Copyright Statement ©

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💎

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. ✨