RFC 3906

RFC 3906: Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels 💖

okay bestie, RFC 3906 is here 📜. It was written by N. Shen (Redback Networks) and H. Smit, and it's dated October 2004. It's labelled Category: Informational, so it's sharing info with the Internet community and isn't a standard 🙈. The title block doesn't list any RFCs it obsoletes or updates, so it stands on its own ✨

Status of this Memo 🎀

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice 🌸

Copyright (C) The Internet Society (2004).

Abstract 🦋

This doc explains how normal hop-by-hop link-state routing protocols team up with the new Traffic Engineering features to make Interior Gateway Protocol (IGP) shortcuts 🔥. Specifically, it shows how Dijkstra's Shortest Path First (SPF) algorithm can be adjusted so link-state IGPs calculate IP routes that send traffic over tunnels set up by Traffic Engineering 💅.

1. Introduction 🌈

okay so link-state protocols like integrated Intermediate System to Intermediate System (IS-IS) [1] and OSPF [2] use Dijkstra's SPF algorithm to work out a shortest path tree to every node in the network 🗺️. The routing tables come from that tree, and each entry is a pair of destination and first-hop info. If a router does normal hop-by-hop routing, the first hop is a physical interface attached to the router. New traffic engineering algorithms work out explicit routes to one or more nodes in the network ✨. On the router that starts those explicit routes, they look like logical interfaces that provide Label Switched Paths through the network. For this doc, we call these Label Switched Paths Traffic Engineering tunnels (TE-tunnels) 🎀. Those capabilities are specified in [3] and [4].

Here's the thing: whether TE-tunnels exist in the network and how traffic gets switched onto them are two separate questions 🙃. A node may define static routes that point at the TE-tunnels. It may match the recursive route next-hop with the TE-tunnel end-point address. Or it may define local policy, like affinity based tunnel selection, for switching certain traffic 💜. This document describes a mechanism that uses link-state IGPs to dynamically install IGP routes over those TE-tunnels 🧚.

The tunnels we care about are ones created explicitly by the node doing the calculation, with an end-point address that this node knows. For algorithms like the one in this document, it doesn't matter whether the tunnel is strictly or loosely routed 🙌. A simple constraint can make sure the mechanism stays loop free 🔁. When a router decides to inject a packet addressed to a destination D, the router may inject that packet into a tunnel whose end-point is closer to destination D (according to the link-state IGP topology) than the injecting router is. Put another way, the tail-end of the tunnel has to be a downstream IGP node for destination D 👑. The algorithms that follow are one way a router can follow this rule and dynamically make smart choices about when to use TE-tunnels for traffic 💅. This algorithm may be used together with other mechanisms, like statically defined routes over TE-tunnels or traffic flow and QoS based TE-tunnel selection.

This IGP shortcut mechanism assumes the TE-tunnels are already set up 🛠️. The TE-tunnels in the network may be used for QoS, bandwidth, redundancy, or fastreroute reasons 💖. When an IGP shortcut mechanism is applied to those tunnels, or other mechanisms are used alongside an IGP shortcut, the physical traffic that actually moves through those tunnels may not match the original traffic engineering setup goal 😭. Traffic patterns in the network can also change over time. So some forwarding plane measurement, with feedback into adjusting TE-tunnel attributes, needs to be there to make sure the network is being traffic engineered efficiently [6] 📈.

2. Enhancement to the Shortest Path First Computation 🍓

During each step of the SPF computation, a router finds the path to one node in the network 🔍. If that node is directly connected to the calculating router, the first-hop info comes from the adjacency database. If a node isn't directly connected to the calculating router, it inherits the first-hop info from its parent(s) 👪. Each node has one or more parents, and each node is the parent of zero or more down-stream nodes 🌳.

For traffic engineering purposes, each router keeps a list of all TE-tunnels that start at this router. For each of those TE-tunnels, the router knows the tail-end router 🎯.

During SPF, when a router finds the path to a new node (in other words, this new node moves from the TENTative list to the PATHS list), the router must determine the first-hop info. There are three possible ways to do this:

