RFC 6227

Design Goals for Scalable Internet Routing

📅 published May 2011, from ietf

RFC 6227: Design Goals for Scalable Internet Routing 🌸

okay bestie, this one is the IRTF's wishlist for how the Internet's routing should level up ✨ It's RFC 6227, an Informational doc (not a Standards Track spec, so it's a vibe check, not a rulebook 💅). It's a product of the Internet Research Task Force, and the Routing Research Group signed off on it. It was published in May 2011, and the ISSN is 2070-1721. The editor is T. Li, from Cisco Systems, Inc. 🎀

It doesn't obsolete or update any other RFCs, since the header doesn't list any. 💖

Abstract 💖

The Internet routing and addressing setup is struggling with scalability, mobility, multi-homing, and inter-domain traffic engineering, and everyone knows it 😭 The Routing Research Group is looking at a different architecture to fix that. This doc is a prioritized list of design goals for that new architecture.

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's just published for info 🦋

It's a product of the IRTF, which shares results of Internet research and development. Those results might not be ready for deployment. This RFC reflects the consensus of the Routing Research Group of the IRTF. Docs approved by the IRSG are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🙈

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6227 🌈

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 📖

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Requirements Language ......................................3
      1.2. Priorities .................................................3
   2. General Design Goals Collected from the Past ....................3
   3. Design Goals for a New Routing Architecture .....................3
      3.1. Improved Routing Scalability ...............................3
      3.2. Scalable Support for Traffic Engineering ...................4
      3.3. Scalable Support for Multi-Homing ..........................4
      3.4. Decoupling Location and Identification .....................4
      3.5. Scalable Support for Mobility ..............................5
      3.6. Simplified Renumbering .....................................5
      3.7. Modularity, Composability, and Seamlessness ................6
      3.8. Routing Quality ............................................6
      3.9. Routing Security ...........................................7
      3.10. Deployability .............................................7
      3.11. Summary of Priorities .....................................7
   4. Security Considerations .........................................7
   5. References ......................................................8
      5.1. Normative References .......................................8
      5.2. Informative References .....................................8

1. Introduction ✨

Okay so, the Internet routing and addressing architecture is facing real challenges in inter-domain scalability, mobility, multi-homing, and inter-domain traffic engineering [RFC4984]. The Routing Research Group (RRG) wants to design an alternate architecture to handle this. This doc lays out a prioritized list of design goals for that target architecture 🧚

Think of these goals as guidelines for designing and evaluating possible solutions. They're meant to be applied with good judgment, not followed like a checklist 💅

The goals were first presented and discussed at the start of the RRG's work on a revised routing architecture. They were revisited and finalized once that work was done. So this is both the list the RRG started with and the updates they made after learning more about the space 🦋

1.1. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.2. Priorities 💜

Every design goal in this doc gets a priority, and it's one of these: 'required', 'strongly desired', or 'desired'.

  • Required: The solution is REQUIRED to support this goal.
  • Strongly desired: The solution SHOULD support this goal, unless there exist compelling reasons showing that it is unachievable, extremely inefficient, or impractical.
  • Desired: The solution SHOULD support this goal.

2. General Design Goals Collected from the Past 🍓

[RFC1958] lists the original architectural principles of the Internet. We pull those in by reference, and they count as part of our desired design goals 🫶

3. Design Goals for a New Routing Architecture 👑

3.1. Improved Routing Scalability 📈

The global BGP routing table keeps growing fast, and that's been clear for a long time [BGPGrowth]. Carrying all that state in inter-domain routing protocols is expensive, and it puts unfair costs on network participants who don't actually get value from a bigger routing table 😭 So the first required goal is a big improvement in the scalability of the inter-domain routing subsystem. It's strongly desired that the routing subsystem scales independently from growth in the Internet user population. If the user base and the routing subsystem are coupled, scalability basically goes out the window 💀 And if a solution supports alternative routes for faster convergence, those alternative routes should also count toward routing subsystem scalability ✨

3.2. Scalable Support for Traffic Engineering 🛣️

Traffic engineering means sending traffic along paths other than the ones normal IGP/EGP routing would pick. Right now, inter-domain traffic engineering often works by injecting more-specific prefixes into the global routing table, and that hurts routing scalability 🙈 Those extra prefixes add more load on the scalability of the routing architecture. But traffic engineering is essential to network operations, so a scalable solution for inter-domain traffic engineering is strongly desired 🌸

3.3. Scalable Support for Multi-Homing 🌐

Multi-homing is when an organization is connected to the Internet through more than one other organization. The current way to do it is to have the organization advertise one or more prefixes into the global routing system, which again hurts routing scalability 😤 More scalable multi-homing solutions are strongly desired 💖

3.4. Decoupling Location and Identification 🦋

Lots of sources have pointed out that an IP address carries both host attachment point information and identification information [IEN1]. That overloading has caused a bunch of semantic collisions that limit the flexibility of the Internet architecture 🙃 So it's desired that a solution separates the host location information namespace from the identification namespace.

Be careful here, though. You need to clearly tell apart decoupling host location from identification, and decoupling end-site addresses from globally routable prefixes. The second one has been proposed as an approach to a scalable routing architecture 👀 Solutions to both problems, meaning (1) decoupling host location from identification and (2) a scalable global routing system (whose solution may, or may not, depend on the second decoupling), are required. And it is required that their solutions are compatible with each other 🫶

Quick reminder: these two decouplings are different things, and the goals need solutions that work together ✨

3.5. Scalable Support for Mobility 🧳