• Check the list of tail-end routers directly reachable via a TE-tunnel. If there's a TE-tunnel to this node, we use that TE-tunnel as the first hop 🚇.
• If there's no TE-tunnel, and the node is directly connected, we use the first-hop info from the adjacency database 🔗.
• If the node isn't directly connected, and isn't directly reachable via a TE-tunnel, we copy the first-hop info from the parent node(s) to the new node 📋.

So the result is that traffic going to nodes that are tail-ends of TE-tunnels flows over those TE-tunnels 🚀. Traffic going to nodes downstream of those tail-end nodes also flows over those TE-tunnels 💫. If there are multiple TE-tunnels to different intermediate nodes on the path to destination node X, traffic flows over the TE-tunnel whose tail-end node is closest to node X 🎀. In certain applications, there's a need to carry both the native adjacency and the TE-tunnel next-hop info for the TE-tunnel tail-end and its downstream nodes 🤹. The head-end node may conditionally switch data traffic onto TE-tunnels based on user defined criteria or events. It may also split traffic across either type of next-hop, or install the routes with two different types of next-hops into two separate RIBs 🌸. Multicast protocols running over physical links may have to perform RPF checks using the native adjacency next-hops rather than the TE-tunnel next-hops 🙈.

3. Special Cases and Exceptions ⚠️

The Shortest Path First algorithm finds equal-cost parallel paths to destinations, and the enhancement in this document doesn't change that 🙌. Traffic can be forwarded over one or more native IP paths, over one or more TE-tunnels, or over a mix of native IP paths and TE-tunnels 🌈.

A special situation happens in this topology 👀:

rtrA -- rtrB -- rtrC
         |       |
        rtrD -- rtrE

Assume all links have the same cost, and that a TE-tunnel is set up from rtrA to rtrD 🚇. When the SPF calculation puts rtrC on the TENTative list, it realizes rtrC isn't directly connected, so it uses the first-hop info from its parent, which is rtrB. When the SPF calculation on rtrA moves rtrD from the TENTative list to the PATHS list, it realizes rtrD is the tail-end of a TE-tunnel. So rtrA installs a route to rtrD via the TE-tunnel, and not via rtrB 💖.

When rtrA puts rtrE on the TENTative list, it realizes rtrE isn't directly connected and isn't the tail-end of a TE-tunnel 🙃. So rtrA copies the first-hop info from the parents (rtrC and rtrD) to the first-hop info of rtrE. Traffic to rtrE now load-balances over the native IP path via rtrA->rtrB->rtrC and over the TE-tunnel rtrA->rtrD ⚖️.

When both parallel native IP paths and paths over TE-tunnels are available, implementations can let the network administrator force traffic onto only TE-tunnels (or only native IP paths), or let both be used for load sharing 🎛️.

4. Metric Adjustment of IP Routes over TE-tunnels 💅

When an IGP route is installed in the routing table with a TE-tunnel as the next hop, an interesting question comes up: what should the cost or metric of this route be? 🤔 The most obvious answer is to assign a metric that matches the IGP metric of the native IP path, as if the TE-tunnels didn't exist. For example, rtrA can reach rtrC over a path with a cost of 20. X is an IP prefix advertised by rtrC. We install the route to X in rtrA's routing table with a cost of 20. If a TE-tunnel from rtrA to rtrC comes up, the route is still installed with a metric of 20 by default, and only the next-hop info for X changes 🦋.

This scheme works well, but in some networks it might be useful to change the cost of the path over a TE-tunnel, so the route over the TE-tunnel is less or more preferred than other routes 🎯.

For instance, when equal cost paths exist over a TE-tunnel and over a native IP path, adjusting the cost of the path over the TE-tunnel lets us force traffic to prefer the TE-tunnel path, prefer the native IP path, or load-balance between them ⚖️. Another example is when multiple TE-tunnels go to the same or different destinations. Adjusting TE-tunnel metrics can force traffic to prefer some TE-tunnels over others, regardless of the underlying IGP cost to those destinations 💫.

Setting a manual metric on a TE-tunnel doesn't affect the SPF algorithm itself 🙅. It only affects the comparison of the new route with existing routes in the routing table. Existing routes can be IP routes to another router that advertises the same IP prefix, or a path to the same router through a different outgoing interface or a different TE-tunnel 🛣️. All routes to IP prefixes advertised by the tail-end router are affected by the TE-tunnel metric. The metrics of paths to routers downstream of the tail-end router are also influenced by the manual TE-tunnel metric 🌊.

This mechanism is loop free because the TE-tunnels are source-routed and the tunnel egress is a downstream node for reaching the computed destinations 🔁. The end result of TE-tunnel metric adjustment is more control over traffic loadsharing 🎀. If there's only one way to reach a particular IP prefix through a single TE-tunnel, then no matter what metric is assigned, the traffic has only one path to take 🧚.

The routing table described in this section can be seen as the private RIB for the IGP 🔐. The metric is an important attribute of the routes in the routing table. A path, or paths, with a lower metric gets selected over other paths for the same route in the routing table 👑.

4.1. Absolute and Relative Metrics ✨

okay so a TE-tunnel's metric can be set in two ways 🎀 an absolute (fixed) metric, or a relative one, which is just an adjustment to the dynamic IGP metric the SPF computation spits out. with an absolute metric, the cost of the IP routes in your routing table doesn't care about the topology anymore 💅 and this fixed number isn't only used for routes advertised by the tail-end router of the TE-tunnel, it's also used for every route downstream of that tail-end router. so if you have TE-tunnels to two core routers in a remote POP and one of them gets an absolute metric of 1, all the traffic heading to that POP is going to take that low-metric TE-tunnel. main character energy 🚇✨

with a relative metric, the cost of IP routes is based on the IGP metric the SPF computation calculates 🦋 the relative metric can be positive or negative. not configuring a metric on a TE-tunnel is just a special case of the relative metric scheme, since no metric is the same as a relative metric of 0 🌸 and the relative metric is bounded by minimum and maximum allowed metric values, while a positive metric disables the TE-tunnel in the SPF calculation 🙈

4.2. Examples of Metric Adjustment 🧚

let's look at this topology 👀 X, Y, and Z are IP prefixes advertised by rtrC, rtrD, and rtrE respectively. T1 is a TE-tunnel from rtrA to rtrC. every link in the network has an IGP metric of 10.

     ===== T1 =====>
   rtrA -- rtrB -- rtrC -- rtrD -- rtrE
        10      10  |   10  |   10  |
                    X       Y       Z

without TE-tunnel T1, rtrA installs IP routes X, Y, and Z in the routing table with metrics 20, 30, and 40 respectively 🍓 now once rtrA has brought up TE-tunnel T1 to rtrC, if rtrA is configured with the relative metric of -5 on tunnel T1, then routes X, Y, and Z get installed with metrics 15, 25, and 35. but if an absolute metric of 5 is configured on tunnel T1 instead, rtrA installs routes X, Y, and Z all with metrics 5, 15, and 25 respectively 🔥 the absolute version is giving full reset energy 💜

---

5. Security Considerations 🔐

okay this part is the serious one bestie 😭 this document does not change the security aspects of IS-IS or OSPF at all. the security considerations specific to each protocol still apply, so go check out [5] and [2] for the details 🫶

6. Acknowledgments 💖

the authors want to thank Joel Halpern and Christian Hopps for their comments on this document. the real MVPs 👑

7. Informative References 📚

• [1] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990.
• [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
• [3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
• [4] 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.
• [5] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
• [6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.

8. Authors' Addresses 🧑‍💻

Naiming Shen
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134

EMail: naiming@redback.com


Henk Smit

EMail: hhwsmit@xs4all.nl

9. Full Copyright Statement ⭐

Copyright (C) The Internet Society (2004).

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. it also doesn't represent that it has made any independent effort to identify any such rights. information on the IETF's procedures with respect to rights in IETF 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. 🫶✨