Mobility is a host, network, or organization changing its topological connectivity with respect to the rest of the Internet, while still receiving packets from the Internet. Existing ways to support mobility are:

  1. renumbering the mobile entity as it changes its topological attachment point(s) to the Internet;
  2. renumbering and creating a tunnel from the entity's new topological location back to its original location; and
  3. letting the mobile entity announce its prefixes from its new attachment point(s).

The first approach by itself is considered unsatisfactory, since changing the IP address can break existing transport or higher-level connections that use IP addresses as identifiers 😭 The second needs a 'home agent' to track the mobile entity's current location. That adds overhead to the routers involved and also adds stretch to the path of an inbound packet. Neither of the first two approaches affects routing scalability. The third one, though, pushes dynamic updates into the global routing system every time the mobile entity moves 🌪️ Mechanisms that give more efficient and scalable mobility support are desired, especially if they can pair with security (especially privacy) and handle topological changes at a high rate 🔐 Ideally, those mechanisms should completely decouple mobility from routing 💜

3.6. Simplified Renumbering 🔢

Lots of end-sites get their IP address assignments from their Internet Service Providers (ISPs). When one of those sites changes providers, the site must renumber into a new address block from its new ISP, so routing can keep scaling. That can be costly, error-prone, and painful [RFC5887] 😩 Automated tools are expected to help a lot once they're developed. Full automation isn't expected, since some manual reconfiguration will probably be needed for the last-mile link. Still, the overall cost of renumbering should be drastically lowered 🙌

IP addresses also get used for other stuff, like access control lists. Sometimes they're hard-coded into applications running in places where a DNS failure could be catastrophic (for example, certain remote monitoring apps) 🚨 Renumbering might just be a mild inconvenience for some sites, and there are guidelines for renumbering a network without a flag day [RFC4192]. For others, the changes are hard enough that renumbering is effectively impossible 🥲 So it's strongly desired that a new architecture lets end-sites renumber with a lot less disruption. Or, if renumbering can be eliminated entirely, the new architecture must show how the topology can be economically morphed to fit the addressing ✨

3.7. Modularity, Composability, and Seamlessness 🎀

okay so a new routing architecture SHOULD NOT be one giant blob 🙅‍♀️ it should be modular, which means it breaks into multiple composable, extensible, and orthogonal subsystems 🧩. the interfaces between those modules should feel natural and seamless, no weird special cases or restrictions bestie 💖. the primitives and abstractions should be general enough that operations work on abstractions and concrete entities equally, and they shouldn't cause deleterious side-effects that get in the way of endpoints talking to each other across the Internet ✨. these properties are strongly desired in a solution, periodt 💅.

as an example 🦋, if a solution used tunneling, the tunneling should be completely transparent to both endpoints. they shouldn't need any new mechanisms just to figure out the correct maximum datagram size 🙈. that's giving invisible, iykyk.

the resulting network should always fully approximate today's best-effort Internet connectivity model 🌐, AND it should anticipate changes to that model, like multiple differentiated and/or guaranteed levels of service in the future 🔮. main character energy for future-proofing 👑.

3.8. Routing Quality 💜

the routing subsystem is responsible for computing a path from any point in the Internet to any other point in the Internet 🗺️. the quality of the computed routes can be measured with a bunch of metrics, like convergence, stability, and stretch 📊.

The stretch factor is the maximum ratio between the length of a route computed by the routing scheme and that of a shortest path connecting the same pair of nodes [JACM89].

ngl stretch is my favourite one 🤓. anyway, a solution is strongly desired to provide routing quality equivalent to what we have today, or better ⭐.

3.9. Routing Security 🔐

right now the routing subsystem is secured through a bunch of protocol-specific mechanisms, and they all have different strengths and applicability 🧐. any new architecture is required to provide at least the same level of security that's deployed at the time the new architecture gets deployed 🫶. no going backwards, bestie.

3.10. Deployability 🚀

a viable solution is required to be deployable from a technical perspective ✅. and because today's Internet has such an extensive deployed base, a solution is also required to be incrementally deployable 🧱. this means a solution must keep supporting the functions in today's routing subsystem that are actually used 🔁. this includes, but isn't limited to, the ability to control routing based on policy 🎛️. it's giving practicality, fr fr.

3.11. Summary of Priorities 🌈

here's the table that sums up the priorities of all the design goals we just went through 💅✨.

           +------------------------+------------------+
           | Design goal            | Priority         |
           +------------------------+------------------+
           | Scalability            | Strongly desired |
           | Traffic engineering    | Strongly desired |
           | Multi-homing           | Strongly desired |
           | Loc/id separation      | Desired          |
           | Mobility               | Desired          |
           | Simplified renumbering | Strongly desired |
           | Modularity             | Strongly desired |
           | Routing quality        | Strongly desired |
           | Routing security       | Required         |
           | Deployability          | Required         |
           +------------------------+------------------+

4. Security Considerations 💀

4. Security Considerations 💀

ok this one is SERIOUS bestie 😭🚨. all solutions are required to provide security that is at least as strong as the existing Internet routing and addressing architecture 🔒. this document doesn't suggest any default architecture or protocol, so this document introduces no new security issues 🙌. phew.

5. References 📚

5.1. Normative References 💖

  • [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
  • [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
  • [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.

5.2. Informative References 🦋

Author's Address ✍️

Tony Li (editor)
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA  95134
USA

Phone: +1 408 853 9317
EMail: tli@cisco.com

that's the whole thing bestie 🌈💖✨

📦 where this page comes from