RFC 5772

RFC 5772: A Set of Possible Requirements for a Future Routing Architecture ✨ (Part 1 of 14) 🦋

okay so bestie, this is an IRTF document (the research side of the Internet's standards world, not the official standards track 💅). It's RFC 5772, dated February 2010, and its category is Historic 📜. That means it's kept on file as a record of the past, not a rulebook you build from.

The writing team is A. Doria (LTU), E. Davies (Folly Consulting), and F. Kastenholz (BBN Technologies) 👑. It has an ISSN of 2070-1721 🔥. The header doesn't say it obsoletes or updates any other RFCs, so it's standing completely on its own 🌸.

---

Abstract 💜

so the requirements in this doc came out of two sub-groups under the IRTF Routing Research Group (RRG) back in 2001, with some editorial tidying up until 2006 🧚. The two groups worked totally independently, so you get two separate views on what the problem is and what it'd take to fix it. Main character energy for sure ✨

It's giving "recommended reading" for anyone designing routing architectures for the Internet in the future 📚

The doc was published with the RRG's support as a snapshot of the work done at that time. BUT (and this is important 🙈) it doesn't necessarily reflect the latest technical understanding or the group's consensus as of the publication date. so read it as history, not gospel 💅

---

Status of This Memo 🎀

this one is not an Internet Standards Track specification. It's published for the historical record 💖

It defines a Historic Document for the Internet community 🌈. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment, so don't just ship them 💀

This RFC is one or more individual people's opinions from the Routing Research Group of the IRTF, not an official group stance 🫶. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard. If you want the details on that, check Section 2 of RFC 5741 🔍

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc5772 🦋

---

Copyright Notice 🌸

Copyright (c) 2010 IETF Trust and the people identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions 🎀

---

Table of Contents 🧚

1. Background ......................................................4
2. Results from Group A ............................................5
   2.1. Group A - Requirements for a Next Generation Routing and
        Addressing Architecture ....................................5
        2.1.1. Architecture ........................................6
        2.1.2. Separable Components ................................6
        2.1.3. Scalable ............................................7
        2.1.4. Lots of Interconnectivity ..........................10
        2.1.5. Random Structure ...................................10
        2.1.6. Multi-Homing .......................................11
        2.1.7. Multi-Path .........................................11
        2.1.8. Convergence ........................................12
        2.1.9. Routing System Security ............................14
        2.1.10. End Host Security .................................16
        2.1.11. Rich Policy .......................................16
        2.1.12. Incremental Deployment ............................19
        2.1.13. Mobility ..........................................19
        2.1.14. Address Portability ...............................20
        2.1.15. Multi-Protocol ....................................20
        2.1.16. Abstraction .......................................20
        2.1.17. Simplicity ........................................21
        2.1.18. Robustness ........................................21
        2.1.19. Media Independence ................................22
        2.1.20. Stand-Alone .......................................22
        2.1.21. Safety of Configuration ...........................23
        2.1.22. Renumbering .......................................23
        2.1.23. Multi-Prefix ......................................23
        2.1.24. Cooperative Anarchy ...............................23
        2.1.25. Network-Layer Protocols and Forwarding Model ......23
        2.1.26. Routing Algorithm .................................23
        2.1.27. Positive Benefit ..................................24
        2.1.28. Administrative Entities and the IGP/EGP Split .....24
   2.2. Non-Requirements ..........................................25
        2.2.1. Forwarding Table Optimization ......................25
        2.2.2. Traffic Engineering ................................25
        2.2.3. Multicast ..........................................25
        2.2.4. Quality of Service (QoS) ...........................26
        2.2.5. IP Prefix Aggregation ..............................26
        2.2.6. Perfect Safety .....................................26
        2.2.7. Dynamic Load Balancing .............................27
        2.2.8. Renumbering of Hosts and Routers ...................27
        2.2.9. Host Mobility ......................................27
        2.2.10. Backward Compatibility ............................27
3. Requirements from Group B ......................................27
   3.1. Group B - Future Domain Routing Requirements ..............28
   3.2. Underlying Principles .....................................28
        3.2.1. Inter-Domain and Intra-Domain ......................29
        3.2.2. Influences on a Changing Network ...................29
        3.2.3. High-Level Goals ...................................31
   3.3. High-Level User Requirements ..............................35
        3.3.1. Organizational Users ...............................35
        3.3.2. Individual Users ...................................37
   3.4. Mandated Constraints ......................................38
        3.4.1. The Federated Environment ..........................39
        3.4.2. Working with Different Sorts of Networks ...........39
        3.4.3. Delivering Resilient Service .......................39
        3.4.4. When Will the New Solution Be Required? ............40
   3.5. Assumptions ...............................................40
   3.6. Functional Requirements ...................................42
        3.6.1. Topology ...........................................43
        3.6.2. Distribution .......................................44
        3.6.3. Addressing .........................................48
        3.6.4. Statistics Support .................................50
        3.6.5. Management Requirements ............................50
        3.6.6. Provability ........................................51
        3.6.7. Traffic Engineering ................................52
        3.6.8. Support for Middleboxes ............................54
   3.7. Performance Requirements ..................................54
   3.8. Backward Compatibility (Cutover) and Maintainability ......55
   3.9. Security Requirements .....................................56
   3.10. Debatable Issues .........................................57
        3.10.1. Network Modeling ..................................58
        3.10.2. System Modeling ...................................58
        3.10.3. One, Two, or Many Protocols .......................59
        3.10.4. Class of Protocol .................................59
        3.10.5. Map Abstraction ...................................59
        3.10.6. Clear Identification for All Entities .............60
        3.10.7. Robustness and Redundancy .........................60
        3.10.8. Hierarchy .........................................60
        3.10.9. Control Theory ....................................61
        3.10.10. Byzantium ........................................61
        3.10.11. VPN Support ......................................61
        3.10.12. End-to-End Reliability ...........................62
        3.10.13. End-to-End Transparency ..........................62
4. Security Considerations ........................................62
5. IANA Considerations ............................................63
6. Acknowledgments ................................................63
7. Informative References .........................................65

more sections coming up in part 2 🌈💖

1. Background ✨

okay so picture it: it's 2001 🌸 and the IRTF Routing Research Group (IRTF RRG) chairs, Abha Ahuja and Sean Doran, decide to set up a sub-group to look at requirements for inter-domain routing (IDR). 🦋 They pull together a squad of well-known routing experts with a totally blank-slate mandate. The group is free to take any approach, even a revolutionary one, to solve the problems they see in inter-domain routing 💅

Meanwhile, in Sweden, an independent effort kicks off with a similar goal 🧚 A team calling itself Babylon, with people from vendors, service providers, and academia, gets together to dig into the history of inter-domain routing, research the problems service providers are dealing with, and draft requirements for a follow-on to the current routing architecture. Their remit was different though. They had to take an evolutionary approach, starting from today's routing architecture and practice, so they limited themselves to an evolutionary strategy. The Babylon group was later folded into the IRTF RRG as Sub-Group B, to tell it apart from the original RRG Sub-Group A.

While the two groups were working in isolation, a big question came up: would their requirement sets look alike? Would the requirements that grew from a blank sheet of paper resemble the ones that started from evolution? Reading both sets, the answer is that there's a lot of fundamental agreement, but also some areas of disagreement 🤔

Some folks in the RRG suggested the two teams should merge into one set of requirements. But these requirements are only guidelines for future work, so some felt merging would risk losing content without gaining any real advantage. Nobody, like the IRTF RRG or the IETF Routing Area, was expected to use these requirements as written and build an architecture that met them. They were really strong recommendations for how to proceed. So in the end, the decision was to include both efforts' results, side by side, in one document 🎀

This document contains the two requirement sets. The text has only had editorial changes; the requirements themselves are unaltered. Whenever the editors felt conditions had changed in the few years since the text was written, they added an editors' note 📝

Now, the important bit: all of these requirements are suggestions, laid out to help people who are developing new routing architectures. The people behind them did their best to make intelligent suggestions, but there are no guarantees 🙈 So a reader should not treat this as absolute, and should not treat every suggestion as necessary. No architecture is expected to fulfill every "requirement". Hopefully though, future architectures will consider what's offered here 💜

The IRTF RRG supported publishing this document as a historical record of the work completed. It was published on the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the time of publication. The document has had substantial review over the years from members of the two teams, other members of the IRTF RRG, and additional experts ✨

Finally, this document does not claim that it is possible to have a practical solution that meets all the listed requirements 💀

---

2. Results from Group A

This section presents the results of the work done by Sub-Group A of the IRTF RRG during 2001-2002. The work originally appeared under the title: "Requirements For a Next Generation Routing and Addressing Architecture" and was edited by Frank Kastenholz 🌈

2.1. Group A - Requirements for a Next Generation Routing and Addressing Architecture

The requirements presented in this section are not presented in any particular order 🍓

2.1.1. Architecture

The new routing and addressing protocols, data structures, and algorithms need to be developed from a clear, well thought-out, and documented architecture 📐

The new routing and addressing system must have an architectural specification that describes all of the routing and addressing elements, their interactions, what functions the system performs, and how it goes about performing them. The architectural specification does not go into issues such as protocol and data structure design 🧠

The architecture should be agnostic with regard to specific algorithms and protocols 🫶

Doing architecture before doing detailed protocol design is good engineering practice 👑 It lets the architecture be reviewed and commented on, with changes made as necessary, while it's still easy to do so. Also, by producing an architecture, the eventual users of the protocols (the operations community) get a better understanding of how the designers of the protocols meant them to be used 💅

2.1.2. Separable Components

The architecture must place different functions into separate components 🎀

Separating functions, capabilities, and so forth into individual components, and making each component "stand alone", is generally considered by system architects to be "A Good Thing" 🌸 It lets each element be designed and tuned to do its job "very well". It also allows for piecemeal replacement and upgrading of elements as new technologies and algorithms become available ✨

The architecture must have the ability to replace or upgrade existing components and to add new ones, without disrupting the remaining parts of the system. Operators must be able to roll out these changes and additions incrementally (i.e., no "flag days"). These abilities are needed so the architecture can evolve as the Internet changes 🦋

The architecture specification shall define each of these components, their jobs, and their interactions 📋

Some thoughts to consider along these lines are:

• Making topology and addressing separate subsystems. This may allow highly optimized topology management and discovery without constraining the addressing structure or physical topology in unacceptable ways 🧚
• Separate "fault detection and healing" from basic topology. From Mike O'Dell:

Historically the same machinery is used for both. While attractive for many reasons, the availability of exogenous topology information (i.e., the intended topology) should, it seems, make some tasks easier than the general case of starting with zero knowledge. It certainly helps with recovery in the case of constraint satisfaction. In fact, the intended topology is a powerful way to state certain kinds of policy. [ODell01]

• Making policy definition and application a separate subsystem, layered over the others 💜

The architecture should also separate topology, routing, and addressing from the application that uses those components. This implies that applications such as policy definition, forwarding, and circuit and tunnel management are separate subsystems layered on top of the basic topology, routing, and addressing systems 🌈

2.1.3. Scalable 📈

Okay bestie, scaling is the main problem facing routing and addressing right now 😭. It has to get solved, and solved for the long term, not with a quick patch. The architecture must support a large and complex network. Ideally it'll last us the next 20 years, but honestly:

1. we don't know how big the Internet will grow over that time, and
2. the architecture we build might change the fundamental structure of the Internet, and therefore its growth patterns. That makes future growth really hard to predict 🔮.

So we can't quantify the requirement in any meaningful way. If we describe things using today's architectural elements, we think the network could grow to:

1. tens of thousands of ASs

Editors' Note: As of 2005, this level had already been reached.

2. tens to hundreds of millions of prefixes, during the lifetime of this architecture.

These sizes are a "flavor" of how we expect the Internet to grow, not hard numbers 🍓. We fully believe any new architecture may get rid of some current architectural elements and bring in new ones.

A new routing and addressing architecture designed around one specific network size would be inappropriate 🙅‍♀️. First, the cost of routing calculations depends only partly on the number of ASs or prefixes. The number and locations of the links in the network matter a lot too. Second, past predictions of Internet growth and topology patterns have been wildly inaccurate, so building for a specific size goal would be shortsighted at best.

Editors' Note: At the time of these meetings, the BGP statistics kept at sites such as www.routeviews.org either did not exist or had only been running for a few months. After 5 years of recording public Internet data, AS growth trends let us observe routing table growth (in the past) with some short-term prediction. Each year of data collection makes it better at observing and predicting trends. This architecture work pointed out the need for such statistics to improve future routing designs.

So we will not make the scaling requirement based on a specific network size. Instead, the new routing and addressing architecture should be able to constrain the increase in load (CPU, memory space and bandwidth, and network bandwidth) on ANY SINGLE ROUTER so it stays below these specific functions:

1. The computational power and memory sizes needed to run the routing protocol software and to hold the tables must grow more slowly than hardware capabilities described by Moore's Law, doubling every 18 months 🚀. Other observations suggest memory sizes double every 2 years or so.
2. Network bandwidth and latency are key constraints on how fast routing protocol updates can spread (and therefore how fast the routing system can adapt to changes). Raw network bandwidth seems to quadruple every 3 years or so. However, there seem to be some serious physics problems in going faster than 40 Gbit/s (OC768), so we shouldn't expect raw link speed to grow much beyond OC768. On the other hand, for economic reasons, large swathes of the Internet core will still run at lower speeds, possibly as slow as DS3.

Editors' Note: Technology is running ahead of imagination, and higher speeds are already common.

Even lower speed links exist in some parts of the Internet 🐢. Corporate access links are often T1 or slower. Low-speed radio links exist. Intra-domain links may be T1 or fractional-T1 (or slower).

So the architecture must not make assumptions about the bandwidth available.

3. The speeds of high-speed RAMs (Static RAMs (SRAMs), used for caches and the like) are growing, though slowly. Because they're used in caches and other very specific applications, these RAMs tend to be small, a few megabits, and their size isn't increasing very fast.

On the other hand, the speed of "large" memories (Dynamic RAMs (DRAMs)) is increasing even slower than that of the high-speed RAMs. This is because DRAM development is driven by the PC market, where size matters most, and low speed can be made up for with better caches.

Memory access rates shouldn't be expected to increase significantly.

Editors' Note: Various techniques have significantly increased memory bandwidth. 800 MHz is now possible, compared with less than 100 MHz in the year 2000. This does not, however, contradict the next paragraph, but rather just extends the timescales somewhat.

The growth in resources available to any one router will eventually slow down. It may even stop. Even so, the network will keep growing 📉➡️📈. The routing and addressing architecture must keep scaling even in this extreme condition. We can't keep adding computing power to routers forever, so other strategies must be available. Some possible strategies are hierarchy, abstraction, and aggregation of topology information 💡.

2.1.4. Lots of Interconnectivity 🕸️

The new routing and addressing architecture must be able to handle a high degree of interconnectivity in the Internet. That means there are large numbers of alternate paths and routes among the various elements. Mechanisms are required to stop this interconnectivity (and its continued growth) from making tables, compute time, and routing protocol traffic grow without bound. The "cost" to the routing system of added complexity must be limited in scope. Sections of the network that don't see the complexity, or don't care about it, ought not pay the cost of that complexity 💅.

Over the past several years, the Internet has become way more interconnected. Individual end sites (companies, customers, etc.), ISPs, exchange points, and so on are all connecting to more "other things" 🌐. Companies multi-home to multiple ISPs, ISPs peer with more ISPs, and so on. These connections are made for lots of reasons, like getting more bandwidth, better reliability and availability, policy, and so on. But this increased interconnectivity has a price 💸. It leads to more scaling problems because it increases the number of AS paths in the networks.

Any new architecture must assume the Internet will become a denser mesh. It must not assume, nor can it dictate, certain patterns or limits on how the various elements of the network interconnect.

Another facet of this requirement is that there may be multiple valid, loop-free paths available to a destination. See Section 2.1.7 for a further discussion 🔁.

We wryly note that one of the original design goals of IP was to support a large, heavily interconnected network, which would be highly survivable (such as in the face of a nuclear war) 💀.

2.1.5. Random Structure 🎲

The routing and addressing architecture must not place any constraints on, or make assumptions about, the topology or connectedness of the elements that make up the Internet. It must not presume any particular network structure. The network does not have a "nice" structure 🙃. We used to believe there was this nice "backbone/tier-1/tier-2/end-site" sort of hierarchy. That's not so. Therefore, any new architecture must not presume any such structure.

Some have proposed a geographic addressing scheme, requiring exchange points to be situated within each geographic "region". There are many reasons we believe this is a bad approach, but those arguments are irrelevant. The main issue is that the routing architecture should not presume a specific network structure 🗺️.

2.1.6. Multi-Homing 🏠

The architecture must provide multi-homing for all elements of the Internet. That means multi-homing of hosts, subnetworks, end-sites, "low-level" ISPs, and backbones (i.e., lots of redundant interconnections) must be supported. Reasons to multi-home include reliability, load sharing, and performance tuning 🎀.

The term "multi-homing" may be interpreted in its broadest sense: one "place" has multiple connections or links to another "place".

The architecture must not limit the number of alternate paths to a multi-homed site.

When multi-homing is used, it must be possible to use one, some (more than one but less than all), or all of the available paths to the multi-homed site. The multi-homed site must be able to declare which path(s) are used and under what conditions (for example, one path may be declared "primary" and the other "backup", to be used only when the primary fails) 🛤️.

A current problem on the Internet is that multi-homing leads to undue increases in the size of the BGP routing tables 😩. The new architecture must support multi-homing without undue routing table growth.

2.1.7. Multi-Path 🛣️✨

As a corollary to multi-homing, the architecture must allow multiple paths from a source to a destination to be active at the same time. These paths don't need to have the same attributes. Policies are used to disseminate the attributes and to classify traffic for the different paths.

There must be a rich "language" for specifying the rules for classifying traffic and assigning classes of traffic to different paths (or prohibiting it from certain paths). The rules should allow traffic to be classified based on, at least, the following:

• IPv6 FlowIDs,
• Diffserv Code Point (DSCP) values,
• source and/or destination prefixes, or
• random selections at some probability.

A mechanism is needed so operators can plan and manage the traffic load on the various paths. To start, this mechanism can be semi-automatic or even manual. Eventually, it ought to become fully automatic 🤖.

When multi-path forwarding is used, options must be available to preserve packet ordering where appropriate (such as for individual TCP connections) 📦.

Please refer to Section 2.2.7 for a discussion of dynamic load-balancing and management over multiple paths.

2.1.8. Convergence ⏱️

okay so convergence (also called the "stabilization time") is how long a router's routing processes take to settle on a new, stable "solution" (aka its forwarding information base) after something changes somewhere in the network 🌸 basically, the routing math stops changing. The Nth run of the software gives the exact same results as the N-1th run ✨

the speed of convergence is generally considered to be a function of the number of subnetworks in the network and the amount of connections between those networks. as either number grows, the time it takes to converge goes up 📈 (it's giving "big group chat = slower replies" energy 💀)

ngl, a change can also ripple back and forth through the whole system 🌊 one change makes some other router change what it advertises, which then sends a new change rippling through 🔁 these oscillations can take a while to work their way out of the network. and it's possible that the ripples never die out at all 😭 when that happens, the routing and addressing system is unstable, and it literally never converges.

finally, it's more than likely that the routers making up the Internet never converge, simply because the Internet is so large and complex 🌐 let's say it takes S seconds for the routers to stabilize on a solution for any one change, and changes happen, on average, every C seconds. because of the size and complexity of the Internet, C is now less than S 🙈 so if a change, C1, happens at time T, the routing system would stabilize at time T+S, but a new change, C2, will happen at time T+C, which is before T+S. the system starts processing the new change before it's finished with the old one. chaotic but make it routing 💅

this doesn't mean that every router is constantly processing changes 🫶 the effects of changes are like ripples in a pond, spreading outward from where they happened. some routers will be processing just C1, others C2, others both C1 and C2, and others neither.

we have two separate scopes where we can set requirements for convergence 🎀

1. Single Change: here, a single change of any type (link addition or deletion, router failure or restart, etc.) is introduced into a stabilized system, and no other changes are introduced. The system MUST re-stabilize within some measure of bounded time. this one is pretty abstract, since it would be impossible to test in a real network 🥺 defining the time constraints is still an open research issue.
2. System-Wide: setting a single target for maximum convergence time for the real Internet is absurd 💀 like we said earlier, the Internet is big and diverse enough that new changes are very likely to show up somewhere before the system fully digests the old ones.

so the first requirement is that there MUST be mechanisms to limit the scope of any one change's visibility and effects 🔍 the number of routers that have to do calculations in response to a change stays small, and so does the settling time. 🤌

the second requirement is based on these assumptions:

• the scope of a change's visibility and impact can be limited. that means routers within that scope know about the change and recalculate their tables based on it, while routers outside the scope don't see it at all 👀
• within any scope, S, network changes are constantly happening, and the average inter-change interval is Tc seconds.
• there are Rs routers within scope S.
• a subset of the destinations known to the routers in S, Ds, is impacted by a given change.
• we can state that for Z% of the changes, within Y% of Tc seconds after a change, C, X% of the Rs routers have their routes to Ds settled to a useful answer. "useful" means packets can get to Ds, though maybe not by the optimal path (this lets some "hunting" for the optimal solution happen 🏹).

X, Y, and Z are yet to be defined, and defining them remains a research issue 🧪

this requirement implies that scopes can be kept relatively small, so that Rs is minimized and Tc is maximized 📏

the growth rate of the convergence time MUST NOT be related to the growth rate of the Internet as a whole 🚫 this means the convergence time either:

1. is not a function of basic network elements (such as prefixes and links/paths), and/or
2. the Internet is continuously divisible into chunks that limit the scope and effect of a change, so the number of routers, prefixes, links, and so on, involved in the new calculations stays limited 🍰

---

2.1.9. Routing System Security 🔐

the security of the Internet's routing system is PARAMOUNT 😤 if the routing system gets compromised or attacked, the entire Internet can fail. that is unacceptable. any new architecture MUST be secure 🛡️

architectures by themselves are not secure. it's the implementation of an architecture, its protocols, algorithms, and data structures, that is secure or not 🧠 these requirements apply mainly to the implementation. the architecture MUST provide the elements the implementation needs to meet these security requirements, and it MUST NOT prevent these security requirements from being met 🙅‍♀️

"security" means different things to different people, so for this requirement to be useful, we have to define what we mean. we do that by identifying the attackers and threats we want to protect against. they are:

• Masquerading: the system, including its protocols, MUST be secure against intruders who adopt the identity of other known, trusted elements of the routing system and then use that position of trust to carry out other attacks 🥸 protocols MUST use cryptographically strong authentication.
• Denial-of-Service (DoS) Attacks: the architecture and protocols SHOULD be secure against DoS attacks directed at the routers. the new architecture and protocols SHOULD also provide as much information as they can, so administrators can track down sources of DoS and Distributed DoS (DDoS) attacks 🕵️‍♀️
• No Bad Data: any new architecture and protocols MUST provide protection against the introduction of bad, erroneous, or misleading data by attackers. most importantly, an attacker MUST NOT be able to redirect traffic flows with the intent of:
  • directing legitimate traffic away from a target, causing a denial-of-service attack by stopping legitimate data from reaching its destination,
  • directing additional traffic (going to other destinations that are "innocent bystanders") to a target, overloading the target, or
  • directing traffic addressed to the target to a place where the attacker can copy, snoop, alter, or otherwise affect it 😱
• Topology Hiding: any new architecture and protocols MUST provide mechanisms that let network owners hide the details of their internal topologies, while still keeping the desired levels of service connectivity and reachability 🫣
• Privacy: by "privacy" we mean privacy of the routing protocol exchanges between routers 🤫

when routers are on point-to-point links, with a router at each end, there may not be any need to encrypt the routing protocol traffic, since the chance of a third party intercepting it is limited (though not impossible) 🤏 we do believe, however, that it's important to be able to protect routing protocol traffic in two cases:

1. when the routers are on a shared network, there's a chance some hosts on that network have been compromised, and those hosts could secretly monitor the protocol traffic 👾
2. when two routers exchange information "at a distance" (over intervening routers and, possibly, across administrative domain boundaries). here, the security of the intervening routers, links, and so on, cannot be assured, so being able to encrypt this traffic is important 🔒

therefore, we believe that the option to encrypt routing protocol traffic is REQUIRED 🎯

• Data Consistency: a router SHOULD be able to detect and recover from any data received from other routers that is inconsistent. that is, it MUST NOT be possible for data from multiple routers, none of which is malicious, to "break" another router 🧩

where security mechanisms are provided, they MUST use methods that are considered cryptographically secure (for example, cryptographically strong encryption and signatures, no cleartext passwords!!) 🔑

use of security features SHOULD NOT be optional (except as REQUIRED above). okay, this might be "social engineering" on our part, but we believe it's necessary 💅 if a security feature is optional, the implementation of the feature MUST default to the "secure" setting 🔐

⚠️ bestie, this whole section is the reason the routing system can't be treated like an afterthought. if the security stuff fails, the whole Internet can fail with it 😭

---

2.1.10. End Host Security 🛡️

the architecture MUST NOT prevent individual host-to-host communications sessions from being secured. in other words, it cannot interfere with things like IPsec 🧁

---

2.1.11. Rich Policy 💅

before we set out policy requirements, we have to define the term 📝 like "security," "policy" means different things to different people. for our purposes, "policy" is the set of administrative influences that alter the path determination and next-hop selection procedures of the routing software 🎛️

the main motivators for influencing path and next-hop selection seem to be transit rules, business decisions, and load management 💼

the new architecture MUST support rich policy mechanisms. furthermore, the policy definition and dissemination mechanisms SHOULD be separated from the network topology and connectivity dissemination mechanisms 🧱 policy provides input to, and controls the generation of, the forwarding table and the abstraction, filtering, aggregation, and dissemination of topology information.

also, if the architecture is properly divided into subsystems, then at a later time, new policy subsystems with new features and capabilities could be developed and installed as needed 🌱

we divide the general area of policy into two sub-categories: routing information and traffic control 🚦

• Routing Information Policies control what routing information is disseminated or accepted, how it is disseminated, and how routers determine paths and next-hops from the received information 🗺️
• Traffic Control Policies determine how traffic is classified and assigned to routes 🎀

2.1.11.1. Routing Information Policies 🎀

okay bestie, there must be mechanisms that let network admins, operators, and designers decide who gets to hear routing info and who gets to send it 💅 these controls include, but are not limited to:

• picking which other routers the routing info gets sent to 📬
• deciding the "granularity" and type of info that gets sent out 🔍 (the length of IPv4 prefixes is a perfect example of granularity, obviously 🙄)
• filtering the topology and service info that gets transmitted, so different peers see different "views" of the internal structure and topology 🫣
• choosing how much security and authenticity the outgoing info gets 🔐
• making the level of detail for part of the network fade out the farther you get from that part of the network 🌫️
• picking who you'll accept routing info from. this one should be "provisional" 🥹 which means "accept routes from "foo" only if there are no others available"
• accepting or rejecting info based on the path it traveled (like, using the current system as an example, filtering routes when an AS shows up anywhere in the AS path). this one should be "use only if there are no other paths available" 🛤️
• picking the granularity you want for received routing info (this includes, but isn't limited to, stuff that's pretty similar to the prefix-length filters everyone uses in the current routing and addressing system) ✨
• choosing the level of security and authenticity that received info needs before it gets accepted 🛡️
• deciding how received routing info gets treated based on the attributes that came with it 🏷️
• slapping attributes on routing info you're about to send, then deciding how it gets treated based on those tags (like sending it "here" but not "there") 🍓
• filtering the topology and service info that gets received 💜

2.1.11.2. Traffic Control Policies 🚦

the architecture should give network operators mechanisms to manage and control the flow of traffic 💖 the traffic controls should include, but aren't limited to:

• the ability to detect congestion points in the network and eliminate them, by redirecting traffic around those points 🏃‍♀️💨
• the ability to build multiple paths through the network with different attributes, then assign traffic to those paths based on discriminators inside the packets. discriminators include, but aren't limited to, IP addresses or prefixes, IPv6 flow ID, DSCP values, and MPLS labels 🧚
• the ability to find and use multiple, equivalent paths through the network (ones that have the "same" attributes) and spread traffic across them 🌈
• the ability to accept or refuse traffic based on some traffic classification (basically giving you transit policies) 👑

Traffic classification must at least include the source and destination IP addresses (prefixes) and the DSCP value. Other fields may be supported, such as:

• protocol and port-based functions,
• the DSCP/QoS (Quality of Service) tuple (such as ports),
• per-host operations (i.e., /32s for IPv4 and /128s for IPv6), and
• traffic matrices (e.g., traffic from prefix X and to prefix Y).

2.1.12. Incremental Deployment 🌸

the reality of the Internet is that there can't be an Internet-wide cutover from one architecture and protocol to another 😭 so any new architecture and protocol must be incrementally deployable. ISPs need to be able to set up small sections of the new architecture, test it out, and then slowly grow those sections 🌱 eventually these sections will "touch" and "squeeze out" the old architecture 💅

the protocols that implement the architecture must be able to interoperate at "production levels" with currently existing routing protocols ⭐ and the protocol specs must define how that interoperability actually works 📜

we also believe that some sections of the Internet will never convert over to the new architecture 🙈 so it's important that the new architecture and its protocols can keep interoperating with "old architecture" regions of the network indefinitely 🫶

the architecture's addressing system must not force existing address allocations to be redone. no renumbering!! 🙅‍♀️

2.1.13. Mobility 🦋

there are two kinds of mobility: host mobility and network mobility. host mobility is when an individual host moves from where it was to where it is. network mobility is when an entire network (or subnetwork) moves 🚚

the architecture must support network-level mobility. for host mobility, check out Section 2.2.9 🔗

Editors' Note: Since the time of this work, the Network Mobility (NEMO) extensions to Mobile-IP [RFC3963] to accommodate mobile networks have been developed. 🙌

2.1.14. Address Portability 🧳

one of the biggest "hot items" in the current Internet political climate is portability of IP addresses (both v4 and v6) 🔥 the short version is that people really don't like renumbering when they change connection point or provider, and they don't trust automated renumbering tools 😤

the architecture must provide complete address portability. 💯

2.1.15. Multi-Protocol 🌍

the Internet is expected to be "multi-protocol" for at least the next several years 🗣️ IPv4 and IPv6 will coexist in lots of different ways during a transition period. the architecture must be able to handle both IPv4 and IPv6 addresses. protocols that replace IPv4 and IPv6 may be developed and deployed during the lifetime of the architecture too, so the architecture must be flexible and extensible enough to handle new protocols as they show up 🪄

also, the architecture must not assume any given relationship between a topological element's IPv4 address and its IPv6 address 🙅‍♀️ it must not assume that every topological element has IPv4 addresses/prefixes, and it can't assume they all have IPv6 addresses/prefixes either.

the architecture should let different paths to the same destination be used for different protocols, even if every path can carry every protocol 🛣️

on top of the addressing tech, the architecture doesn't need to be limited to only packet-based multiplexing/demultiplexing tech (like IP). support for other multiplexing/demultiplexing technologies may be added 🧩

2.1.16. Abstraction 🪞

the architecture must give network designers and operators mechanisms to:

• group elements together for administrative control purposes 🗂️
• hide the internal structure and topology of those groupings for administrative and security reasons 🙈
• limit how much topology info gets exported from the groupings, to control the load placed on external routers 🧘‍♀️
• define rules for traffic transiting or terminating in the grouping 🚪

the architecture must allow the current Autonomous System structure to be mapped into any new abstraction schemes 🗺️

mapping mechanisms, algorithms, and techniques must be specified. 📐

2.1.17. Simplicity ✏️

the architecture must be simple enough that someone who is extremely knowledgeable in routing, and really good at making straightforward, simple explanations, can explain all the important concepts in less than an hour ⏱️

this criterion was chosen because coming up with an objective measure of complexity for an architecture is super hard and out of scope for this document 🫠

the requirement is that the routing architecture be kept as simple as possible. this takes careful evaluation of possible features and functions, with a merciless weeding out of anything that "might be nice" but isn't necessary 🪓💅

keeping the architecture simple means the protocols and software used to implement it are simpler too, which leads to:

1. faster implementation of the protocols. fewer bells and whistles means fewer things to implement ⚡
2. more reliable implementations. with fewer components there's less code, which means fewer bugs and fewer interactions between components that could lead to unforeseen and incorrect behavior 🐛

2.1.18. Robustness 🛡️

the architecture, and the protocols implementing it, should be robust. robustness comes in lots of flavors. some things to consider for robustness include (but aren't limited to):

• continued correct operation in the face of:
  • defective (even malicious) trusted routers 😈
  • network failures. whenever possible, valid alternate paths are to be found and used 🔄
• failures must be localized. that is, the architecture must limit the "spread" of any adverse effects of a misconfiguration or failure. badness must not spread 🚫

of course, the general robustness principle of being liberal in what's accepted and conservative in what's sent must also be applied 🫶

Original Editor's Note: Some of the contributors to this section have argued that robustness is an aspect of security. I have exercised editor's discretion by making it a separate section. The reason for this is that to too many people "security" means "protection from break-ins" and "authenticating and encrypting data". This requirement goes beyond those views. 🧐

2.1.19. Media Independence 📡

it's an article of faith that IP operates over a wide variety of media (like Ethernet, X.25, ATM, and so on), but IP routing must take an agnostic view toward any "routing" or "topology" services offered by the medium IP is running over 🤷‍♀️ so the new architecture must not be designed to integrate with any media-specific topology management or routing scheme.

the routing architecture must assume, and must work over, the simplest possible media 🧃

the routing and addressing architecture can totally make use of lower-layer info and services when and where they're available, to whatever extent IP routing wants 😌

2.1.20. Stand-Alone 🏝️

the routing architecture and protocols must not rely on other components of the Internet (like DNS) for their correct operation 🙅‍♀️ routing is the fundamental process by which data "finds its way around the Internet", and most, if not all, of those other components rely on routing to properly forward their data 🔁 so routing can't rely on any Internet systems, services, or capabilities that in turn rely on routing. if it did, you'd get a dependency loop 💀

2.1.21. Safety of Configuration 🧸

the architecture, protocols, and standard implementation defaults must be set up so that a router installed "out of the box", with no configuration or anything else done by the operators, won't cause "bad things" to happen to the rest of the routing system (e.g., no dial-up customers advertising routes to 18/8!) 📞🙈

2.1.22. Renumbering 🔢

the routing system must allow topological entities to be renumbered 🪪

2.1.23. Multi-Prefix 🌷

the architecture must allow topological entities to have multiple prefixes (or the equivalent under the new architecture) 💐

2.1.24. Cooperative Anarchy ✨

Okay so, as RFC 1726[RFC1726] puts it:

A major contributor to the Internet's success is the fact that there is no single, centralized, point of control or promulgator of policy for the entire network. This allows individual constituents of the network to tailor their own networks, environments, and policies to suit their own needs. The individual constituents must cooperate only to the degree necessary to ensure that they interoperate.

This decentralization, called "cooperative anarchy," is literally still a key feature of the Internet today 🌈. The new routing architecture must keep it. There can be no centralized point of control or promulgator of policy for the entire Internet 🙅‍♀️. Iconic, honestly.

2.1.25. Network-Layer Protocols and Forwarding Model 🦋

For backward compatibility, any new routing and addressing architecture and protocols MUST work with IPv4 and IPv6 using the traditional "hop-by-hop" forwarding and packet-based multiplex/demultiplex models. BUT the architecture doesn't have to be stuck with those models 💅. Extra forwarding and multiplex/demultiplex models may be added, so there's room to grow.

2.1.26. Routing Algorithm 🌸

The architecture should not require a particular routing algorithm family. Put differently, it should be agnostic about link-state, distance-vector, or path-vector routing algorithms 🫶. No favourites, no drama.

2.1.27. Positive Benefit 👑

Finally, and this one is important, the architecture MUST show benefits in terms of increased stability, decreased operational costs, and increased functionality and lifetime, compared to the current schemes 🔥. That benefit has to stick around even after the inevitable costs of developing and debugging the new protocols, enduring the inevitable instabilities as things get shaken out, and so on 😭.

2.1.28. Administrative Entities and the IGP/EGP Split 🍓

We explicitly recognize that the Internet is made up of resources under control of multiple administrative entities. Each entity MUST be able to manage its own portion of the Internet as it sees fit 💖. The constraints you can put on routing and addressing inside one administration may not be feasibly extended to cover multiple administrations, so there's a natural and inevitable split between routing and addressing under single administrative control and routing and addressing that involves multiple administrative entities 🧚. And while there may be multiple administrative authorities, their boundaries may be complex and overlapping instead of a strict hierarchy. Messy, but real.

There may also be multiple levels of administration, each with its own level of policy and control. For example, a large network might have "continental-level" administrations covering its European and Asian operations, respectively. There would also be that network's "inter-continental" administration covering the Europe-to-Asia links. And finally, there would be the "Internet" level in the administrative structure (analogous to the "exterior" concept in the current routing architecture) 🌍.

So, we believe that the administrative structure of the Internet MUST be extensible to many levels (more than the two provided by the current IGP/EGP split) ✨. The interior/exterior property is not absolute. It's relative: a point on the network is interior with respect to some points and exterior with respect to others. Very "it depends," but in a good way 🙈.

Administrative entities may not trust each other, and some may be almost actively hostile toward each other 💀. The architecture MUST accommodate these models. Furthermore, the architecture MUST NOT require any particular level of trust among administrative entities 🛡️. Boundaries are for everyone, bestie.

2.2. Non-Requirements 🎀

The following are not required or are non-goals. That does NOT mean these issues must not be addressed by a new architecture. Rather, addressing them or not is purely an optional matter for the architects 🧁.

2.2.1. Forwarding Table Optimization 💜

We believe it is not necessary for the architecture to minimize the size of the forwarding tables (FIBs). Current memory sizes, speeds, and prices, along with processor and Application-specific Integrated Circuit (ASIC) capabilities, allow forwarding tables to be very large, O(E6), and allow fast (100 M lookups/second) tables to be built with little difficulty ⚡.

2.2.2. Traffic Engineering 🦄

"Traffic engineering" is one of those terms that has become terribly overloaded 😩. If you asked N people what traffic engineering is, you'd get something like N! disjoint answers 💀. So we elect not to require "traffic engineering" per se. Instead, we tried to figure out what the ultimate intent is when operators "traffic engineer" their networks, and then make those capabilities an inherent part of the system 🧠.

2.2.3. Multicast 🌊

The new architecture is not designed explicitly to be an inter-domain multicast routing architecture. However, given the notable lack of a viable, robust, and widely deployed inter-domain multicast routing architecture, the architecture should not hinder the development and deployment of inter-domain multicast routing without an adverse effect on meeting the other requirements 🤞.

We do note, however, that one respected network sage [Clark91] has said (roughly):

When you see a bunch of engineers standing around congratulating themselves for solving some particularly ugly problem in networking, go up to them, whisper "multicast", jump back, and watch the fun begin...

Iconic advice, no notes 😭🔥.

2.2.4. Quality of Service (QoS) 🎈

The architecture concerns itself primarily with disseminating network topology information so that routers may select paths to destinations and build appropriate forwarding tables. Quality of Service (QoS) is not part of this function, and we make no requirements with respect to QoS 🙅‍♀️.

However, QoS is an area of great and evolving interest. It's reasonable to expect that in the not too distant future, sophisticated QoS facilities will be deployed in the Internet. Any new architecture and protocols should be developed with an eye toward these future evolutions 👀. Extensibility mechanisms, allowing future QoS routing and signaling protocols to "piggy-back" on top of the basic routing system, are desired 🍭.

We DO require the ability to assign attributes to entities and then do path generation and selection based on those attributes. Some may call this QoS, and that's a whole vibe 💅.

2.2.5. IP Prefix Aggregation 🌙

There is no specific requirement that CIDR-style (Classless Inter-Domain Routing) IP prefix aggregation be done by the new architecture. Address allocation policies, societal pressure, and the random growth and structure of the Internet have all conspired to make prefix aggregation extraordinarily difficult, if not impossible 😵‍💫. This means large numbers of prefixes will be sloshing about in the routing system, and forwarding tables will grow quite big. We believe this is a cost that must be borne 🫠.

Nothing in this non-requirement should be read as saying that prefix aggregation is explicitly prohibited. CIDR-style IP prefix aggregation might be used as a mechanism to meet other requirements, such as scaling 🧩.

2.2.6. Perfect Safety 🛟

Making the system impossible to misconfigure is, we believe, not required. The checking, constraints, and controls necessary to achieve this could, we believe, prevent operators from performing necessary tasks in the face of unforeseen circumstances 😬.

However, safety is always a "good thing," and any results from research in this area should certainly be taken into consideration and, where practical, incorporated into the new routing architecture 💖.

2.2.7. Dynamic Load Balancing 🎢

History has shown that using the routing system to perform highly dynamic load balancing among multiple more-or-less-equal paths usually ends up causing all kinds of instability, etc., in the network 🙃. Thus, we do not require such a capability.

However, this is an area that is ripe for additional research, and some believe the capability will be necessary in the future. So the architecture and protocols should be "malleable" enough to allow development and deployment of dynamic load-balancing capabilities, should we ever figure out how to do it 🪄.

2.2.8. Renumbering of Hosts and Routers 🔢

We believe the routing system is not required to "do renumbering" of hosts and routers. That's an IP issue 💅.

Of course, the routing and addressing architecture must be able to deal with renumbering when it happens 🫶.

2.2.9. Host Mobility 📱

In the Internet architecture, host mobility is handled on a per-host basis by a dedicated, Mobile-IP protocol [RFC3344]. Traffic destined for a mobile host is explicitly forwarded by dedicated relay agents. Mobile-IP [RFC3344] adequately solves the host-mobility problem, and we do not see a need for any additional requirements in this area 🙌. Of course, the new architecture must not impede or conflict with Mobile-IP.

2.2.10. Backward Compatibility 🕰️

For the purposes of developing the architecture, we assume there is a "clean slate." Unless specified in Section 2.1, there are no explicit requirements that elements, concepts, or mechanisms of the current routing architecture be carried forward into the new one ✨. Fresh start, fresh vibes 🌈.

3. Requirements from Group B 🌟

The following is the result of the work done by Sub-Group B of the IRTF RRG in 2001-2002. It was originally released under the title "Future Domain Routing Requirements" and was edited by Avri Doria and Elwyn Davies 📜.

3.1. Group B - Future Domain Routing Requirements 🎀

It is generally accepted that there are major shortcomings in the inter-domain routing of the Internet today, and that these may result in meltdown within an unspecified period of time 😱. Remedying these shortcomings will require extensive research to tie down the exact failure modes that lead to them and to identify the best techniques to remedy the situation 🔍.

Reviewer's Note: Even in 2001, there was a wide difference of opinion across the community regarding the shortcomings of inter- domain routing. In the years between writing and publication, further analysis, changes in operational practice, alterations to the demands made on inter-domain routing, modifications made to BGP, and a recognition of the difficulty of finding a replacement may have altered the views of some members of the community. 🤔

Changes in the nature and quality of the services that users want from the Internet are difficult to provide within the current framework, as they impose requirements never foreseen by the original architects of the Internet routing system 🥹.

The kind of radical changes that have to be accommodated are epitomized by the advent of IPv6 and the application of IP mechanisms to private commercial networks that offer specific service guarantees beyond the best-effort services of the public Internet 🚀. Major changes to the inter-domain routing system are inevitable to provide an efficient underpinning for the radically changed and increasingly commercially-based networks that rely on the IP protocol suite. It's a glow-up, and the routing system has to level up with it 💜✨.

3.2. Underlying Principles ✨

okay so, inter-domain routing gets blamed for basically everything, but it's literally tangled up with intra-domain routing, and if we only change the inter-domain side, we're kinda stuck with the same mess 💅 so the whole area of routing has to be treated as one integrated system 🦋 there are two reasons for this:

• Requirements should not presuppose the solution. Sticking with today's definitions and the split between inter-domain and intra-domain routing would be a presupposition, and that's a big no 🙅‍♀️ so this part of the document calls it Future Domain Routing (FDR) 🌸
• We need to understand how closely inter-domain and intra-domain routing are related in today's routing architecture 🧠

ngl "domain routing" is a loaded phrase because people already use it in different ways 😭 the meaning will get built up naturally as we go, but we need a little explicit definition of "domain" first, plus some explanation of how far "routing" reaches 🎀

so this document uses "domain" in a super broad sense: any collection of systems or domains that falls under a common authority, which decides the attributes that define the collection and the policies that control it ✨ it's very similar to the region concept from John Wroclawski's Metanet model [Wroclawski95] 💜 the idea is that certain attributes shape how the systems inside a domain behave, and there are borders between domains 🌈 a domain doesn't have to behave the same way as every other domain, and it doesn't say anything about domains being hierarchical 🙈 it also doesn't limit what kinds of attributes can decide membership in a domain. and since today's routing domains are an example of this concept, we didn't bother inventing a new term 💖

current practice in routing-system design really pushes for separating the control plane from the forwarding plane inside a router 🔥 this document follows that practice, but we still use "routing" as a global portmanteau for all aspects of the system 🦋 specifically though, "routing" means the process of discovering, interpreting, and distributing information about the logical and topological structure of the network 💅

3.2.1. Inter-Domain and Intra-Domain

throughout this section we'll be using "intra-domain" and "inter-domain" 🎀 these are relative terms, so don't think of them as fixed labels ✨ in every domain there's a set of network systems inside it, and routing between those systems is called "intra-domain" 🌸 sometimes there's routing between domains, and that's called "inter-domain" 💜 and get this: the routing exchange between two network systems can be intra-domain from one point of view and inter-domain from another 🤯 iconic, honestly.

3.2.2. Influences on a Changing Network

the Internet is probably going to evolve because of a bunch of changes that will shake up how the network is organized and used 👑 here's the list:

• the commercial relationships between (connectivity) service providers keep evolving, which changes how peering between providers is organized and how transit traffic gets routed 💅
• there are growing requirements for traffic engineering within and between domains, including handling multiple paths between domains 🛣️
• a second IP addressing technique is being added in the form of IPv6 🌈
• VPNs and private address space are being used with both IPv4 and IPv6 🫶
• the end-to-end principle is evolving to handle the Internet's bigger role, as discussed in [Blumenthal01] 😭 that paper says the huge range of new requirements, especially the social and techno-political ones being dumped on the future, might compromise the Internet's original design principles 💀 the Internet could lose some of its key features, especially its ability to support new and unanticipated applications 🙈 this connects to the rise of new stakeholders (especially ISPs), new government interests, the changing motivations of an ever-growing user base, and the tension between wanting trustworthy overall operation and not being able to trust how individual users behave ⭐
• alternative forwarding techniques are being brought in, like the explicit routing (pipes) provided by the MPLS [RFC3031] and GMPLS [RFC3471] environments 🧚
• extra constraints are being pulled into route determination from interactions with other layers (for example, Shared Risk Link Groups [InferenceSRLG]) 🔗 this includes the worry that redundant routes shouldn't fate-share, for example because they physically run through the same trench 🕳️
• alternative and multiple routing techniques are being supported, because they're better suited to delivering types of content that aren't organized as IP-addressed packets 🍓

philosophically, the Internet's mission is to move information from one place to another 🌸 but that information is rarely neatly sized, IP-addressed packets 🙃 so the FDR has to think about how the information (content) being carried gets identified, named, and addressed ✨ once that's clear, routing techniques can be adapted to handle the expected types of content 💖

3.2.3. High-Level Goals

this section tries to answer two questions 🎀

• what are we trying to achieve in a new architecture?
• why should the Internet community care?

there's also a third question that really needs answering, but it's rarely been talked about explicitly 👀

• how will we know when we've succeeded?

3.2.3.1. Providing a Routing System Matched to Domain Organization

ok this one is so real: a lot of today's routing problems come from a routing system that doesn't really fit the organization and policies it's supposed to support 😤 our goal is a routing architecture where even a domain organization nobody has imagined yet can be served by an architecture that matches its requirements 🦋 we'll know we've nailed it when the desired policies, rules, and organization can be mapped into the routing system in a way that's natural, consistent, and easy to understand 👑

3.2.3.2. Supporting a Range of Different Communication Services

today's routing protocols only support a single forwarding service, which is usually used to deliver best-effort service on the public Internet 🥲 meanwhile Diffserv, for example, can build a bunch of different bit transport services inside the network 🌈 using some of the per-domain behaviors (PDB)s that have been discussed in the IETF, you can build services like Virtual Wire [DiffservVW] and Assured Rate [DiffservAR] ✨

providers today offer rudimentary promises about how traffic gets handled, like delay and long-term packet loss guarantees 🫠 and this is only going to matter more over time 📈 communicating the service characteristics of paths in routing protocols will be necessary in the near future, and it'll be necessary to route packets according to their service requirements 💅

so one goal of this architecture is to let adequate information about path service characteristics get passed between domains, which in turn allows delivery of bit transport services other than the best-effort datagram connectivity service that's the current common denominator 🎀

3.2.3.3. Scalable Well Beyond Current Predictable Needs

any proposed FDR system should scale beyond the size and performance we can foresee for the next ten years 🚀 the previous IDR proposal, as implemented by BGP, has held up for over ten years with some massaging 🧱 in that time the Internet grew way past the predictions that were implied by the original requirements 📈

unfortunately, we'll only know if we've succeeded here if the FDR system survives past its design lifetime without serious massaging 😬 failure will be much easier to spot, lol 💀

3.2.3.4. Alternative Forwarding Mechanisms

with circuit-based technologies (e.g., MPLS [RFC3031] and GMPLS [RFC3471]) being managed by IP routers, there are forwarding mechanisms besides the datagram service that the routing architecture needs to support 🧚

an explicit goal of this architecture is to add support for forwarding mechanisms other than the current hop-by-hop datagram forwarding service driven by globally unique IP addresses 🦋

3.2.3.5. Separation of Topology Map from Connectivity Service

an organization can run multiple services within a single network, and that's totally a thing 🫶 these services can be different in quality, different in connectivity type, or use different protocols (e.g., IPv4 and IPv6) 🌸 across all of them there may be a common domain topology, even though the policies controlling how information gets routed might differ from service to service 💜 so a goal of this architecture is to support separating the creation of a domain (or organization) topology map from service creation 🎀

3.2.3.6. Separation between Routing and Forwarding

a router is made of two main separable parts: control and forwarding 🔧 these parts depend on each other, but they do largely independent jobs 🙌 control (routing, signaling, and management) is usually done in software, while forwarding is typically done with specialized ASICs or network processors ⚡

today's IP-based network has control and data protocols sharing the same network and forwarding regime 🤔 that might not always be true in future networks, so we should be careful not to build this sharing into the FDR as an assumption 🙅‍♀️

a goal of this architecture is to fully separate control and forwarding, and to think about what other concerns might be properly handled separately (e.g., adjacency management) 💖

3.2.3.7. Different Routing Paradigms in Different Areas of the Same Network

a bunch of routing paradigms have been used or researched, on top of the conventional shortest-path-by-hop-count paradigm that's the current mainstay of the Internet 🌈 differences in the underlying transport networks can make other kinds of routing more relevant 🛤️ and the perceived need for traffic engineering will definitely change the routing chosen in various domains 👑

one of these routing paradigms should explicitly be the current one 🫶 that way, the new paradigms can inter-operate in a backward-compatible way with today's system 🦋 this makes a migration strategy possible that avoids flag days 🎀

3.2.3.8. Protection against Denial-of-Service and Other Security Attacks

okay so right now, if a route to a destination exists, that basically means anybody who can get a packet onto the network is allowed to use it 💀 there are some limits to that idea, but it's still giving denial-of-service attack energy 😭 a goal of the FDR system should be to let traffic be tied to whole or partial routes, so a destination or link's resources can be protected from unauthorized use 🛡️✨

Editors' Note: When sections like this one and the previous ones on quality differentiation were written, the idea of separating traffic for security or quality was considered an unqualified advantage. Today, however, in the midst of active discussions on Network Neutrality, it is clear that such issues have a crucial policy component that also needs to be understood. These, and other similar issues, are open to further research.

3.2.3.9. Provable Convergence with Verifiable Policy Interaction

this one is a whole thing 🧠 Griffin, et al. showed analytically ([Griffin99]), and [RFC3345] showed it in practice, that BGP won't converge stably, or is only meta-stable (meaning it won't re-converge when a single failure happens), when certain types of policy constraint get applied to categories of network topology 🌀 adding policy to the basic distance-vector algorithm breaks the convergence proofs that could be applied to a policy-free implementation 😩

it's also been argued that global convergence might not be a necessary goal anymore, and that local convergence may be all that's required 🤷‍♀️

so a goal of the FDR should be provable convergence for the protocols used, which may mean constraining the topologies and domains that are subject to convergence 💅 this also means vetting the policies being imposed, so they're compatible across domain boundaries and end up as a consistent policy set 🎀

Editors' Note: This requirement is very optimistic in that it implies that it is possible to get operators to cooperate even it is seen by them to be against their business practices. Though perhaps Utopian, this is a good goal.

3.2.3.10. Robustness Despite Errors and Failures

from time to time in Internet history, misconfigured routers have destroyed global connectivity 😱 that's a whole mood 🙈

a goal of the FDR is to be more robust against configuration errors and failures 💖 this should probably mean making sure the effects of a misconfiguration or failure can be confined to a suitable locality around the problem 🧚

3.2.3.11. Simplicity in Management

the policy work done at the IETF ([rap-charter02], [snmpconf-charter02], and [policy-charter02]) already gave us an architecture that standardizes and simplifies QoS management ✨ that kind of simplicity is needed in a Future Domain Routing architecture and its protocols, honestly it's non-negotiable 🫶

a goal of this architecture is to make configuration and management of inter-domain routing as simple as possible 🍓

Editors' Note: Snmpconf and rap are the hopes of the past. Today, configuration and policy hope is focused on netconf [netconf-charter].

3.2.3.12. The Legacy of RFC 1126

okay this is the origin story 🎬 [RFC1126] laid out a set of requirements that guided the development of BGP. the network has changed a lot since 1989, but a lot of those same requirements are still here 🌸 a future domain routing solution has to support, as its base requirement, the level of function that's available today, no exceptions 👑 there's a detailed discussion of RFC 1126 and its requirements in [RFC5773]. those requirements are spelled out in that document, but they're also subsumed by the requirements in this one 💜

3.3. High-Level User Requirements

this section looks at what the FDR's target audience needs, both for the organizations that might own networks that would use FDR and for the human users who'll have to interact with it 🫶

3.3.1. Organizational Users

the organizations that own networks connected to the Internet have gotten way more diverse since [RFC1126] came out 🌈 most notably, big chunks of the network are now owned by commercial service provider organizations that make their money carrying data traffic 💸

3.3.1.1. Commercial Service Providers

the routing system has to account for a commercial service provider's need for secrecy and security, and it should let them organize their business as flexibly as possible 🔐

service providers often want to hide the details of their network from other connected networks 🙈 as far as is possible, the routing system should not make service providers expose more of their topology and capabilities than is strictly necessary 🤐

lots of service providers offer contracts to customers in the form of Service Level Agreements (SLAs) 📝 the routing system must let providers support these SLAs through traffic engineering, load balancing, and multi-homing, giving the degree of resilience and robustness that's needed 💪

service providers can be sorted into these categories:

• Global Service Providers (GSPs) whose networks have a global reach. GSPs may, and usually will, wish to constrain traffic between their customers to run entirely on their networks. GSPs will interchange traffic at multiple peering points with other GSPs, and they'll need extensive policy-based controls to control the interchange of traffic. Peering may be through the use of dedicated private lines between the partners or, increasingly, through Internet Exchange Points. 🌍
• National, or regional, Service Providers (NSPs) that are similar to GSPs but typically cover one country. NSPs may operate as a federation that provides similar reach to a GSP and may wish to be able to steer traffic preferentially to other federation members to achieve global reach. 🗺️
• Local Internet Service Providers (ISPs) operate regionally. They'll typically purchase transit capacity from NSPs or GSPs to provide global connectivity, but they may also peer with neighboring, and sometimes distant, ISPs. 🏘️

the routing system should be flexible enough to handle the constantly changing business relationships of providers, and the different levels of trust they apply to customers and partners 🦋

service providers will need to be involved in accounting for Internet usage and monitoring traffic 📊 they may also be involved in government action to tax Internet usage, enforce social mores and intellectual property rules, or apply surveillance to traffic to detect or prevent crime 👀

3.3.1.2. Enterprises

the leaves of the network domain graph are, in many cases, networks supporting a single enterprise 🏢 these cover an enormous range of complexity. some multi-national companies own networks that rival the complexity and reach of a GSP, whereas many fall into the Small Office-Home Office (SOHO) category 🏠 the routing system should allow simple and robust configuration and operation for the SOHO category, while still effectively supporting the larger enterprises ✨

enterprises are especially likely to lack the capability to configure and manage a complex routing system, so every effort should be made to provide simple configuration and operation for these networks 🫶

enterprises will also need to be able to change their service provider with ease 🔄 this is mostly a naming and addressing issue, but the routing system must be able to support a seamless changeover. for example, if the changeover requires a change of address prefix, the routing system must be able to cope with a period when both sets of addresses are in use ⏳

enterprises will want to be able to multi-home to one or more providers as one possible way of boosting the resilience of their network 💖

enterprises will also frequently need to control the trust they place in both workers and external connections, through firewalls and similar mid-boxes placed at their external connections 🧱

3.3.1.3. Domestic Networks

increasingly, domestic (non-business home) networks are likely to be 'always on' and will resemble SOHO enterprise networks, with no special requirements on the routing system 🏡🌈

the routing system must also continue to support dial-up users 📞

3.3.1.4. Internet Exchange Points

peering between service providers, academic networks, and larger enterprises is happening more and more at specific Internet Exchange Points, where lots of networks are linked together in a fairly small physical area 🌐 the resources of the exchange may be owned by a trusted third party or owned jointly by the connecting networks 🤝 the routing systems should support these exchange points without requiring the exchange point to act as a superior entity with every connected network logically inferior to it, and without requiring the exchange point to be a member of one (or all) of the connected networks 🙅‍♀️ the connecting networks have to delegate a certain amount of trust to the exchange point operator 🔑

3.3.1.5. Content Providers

content providers are, on one level, a special class of enterprise 📦 but wanting to deliver content efficiently means a content provider may run multiple replicated origin servers or caches across a network 🚀 these may also be provided by a separate content delivery service 🌊 the routing system should facilitate delivering content from the most efficient location 🎯

3.3.2. Individual Users

this section covers the most important human users of the FDR and how they're expected to interact with the system 🧚‍♀️

3.3.2.1. All End Users

the routing system must keep delivering the current global connectivity service (meaning any unique address can reach any other unique address, subject to policy constraints) that has always been the basic aim of the Internet 🌍💜

end user applications should be able to request end-to-end communication services with QoS characteristics that differ from the best-effort service that today's Internet is built on ⭐ they can request this directly or have it requested on their behalf by agents and policy mechanisms 🤖 it should be possible to request both a single service channel and a bundle of service channels delivered as a single entity 🎁

3.3.2.2. Network Planners

the routing system should let network planners plan and implement a network that can be proved stable and will meet their traffic engineering requirements 📐

3.3.2.3. Network Operators

the routing system should, as far as is possible, be simple to configure, operate, and troubleshoot 🛠️ it should behave in a predictable and stable fashion, and deliver appropriate statistics and events so the network can be managed and upgraded efficiently and in a timely fashion ⏰

3.3.2.4. Mobile End Users

the routing system must support mobile end users 📱 it's very clear that mobility is becoming the main way people access networks 🦋

3.4. Mandated Constraints ✨

okay so not every requirement is a tech thing, bestie 💅 some are literally dictated by the real world around us. 🌍 To understand these, you have to look at where the systems will actually be deployed. The constraints come from:

• environmental factors,
• geography,
• political boundaries and considerations, and
• technological factors, like how different levels of technology are around in the developed world compared to the developing or undeveloped world. 🌸

3.4.1. The Federated Environment 🦋

the Internet graph, with routers and other control boxes as the nodes and communication links as the edges, is currently split administratively into a huge number of disjoint domains. 🕸️

one common administration might be responsible for one or more domains, and those domains may or may not be next to each other in the graph. 🫶

commercial and policy constraints that affect the routing system will usually be enforced at the boundaries of these domains, where traffic gets exchanged between them. 💼

the need for commercial confidentiality is super real, so it's going to push for minimizing the control information that crosses those boundaries. 🔒 that leads to needing aggregated information, abstracted maps of connectivity exported from domains, and a healthy amount of mistrust toward supplied information. 🙈

the desire for anonymity may require zero-knowledge security protocols so users can access resources without exposing their identity. 🧚

and the requirements should let groups of peering domains be treated as one complex domain. ✨ these complex domains could have a common administrative policy, which is lowkey iconic. 👑

3.4.2. Working with Different Sorts of Networks 🌈

the diverse Layer 2 networks that the Layer 3 routing system runs over have usually been operated totally independently from Layer 3, and often with their own routing mechanisms. 🙃 so we have to think about how much information should be swapped between the layers, and what kind of info it should be. 🤔 especially because guaranteed robustness through diverse routing layers means you need to know about the underlying networks. 🛡️

mobile access networks may also put extra requirements on Layer 3 routing. 📱

3.4.3. Delivering Resilient Service 🛟

the routing system operates at Layer 3 in the network. 🧭 to get robustness and resilience at this layer, when multiple diverse routes are used to deliver that resilience, the Layer 3 routing system needs to be assured that the Layer 2 and lower routes are actually diverse. 😤 the "diamond problem" is the simplest version of this: a Layer 3 provider tries to be diverse by buying Layer 2 services from two separate providers, but those providers both buy their Layer 1 services from the same provider. 💀

                     Layer 3 service
                      /           \
                     /             \
                 Layer 2         Layer 2
               Provider A      Provider B
                     \             /
                      \           /
                     Layer 1 Provider

now, when the backhoe cuts the trench, the Layer 3 provider has no resilience at all, unless they took special steps to verify that the trench wasn't shared. 🚜😭 the routing system should facilitate avoiding this kind of trap. 🪤

there's some work going on to understand the problems that come out of this requirement, like the work on Shared Risk Link Groups [InferenceSRLG]. 🔍 unfortunately, the full generality of the problem requires that diversity be maintained over time between an arbitrarily large set of mutually distrustful providers. 🥲 for some cases, it may be enough to check diversity at provisioning or route instantiation time, but this is still a hard problem that needs research work. 🧪

3.4.4. When Will the New Solution Be Required? ⏰

there's a full range of opinion on this one. 🗣️ an informal survey says the range runs from 2 to 6 years. and while there are some (possibly outliers) who think there's no need for a new routing architecture, and others who think one was needed years ago, the median seems to sit around 4 years. 📈 as with all projections of the future, this can't be proven right now. 🔮

Editors' Note: this paragraph was written in 2002, yet it could be written without change in 2006. 😭 as with lots of technical predictions and schedules, the horizon has stayed fixed through that whole interval. 🌀

---

3.5. Assumptions 💭

when projecting the requirements for the Future Domain Routing, a bunch of assumptions were made. 🧁 the requirements set out should be consistent with these assumptions, but there are definitely other assumptions that aren't explicitly spelled out here. 🫠

1. the number of hosts today is somewhere around 100 million. 🖥️ with dial-in, NATs, and the universal deployment of IPv6, this is likely to become up to 500 million users (see [CIDR]). in a number of years, with wireless accesses and different appliances attaching to the Internet, we're likely to see a couple of billion (10^9) "users" on the Internet. 📲 how many globally addressable hosts there are depends a lot on how common NATs will be in the future. 🎀
2. NATs, firewalls, and other middle-boxes exist, and we can't assume they'll stop being a presence in the networks. 🧱
3. the number of operators in the Internet probably won't grow very much, since operators will tend to merge. 🤝 but as Internet connectivity expands to new countries, new operators will emerge and then merge again. 🔁
4. at the beginning of 2002, there were around 12000 registered ASs. 📚 with current use of ASs (for example, multi-homing), the number of ASs could be expected to grow to 25000 in about 10 years [Broido02]. this is down from a previously reported growth rate of 51% per year [RFC3221]. future growth rates are hard to predict. 🤷‍♀️

Editors' Note: in the routing report table of August 2006, the total number of ASs present in the Internet Routing Table was 23000. 🎉 in 4 years, that's substantial progress on the prediction of 25000 ASs. also, there are significantly more ASs registered than are visibly active, i.e., in excess of 42000 in mid-2006. it's possible, though, that many are being used internally. 🕵️

5. in contrast to the number of operators, the number of domains is likely to grow significantly. 📈 today, each operator has different domains within an AS, but this also shows up in SLAs and policies internal to the operator. making this globally visible would create a number of domains: 10-100 times the number of ASs, i.e., between 100,000 and 1,000,000. 🤯
6. with more and more capacity at the edge of the network, the IP network will expand. 🌐 today there are operators with several thousands of routers, but this is likely to increase. some domains will probably contain tens of thousands of routers. 🗼
7. the speed of connections in the (fixed) access will technically be (almost) unconstrained. 🏎️ however, the cost of the links won't be negligible, so the apparent speed will be effectively bounded. within a number of years, some will have multi-gigabit speed in the access. ⚡
8. at the same time, the bandwidth of wireless access still has a strict upper bound. 📶 within the foreseeable future, each user will only have a tiny amount of resources available compared to fixed accesses (10 kbps to 2 Mbps for a Universal Mobile Telecommunications System (UMTS), with only a few achieving the higher figure, since the bandwidth is shared between the active users in a cell and only small cells can actually reach this speed; but 11 Mbps or more for wireless LAN connections). there may also be requirements for effective use of bandwidth as low as 2.4 Kbps or lower, in some applications. 🐢
9. assumptions 7 and 8 taken together suggest a minimum span of bandwidth between 2.4 kbps and 10 Gbps. 🌈
10. the speed in the backbone has grown rapidly, and there's no evidence the growth will stop in the coming years. 🚀 terabit speed is likely to be the minimum backbone speed in a couple of years. the range of bandwidths that need to be represented will need consideration on how to represent the values in the protocols. 🔢
11. there have been discussions about whether Moore's Law will keep holding for processor speed. 🤓 if Moore's Law doesn't hold, then communication circuits might play a more important role in the future. also, optical routing is based on circuit technology, which is the main reason for taking "circuits" into account when designing an FDR. 💡
12. however, the datagram model still remains the fundamental model for the Internet. 📦💖
13. the number of peering points in the network is likely to grow, as multi-homing becomes important. 🔗 also, traffic will become more locally distributed, which will drive the demand for local peering. 🏘️

Editors' Note: on the other hand, peer-to-peer networking may shift the balance in demand for local peering. 🔄

14. the FDR will achieve the same degree of ubiquity as the current Internet and IP routing. 🌍👑

---

3.6. Functional Requirements 📋

this section has a detailed discussion of new requirements for a Future Domain Routing architecture. 🧩 the nth requirement is labelled "R(n)". as discussed in Section 3.2.3.12, a new architecture must build upon the requirements of the past routing framework and must not reduce the functionality of the network. 🙅‍♀️ a discussion and analysis of the RFC 1126 requirements can be found in [RFC5773]. 📖

3.6.1. Topology 🗺️

3.6.1.1. Routers Should Be Able to Learn and to Exploit the Domain Topology 🧠

R(1) routers must be able to acquire and hold sufficient information on the underlying topology of the domain to allow the establishment of routes on that topology. 🗺️

R(2) routers must have the ability to control the establishment of routes on the underlying topology. 🎛️

R(3) routers must be able, where appropriate, to control Sub-IP mechanisms to support the establishment of routes. 🔧

the OSI Inter-Domain Routing Protocol (IDRP) [ISO10747] allowed a collection of topologically related domains to be replaced by an aggregate domain object, kind of like the Nimrod [Chiappa02] domain hierarchies. 🪆 this let a route be represented more compactly by a single collection instead of a sequence of individual domains. ✨

R(4) routers must, where appropriate, be able to construct abstractions of the topology that represent an aggregation of the topological features of some area of the topology. 🌟

3.6.1.2. The Same Topology Information Should Support Different Path Selection Ideas ✨

okay so the same topology info needs to be able to power a whole buffet of path selection methods 🍓 that we'd expect from a future Internet. that means distributed stuff like hop-by-hop, shortest path, local optimization constraint-based, class of service, source address routing, and destination address routing, plus the centralized, global optimization constraint-based "traffic engineering" vibe 💅. letting different path selection techniques coexist gives way more predictable and comprehensible results than the "clever tricks" we're stuck using today 😭. and traffic engineering functions need to be combined, bestie 🫶

R(5) routers must be capable of supporting a small number of different path selection algorithms. 🦋

3.6.1.3. Separation of the Routing Information Topology from the Data Transport Topology 🎀

R(6) the controlling network may be logically separate from the controlled network. 🧚

the two functional "planes" 💜 can physically live in the same nodes and share the same links, but that's not the only option, and sometimes other setups are necessary. an example is a pure circuit switch (one that can't see individual IP packets) paired with an external controller 🌸. another example might be multiple links between two routers, where all the links carry data forwarding but only one of them is used for carrying the routing session 👑

3.6.2. Distribution 🌈

3.6.2.1. Distribution Mechanisms

R(7) relevant changes in the state of the network, including modifications to the topology and changes in the values of dynamic capabilities, must be distributed to every entity in the network that needs them, in a reliable and trusted way, at the earliest appropriate time after the changes have occurred. ⭐

R(8) information must not be distributed outside areas where it is needed, or believed to be needed, for the operation of the routing system. 🙈

R(9) information must be distributed in such a way that it minimizes the load on the network, consistent with the required response time of the network to changes. 💖

3.6.2.2. Path Advertisement 🦋

R(10) the router must be able to acquire and store additional static and dynamic information that relates to the capabilities of the topology and its component nodes and links, and that can subsequently be used by path selection methods. ✨

the inter-domain routing system must be able to advertise more kinds of information than just connectivity and domain paths 🫶

R(11) the routing system must support service specifications, e.g., the Service Level Specifications (SLSs) developed by the Differentiated Services working group [RFC3260]. 💅

careful attention should be paid to making sure the distribution of additional information with path advertisements stays scalable as domains and the Internet get larger, more numerous, and more diversified 👀

R(12) the distribution mechanism used for distributing network state information must be scalable with respect to the expected size of domains and the volume and rate of change of dynamic state that can be expected. 🌸

the combination of R(9) and R(12) may result in a compromise between how responsive the network is to change and the overhead of distributing change notifications 😵‍💫 attempts to respond to very rapid changes may damage the stability of the routing system 💀

possible examples of additional capability information that might be carried include:

• QoS information

to let an ISP sell predictable end-to-end QoS service to any destination, the routing system should have information about the end-to-end QoS. this means that:

R(13) the routing system must be able to support different paths for different services. 🔥

R(14) the routing system must be able to forward traffic on the path appropriate for the service selected for the traffic, either according to an explicit marking in each packet (e.g., MPLS labels, Diffserv Per-Hop Behaviors (PHBs) or DSCP values) or implicitly (e.g., the physical or logical port on which the traffic arrives). 🧚

R(15) the routing system should also be able to carry information about the expected (or actually, promised) characteristics of the entire path and the price for the service. 🍓

(if that info gets exchanged at all between network operators today, it's through bilateral management interfaces, not the routing protocols 🙃)

this would let the operator optimize the choice of path based on a price/performance trade-off, which is very giving "best of both worlds" 🌈

in addition to dynamic QoS info, the system should be able to use static class-of-service information ✨

• Security information

security characteristics of other domains referred to by advertisements can let the routing entity make routing decisions based on political concerns 👑 the information itself is assumed to be secure so that it can be trusted 🔐

• Usage and cost information

usage and cost info can be used for billing and traffic engineering 💵 to support cost-based routing policies for customers (i.e., peer ISPs), info such as "traffic on this link or path costs XXX per Gigabyte" needs to be advertised, so the customer can pick a more or a less expensive route 🛒

• Monitored performance

performance info such as delay and drop frequency can be carried 📈 (this may only be suitable inside a domain because of trust considerations 🫣). it should support at least the kind of delay-bound contractual terms that service providers are currently offering. note that these values refer to the outcome of carrying bits on the path, whereas the QoS information refers to the proposed behavior that results in that outcome 🧠

• Multicast information

R(16) the routing system must provide information needed to create multicast distribution trees. this information must be provided for one-to-many distribution trees and should be provided for many-to-many distribution trees. 📡

the actual construction of distribution trees is not necessarily done by the routing system 🤷‍♀️

3.6.2.3. Stability of Routing Information 🌸

R(17) the new network architecture must be stable without needing global convergence, i.e., convergence is a local property. 🦋

the degree to which this is possible, and the definition of "local", remain research topics 🔬 restricting the convergence requirement to localities will affect all of the other requirements in this section 🫶

R(18) the distribution and the rate of distribution of changes must not affect the stability of the routing information. for example, commencing redistribution of a change before the previous one has settled must not cause instability. 💅

3.6.2.3.1. Avoiding Routing Oscillations 🌀

R(19) the routing system must minimize oscillations in route advertisements. 🙅‍♀️

3.6.2.3.2. Providing Loop-Free Routing and Forwarding 🔁

in line with the separation of routing and forwarding concerns:

R(20) the distribution of routing information must be, so far as is possible, loop-free. 💖

R(21) the forwarding information created from this routing information must seek to minimize persistent loops in the data-forwarding paths. 🧚

it's accepted that transient loops may occur during convergence of the protocol, and that there are trade-offs between loop avoidance and global scalability 🫶

3.6.2.3.3. Detection, Notification, and Repair of Failures 🚨

R(22) the routing system must provide means for detecting failures of node equipment or communication links. 👀

R(23) the routing system should be able to coordinate failure indications from Layer 3 mechanisms, from nodal mechanisms built into the routing system, and from lower-layer mechanisms that propagate up to Layer 3, in order to determine the root cause of the failure. this will let the routing system react correctly by activating appropriate mitigation and repair mechanisms if required, while making sure it does not react if lower-layer repair mechanisms can repair or mitigate the fault. 🧠

most Layer 3 routing protocols have used keepalives or "hello" protocols as a way of detecting failures at Layer 3 🏃‍♀️ those keepalive mechanisms are often backed up by analog mechanisms (e.g., laser-light detection) and hardware mechanisms (e.g., hardware/software watchdogs) built into routing nodes and communication links. great care must be taken to make the best possible use of the various failure repair methods available, while making sure that only one repair mechanism at a time is allowed to repair any given fault ⚠️

interactions between, for example, fast reroute mechanisms at Layer 3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) repair at Layer 1 are highly undesirable and are likely to cause problems in the network 💀

R(24) where a network topology and routing system contains multiple fault repair mechanisms, the responses of these systems to a detected failure should be coordinated so that the fault is repaired by the most appropriate means, and no extra repairs are initiated. 🎀

R(25) where specialized packet exchange mechanisms (e.g., Layer 3 keepalive or "hello" protocol mechanisms) are used to detect failures, the routing system must allow the configuration of the rate of transmission of these keepalives. this must include the capability to turn them off altogether for links that are deliberately broken when no real user or control traffic is present (e.g., ISDN links). 🌙

this lets the operator compromise between the speed of failure detection and the proportion of link bandwidth dedicated to failure detection 🎚️

3.6.3. Addressing 🏡

3.6.3.1. Support Mix of IPv4, IPv6, and Other Types of Addresses 🌍

R(26) the routing system must support a mix of different kinds of addresses. 🫧

this mix will include at least IPv4 and IPv6 addresses, and preferably various types of non-IP addresses too 💜 for instance, networks like SDH/SONET and Wavelength Division Multiplexing (WDM) may prefer to use non-IP addresses 💡 it may also be necessary to support multiple sets of "private" (e.g., RFC 1918) addresses when dealing with multiple customer VPNs 🔒

R(27) the routing system should support the use of a single topology representation to generate routing and forwarding tables for multiple address families on the same network. ✨

this capability would minimize the protocol overhead when exchanging routes 🏃‍♀️💨

3.6.3.2. Support for Domain Renumbering/Readdressing 🔄

R(28) if a domain is subject to address reassignment that would cause forwarding interruption, then the routing system should support readdressing (e.g., when a new prefix is given to an old network, and the change is known in advance) by maintaining routing during the changeover period [RFC2071] [RFC2072]. 🦋

3.6.3.3. Multicast and Anycast 🎀

R(29) okay bestie, the routing system must support multicast addressing, both within a domain and across multiple domains. 🦋

R(30) the routing system should support anycast addressing within a domain 💅. The routing system may support anycast addressing across domains, which is giving flexible vibes ✨.

ngl there's an open question here: is it possible, or even useful, to support anycast addressing between cooperating domains? 🤔

3.6.3.4. Address Scoping 🌸

R(31) the routing system must support scoping of unicast addresses, and it should support scoping of multicast and anycast address types. 🧚

The unicast address scoping that's being designed for IPv6 doesn't seem to cause any special problems for routing, so that's a W 🙌. IPv6 inter-domain routing only handles IPv6 global addresses, while intra-domain routing also needs to be aware of the scope of private addresses 👀.

Editors' Note: the original reference was to site-local addresses, but these have been deprecated by the IETF. Link-local addresses are never routed at all. 💀

More study may be needed to figure out the requirements and solutions for scoping in a more general sense, and for scoping of multicast and anycast addresses. It's a whole mystery 🔍.

3.6.3.5. Mobility Support 🦋

R(32) the routing system must support system mobility. The term "system" includes anything from an end system to an entire domain. Literally everything 😭.

We observe that the existing solutions based on renumbering and/or tunneling are designed to work with the current routing, so they don't add any new requirements to future routing. But the requirement is general, and future solutions may not be restricted to the ones we have today. Future-proofing era 🔮✨.

3.6.4. Statistics Support 📊

R(33) both the routing and forwarding parts of the routing system must maintain statistical information about the performance of their functions. Receipts, bestie 🧾💖.

3.6.5. Management Requirements 🎀

While the tools of management are outside the scope of routing, the mechanisms that support the routing architecture and protocols are within scope. Not the tools, but the bones 🦴.

R(34) mechanisms to support Operational, Administrative, and Management control of the routing architecture and protocols must be designed into the original fabric of the architecture. Built in from day one, no retrofits 🏗️🌈.

3.6.5.1. Simple Policy Management 📜

The basic aims of this specification are:

• to require less manual configuration than today, and
• to satisfy the requirements for both easy handling and maximum control. That is:
  • all the information should be available,
  • but should not be visible except for when necessary.
  • policies themselves should be advertised and not only the result of policy, and
  • policy-conflict resolution must be provided.

R(35) the routing system must provide management of the system by means of policies. For example, policies that can be expressed in terms of the business and services implemented on the network, and that reflect the operation of the network in terms of the services affected. Business brain, network brain 🧠💼.

Editors' Note: This requirement is optimistic in that it implies that it is possible to get operators to cooperate even if it is seen by them to be against their business practices. Big if, honestly 🙃.

R(36) the distribution of policies must be amenable to scoping to protect proprietary policies that aren't relevant beyond the local set of domains. Privacy for the policies, obviously 🔒.

3.6.5.2. Startup and Maintenance of Routers 🛠️

A major problem in today's networks is the need to perform initial configuration on routers from a local interface before a remote management system can take over. It's not clear that this imposes any requirements on the routing architecture beyond what's needed for a ZeroConf host 🤷‍♀️.

Similarly, maintenance and upgrades of routers can cause major disruptions to network routing, because the routing system and management of routers isn't organized to minimize that disruption. Some improvements have been made, like graceful restart mechanisms in protocols, but more needs to be done 😤.

R(37) the routing system and routers should provide mechanisms that minimize the disruption to the network caused by maintenance and upgrades of software and hardware. This requirement recognizes that some of the capabilities needed are outside the scope of the routing architecture (e.g., minimum impact software upgrade). Some of this is not our department, and that's fine 💅.

3.6.6. Provability 🧪

R(38) the routing system and its component protocols must be demonstrated to be locally convergent under the permitted range of parameter settings and policy options that the operator(s) can select. Show your work 📐.

There are various methods for demonstration and proof, including but not limited to: mathematical proof, heuristic, and pattern recognition. No requirement is made on the method used for demonstrating local convergence properties. Pick your fighter 🥊.

R(39) routing protocols employed by the routing system, and the overall routing system, should be resistant to bad routing policy decisions made by operators. Guardrails, please 🚧.

Tools are needed to check compatibility of routing policies. While these tools aren't part of the routing architecture, the mechanisms to support such tools are 🛠️✨.

Routing policies are compatible if their interaction does not cause instability. A domain or group of domains in a system is defined as being convergent, either locally or globally, if and only if, after an exchange of routing information, routing tables reach a stable state that does not change until the routing policies or the topology changes again. Stable is the goal, babe 🫶.

To achieve the above-mentioned goals:

R(40) the routing system must provide a mechanism to publish and communicate policies so that operational coordination and fault isolation are possible. Everyone gets the memo 📣.

Tools are required that verify the stability characteristics of the routing system in specified parts of the Internet. The tools should be efficient (fast) and have a broad scope of operation (check large portions of the Internet). While these tools aren't part of the architecture, developing them is in the interest of the architecture, and should be defined as a Routing Research Group activity while research on the architecture is in progress 🔬.

Tools analyzing routing policies can be applied statically or (preferably) dynamically. A dynamic solution requires tools that can be used for run-time checking for oscillations that arise from policy conflicts. Research is needed to find an efficient solution to dynamic checking of oscillations. The oscillation hunt continues 🌀.

3.6.7. Traffic Engineering 🚦

The ability to do traffic engineering, and to get feedback from the network to enable traffic engineering, should be included in the future domain architecture. Though traffic engineering has many definitions, at base it's another alternative or extension for the path selection mechanisms of the routing system. No fundamental changes to the requirements are needed, but the iterative processes involved in traffic engineering may require some additional capabilities and state in the network 🌊.

Traffic engineering typically involves a combination of off-line network planning and administrative control functions, in which expected and measured traffic flows are examined, resulting in changes to static configurations and policies in the routing system. It's a whole planning arc 🗓️.

During operations, these configurations control the actual flow of traffic and affect the dynamic path selection mechanisms. The results are measured and fed back into further rounds of network planning. Full loop, no cap 🔁💜.

3.6.7.1. Support for, and Provision of, Traffic Engineering Tools 🧰

At present, there's an almost total lack of effective traffic engineering tools, whether real-time for network control or off-line for network planning. The routing system should encourage the provision of such tools. Give us the tools, bestie 🥺.

R(41) the routing system must generate statistical and accounting information in such a way that traffic engineering and network planning tools can be used in both real-time and off-line planning and management. Data is the main character here 📈.

3.6.7.2. Support of Multiple Parallel Paths 🛣️

R(42) the routing system must support the controlled distribution, over multiple links or paths, of traffic toward the same destination. This applies to domains with two or more connections to the same neighbor domain, and to domains with connections to more than one neighbor domain. The paths need not have the same metric. Spread it out, queen 👑.

R(43) the routing system must support forwarding over multiple parallel paths when available. This support should extend to cases where the offered traffic is known to exceed the available capacity of a single link, and to cases where load is to be shared over paths for cost or resiliency reasons. Share the load, no drama 💖.

R(44) where traffic is forwarded over multiple parallel paths, the routing system must, so far as is possible, avoid reordering packets in individual micro-flows. Keep those packets in order, periodt 📦✨.

R(45) the routing system must have mechanisms to allow traffic to be reallocated back onto a single path when multiple paths aren't needed. Back to one lane when the traffic jam clears 🚗.

3.6.7.3. Peering Support 🤝

R(46) the routing system must support peer-level connectivity as well as hierarchical connections between domains. Both vibes, always 🌈.

The network is getting more and more complex, with private peering arrangements set up between providers at every level of the hierarchy of service providers, and even by certain large enterprises, in the form of dedicated extranets. It's giving spiderweb 🕸️💀.

R(47) the routing system must facilitate traffic engineering of peer routes, so that traffic can be readily constrained to travel as the network operators desire, allowing optimal use of the available connectivity. Operators get to steer, that's the whole point 🧭.

3.6.8. Support for Middleboxes 📦

One of our assumptions is that NATs and other middleboxes, such as firewalls, web proxies, and address family translators (e.g., IPv4 to IPv6), are here to stay. They're iconic, we know, we're not fighting it 😤💅.

R(48) the routing system should work in conjunction with middleboxes, e.g., NAT, to aid in bi-directional connectivity without compromising the additional opacity and privacy that the middleboxes offer. Help them connect, but don't spill their secrets 🤫🫶.

This problem is closely analogous to the abstraction problem, which is already under discussion for the interchange of routing information between domains. Same energy, different outfit 👗✨.

3.7. Performance Requirements ✨

okay so performance is a whole saga in this doc 💅 people have been talking about how the routing system performs for ages, and these are the requirements that came out of all that chatter. the actual numbers are still TBD, bestie 🙈

R(49) The routing system must support domains of at least N systems. A system is taken to mean either an individual router or a domain. 🌸

R(50) Local convergence should occur within T units of time. ⏱️

R(51) The routing system must be measurably reliable. The measure of reliability remains a research question. 🔬

R(52) The routing system must be locally stable to a measured degree. The degree of measurability remains a research issue. 🧠

R(53) The routing system must be globally stable to a measured degree. The degree of measurability remains a research issue. 🌍

R(54) The routing system should scale to an indefinitely large number of domains. 🚀

ngl there has been very little data or statistical evidence backing up a lot of the performance claims people made back in the day 😭 a few efforts kicked off in recent years to gather data and do the analyses needed for real scientific assessments of performance. to finish this section of the requirements analysis, that data and those analyses need to be gathered and collated into this document. that work has started but it is NOT done yet 💀

Editors' Note: This work was never completed due to corporate reorganizations.

---

3.8. Backward Compatibility (Cutover) and Maintainability 🦋

this area is kind of a dilemma, no cap 😩 on one hand, there is an absolute requirement that:

R(55) The introduction of the routing system must not require any flag days. 🚫

R(56) The network currently in place must continue to run at least as well as it does now while the new network is being installed around it. 🫶

however, at the same time, there is also a requirement that:

R(57) The new architecture must not be limited by the restrictions that plague today's network. ✨

it has to be admitted that R(57) is not a well-defined requirement, because we haven't fully spelled out what the restrictions even are 🙈 some of them can be derived from reading the discussions for the positive requirements above. it would be a super useful exercise to explicitly list every restriction and irritation we want to get rid of. it would also help to figure out whether these restrictions can be removed at a reasonable cost, or whether we are actually condemned to live with them 💀

those restrictions cannot be allowed to become permanent baggage on the new architecture. if they do, the effort to create a new system will come to naught 😭 it may, however, be necessary to live with some of them temporarily for practical reasons, while providing an architecture that will eventually allow them to be removed. the last three requirements matter not only for the transition strategy but also for the architecture itself. they imply that it must be possible for an internet such as today's BGP-controlled network, or one of its ASs, to exist as a domain within the new FDR. 👑

---

3.9. Security Requirements 🔐

as previously discussed, one of the big changes that has overtaken the Internet since its inception is the erosion of trust between end users, between those users and service suppliers, and between the multiplicity of providers. so security, in all its aspects, is going to be way more important in the FDR. it's giving main character energy 💅

It must be possible to secure the routing communication.

R(58) The communicating entities must be able to identify who sent and who received the information (authentication). 🪪

R(59) The communicating entities must be able to verify that the information has not been changed on the way (integrity). 🔒

security matters more in inter-domain routing, where the operator has no control over the other domains, than in intra-domain routing, where all the links and nodes are under the operator's administration and can be expected to share a trust relationship. but this intra-domain trust should not be taken for granted, bestie 🙅‍♀️

R(60) Routing communications must be secured by default, but an operator must have the option to relax this requirement within a domain where analysis indicates that other means (such as physical security) provide an acceptable alternative. 🏰

R(61) The routing communication mechanism must be robust against denial-of-service attacks. 🛡️

R(62) It should be possible to verify that the originator of the information was authorized to generate the information. ✅

further considerations that may impose further requirements include:

• whether no one else but the intended recipient is able to access (privacy) or understand (confidentiality) the information,
• whether it is possible to verify that all the information has been received and that the two parties agree on what was sent (validation and non-repudiation),
• whether there is a need to separate security of routing from security of forwarding, and
• whether traffic flow security is needed (i.e., whether there is value in concealing who can connect to whom, and what volumes of data are exchanged).

securing the BGP session, as done today, only secures the exchange of messages from the peering domain, NOT the content of the information. in other words, we can confirm that the information we got is what our neighbor really sent us, but we don't know whether or not that information (which originated in some remote domain) is true. 🤯

a decision has to be made on whether to rely on chains of trust (we trust our peers who trust their peers who..), or whether we also need authentication and integrity of the information end-to-end. this information includes both routes and addresses. there has been interest in having digital signatures on originated routes, as well as countersignatures by address authorities to confirm that the originator has authority to advertise the prefix. even understanding who can confirm that authority is non-trivial 😵‍💫 it might be the provider who delegated the prefix (with a whole chain of authority back to ICANN), or it might be an address registry. where a prefix delegated by one provider is being advertised through another provider, as in multi-homing, both may have to be involved to confirm the prefix may be advertised through a provider who doesn't have any interest in the prefix!

R(63) The routing system must cooperate with the security policies of middle-boxes whenever possible. 🧱

this is likely to involve further requirements for abstraction of information, for example a firewall that is trying to minimize interchange of information that could lead to a security breach. the effect of such changes on the end-to-end principle should be carefully considered, as discussed in [Blumenthal01]. 🧐

R(64) The routing system must be capable of complying with local legal requirements for interception of communication. ⚖️

---

3.10. Debatable Issues 🤔

this section covers issues that need to be considered and resolved when deciding on a Future Domain Routing architecture. they can't be described as requirements, but they DO affect which types of solution are acceptable. the discussions below are very open-ended, so buckle up 🎢

3.10.1. Network Modeling 🕸️

the mathematical model underlying today's routing system uses a graph representation of the network. hosts, routers, and other processing boxes are represented by nodes, and communications links by arcs. this is a topological model, meaning routing doesn't need to directly model the physical length of the links or the position of the nodes. the model can be transformed to give a convenient picture of the network by adjusting the lengths of the arcs and the layout of the nodes. the connectivity is preserved and routing is unaffected by this transformation 💖

the routing algorithms in traditional routing protocols use a small number of results from graph theory. it's only recently that additional results have been employed to support constraint-based routing for traffic engineering ✨

the naturalness of this network model and the "fit" of graph-theoretical methods may have tended to blind us to alternative representations, and may have kept us from chasing other strands of theoretical thinking that could give better results 👀

we should NOT let this habit stop us from looking for alternative representations and algorithms. topological revolutions are possible and allowed, at least in theory 🌈

3.10.2. System Modeling 🧩

the assumption that object modeling of a system is an essential first step to creating a new system is still pretty novel in this context. often, the object modeling effort becomes an end in itself and never leads to actually creating the system 😩 but there is a balance, and a lot can be discovered in an ongoing effort to model a system like the Future Domain Routing system. it is recommended that this process be included in the requirements. it should not, however, be a gating event for all other work 🚪

some of the most important realizations will happen while figuring out the following:

• Object classification
• Relationships and containment
• Roles and Rules

3.10.3. One, Two, or Many Protocols 📚

there has been a lot of discussion about whether the FDR protocol solution should be one (probably new) protocol, two (intra- and inter-domain) protocols, or many protocols. while it might be best to have one protocol that handles all situations, that seems unlikely 🥲 on the other hand, keeping the "strict" division we see in today's network between the IGP and EGP may be too restrictive an approach. given this, and the fact that there are already many routing protocols in use, the only possible answer seems to be that the architecture should support many protocols. whether a new protocol needs to be designed to support the highest goals of this architecture remains an open issue, one for the solution to settle. the expectation is that a new protocol WILL be needed 🫶

3.10.4. Class of Protocol 🗂️

if a new protocol is required to support the FDR architecture, it's still an open question what kind of protocol it ought to be. our expectation is that a map distribution protocol will be required to augment the current path-vector protocol and shortest path first protocols. 🗺️💜

3.10.5. Map Abstraction ✨

Okay so, if a map distribution protocol (the kind defined in [RFC1992]) is needed, what does that protocol have to do? If every single detail gets advertised across the whole Internet, that's a LOT of information 😭 Scalable solutions need abstraction, bestie.

• If we summarize too much, some information gets lost along the way 💀
• If we summarize too little, then more information than necessary is floating around, and that's what hurts scaling 🙈
• We can allow more summarization if there's also a mechanism to query for more details within policy limits 🧚
• The core requirement isn't that the information has to be advertised. It's that the information needs to be available to the folks who need it. We shouldn't presuppose that advertising is the only way to do that 💅

3.10.6. Clear Identification for All Entities 💖

The words we use for concepts and operations in routing matter SO much, fr fr. Instead of describing things with terms that are inaccurate or rarely used in the real world of networking, we should make an effort to use the correct words 🎀 Lots of networking terms get thrown around casually, and that leads to a partial or incorrect understanding of the concept underneath. Entities like nodes, interfaces, subnetworks, and tunnels need to be clearly identified and defined, and so do the grouping concepts like ASs, domains, areas, and regions, so nobody gets confused 🌸

There's also a need to separate identifiers (what or who) from locators (where) from routes (how to reach). Very important, very iconic 👑

Editors' Note: Work was undertaken in the shim6 working group of the IETF on this sort of separation. This work needs to be taken into account in any new routing architecture. 🫶

3.10.7. Robustness and Redundancy 🦋

The routing association between two domains should survive even if some individual connection between two routers goes down. Main character energy: one link dying should NOT ruin the whole vibe ✨

The "session" should operate between logical "routing entities" on each domain side, and not necessarily be bound to individual routers or addresses. A logical entity like that can be physically spread across multiple network elements. Or it can live in a single router, which would default to the current situation 🧚

3.10.8. Hierarchy 🌈

A more flexible hierarchy, with more levels and recursive groupings in both upward and downward directions, allows more structured routing. The payoff is that no single level gets too big for routers to handle 💜

BUT, ngl, the real-world Internet seems to be getting less hierarchical, so it's going to be harder and harder to use hierarchy to control scaling 😭

Also, groupings can look different depending on which aspect we use to define them. A Diffserv area, an MPLS domain, a trusted domain, a QoS area, a multicast domain, etc., don't always line up, and they aren't strict hierarchical subsets of each other either 🍓 The basic distinction at each level is "this grouping versus everything outside" 🙌

3.10.9. Control Theory 🔥

Is it possible to apply a control theory framework to analyze the stability of the control system of the whole network domain? We'd look at things like convergence speed and the frequency response, and then use those results to set the timers and other protocol parameters. Lowkey genius 🧠

Control theory could also play a part in QoS routing, by modifying current link-state protocols so link costs depend on load and feedback. Control theory is often used to make dynamic systems more stable ⭐

It might even be possible to build a brand-new, totally dynamic routing protocol based purely on control theory, as opposed to the current protocols, which are based on graph theory and are static in nature 🦋

3.10.10. Byzantium 💀

Is solving the Byzantine Generals problem a requirement? That's the problem of reaching a consensus among distributed units when some of them give misleading answers. At one level, the current intra-domain routing system is totally intolerant of misleading information 🙈 But the effect of different sorts of misleading or incorrect information varies wildly, from total collapse all the way down to purely local disconnection of a single domain. That's not very desirable, bestie 😭

There are, possibly, other network robustness issues that must be researched and resolved 🔍

3.10.11. VPN Support 💜

Today, BGP is also used for VPNs, for example, as described in RFC 4364 [RFC4364] 🎀

Internet routing and VPN routing have different purposes, and they most often exchange different information between different devices. Most Internet routers don't need to know VPN-specific information, so the concepts should be clearly separated 💅

When it comes to mechanisms, though, VPN routing can share the same protocol as ordinary Internet routing. It can use a separate instance of the same protocol, or it can use a different protocol altogether. All of these variants are possible and each has its own merits. These requirements are silent on this issue 🤐

3.10.12. End-to-End Reliability 🌸

The existing Internet architecture neither requires nor provides end-to-end reliability of control information dissemination. Hmm, but there's already a requirement for end-to-end reliability of control information distribution: the ends of the VPN that gets established need an acknowledgment that setting it up succeeded ✨ It's not necessarily the job of a routing architecture to provide end-to-end reliability for this kind of purpose. Still, we need to be clear that end-to-end reliability becomes a requirement if the network has to support that kind of reliable control signaling 🫶 There may be other requirements that come from requiring the FDR to support reliable control signaling 🧚

3.10.13. End-to-End Transparency 🦋

Private addressing schemes, Network Address Translators, and firewalls have significantly reduced the end-to-end transparency of the network 😭 In lots of cases the network is no longer symmetric either, so communication between two addresses is possible if the session starts from one end but not from the other. That's a problem for new peer-to-peer services and for "push" services, where the server in a client-server arrangement starts the communication session 🙃 Whether a new routing system can or should try to restore this transparency is still an open issue 🤔

A related issue is how far end-user applications should go in trying to control the routing of their communications to the rest of the network 👀

---

4. Security Considerations 🔐

We address security issues in the individual requirements. We also require that the architecture and protocols developed against this set of requirements be "secure." This is serious business, bestie 😤 Discussion of specific security issues can be found in the following sections:

• Group A: Routing System Security - Section 2.1.9
• Group A: End Host Security - Section 2.1.10
• Group A: Routing Information Policies - Section 2.1.11.1
• Group A: Abstraction - Section 2.1.16
• Group A: Robustness - Section 2.1.18
• Group B: Protection against Denial-of-Service and Other Security Attacks - Section 3.2.3.8
• Group B: Commercial Service Providers - Section 3.3.1.1
• Group B: The Federated Environment - Section 3.4.1
• Group B: Path Advertisement - Section 3.6.2.2
• Group B: Security Requirements - Section 3.9

5. IANA Considerations 📋

This document is a set of requirements from which a new routing and addressing architecture may be developed. From that architecture, a new protocol, or set of protocols, may be developed 🌈

While this note poses no new tasks for IANA, the architecture and protocols developed from this document probably will have issues that IANA needs to deal with 💅

6. Acknowledgments 💖

This document is the combined effort of two groups in the IRTF. Group A was formed by the IRTF Routing Research chairs, and Group B was self-formed and later got folded into the IRTF Routing Research Group. Each group has its own set of acknowledgments 🫶

Group A Acknowledgments 🌟

This originated in the IRTF Routing Research Group's sub-group on Inter-domain routing requirements. The members of the group were:

     Abha Ahuja                      Danny McPherson
     J. Noel Chiappa                 David Meyer
     Sean Doran                      Mike O'Dell
     JJ Garcia-Luna-Aceves           Andrew Partan
     Susan Hares                     Radia Perlman
     Geoff Huston                    Yakov Rehkter
     Frank Kastenholz                John Scudder
     Dave Katz                       Curtis Villamizar
     Tony Li                         Dave Ward

We also appreciate the comments and review received from Ran Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery Haas, Dmitri Krioukov, Russ White, and Alex Zinin. Special thanks to Yakov Rehkter for contributing text and to Noel Chiappa 🎀

Group B Acknowledgments 🌷

The document is derived from work originally produced by Babylon. Babylon was a loose association of individuals from academia, service providers, and vendors whose goal was to discuss issues in Internet routing with the intention of finding solutions for those problems 🦋

The individual members who contributed materially to this document are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen 🌈

Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically, we'd like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Torbjorn Lundberg, Jeremy Mineweaser, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, and Roberto Zamparo 💜

In addition, the authors are indebted to the folks who wrote all the references they consulted in putting this paper together. That includes not only the references explicitly listed below, but also those who contributed to the mailing lists they'd been participating in for years 📚

The editors thank Lixia Zhang, as IRSG document shepherd, for her help and her perseverance, without which this document would never have been published 👑

Finally, it's the editors who are responsible for any lack of clarity, any errors, glaring omissions, or misunderstandings. No cap, that's on them 🙈

7. Informative References ✨

okay bestie, this is the reading list 📚🎀 every single one of these is something the RFC leaned on, so I'm keeping every title, author, date and link exactly as it was. no cap 💅

• [Blumenthal01] Blumenthal, M. and D. Clark, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", May 2001, <http://dspace.mit.edu/handle/1721.1/1519>.
• [Broido02] Broido, A., Nemeth, E., Claffy, K., and C. Elves, "Internet Expansion, Refinement and Churn", February 2002.
• [CIDR] Telcordia Technologies, "CIDR Report", <http://www.cidr-report.org/>.
• [Chiappa02] Chiappa, N., "A New IP Routing and Addressing Architecture", July 1991, <http://ana-3.lcs.mit.edu/~jnc/nimrod/overview.txt>.
• [Clark91] Clark, D., "Quote reportedly from IETF Plenary discussion", 1991. 🙈
• [DiffservAR] Seddigh, N., Nandy, B., and J. Heinanen, "An Assured Rate Per-Domain Behaviour for Differentiated Services", Work in Progress, July 2001. 🦋
• [DiffservVW] Jacobson, V., Nichols, K., and K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Work in Progress, July 2000. 🌸
• [Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", SIGCOMM 1999. 🔥
• [ISO10747] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", International Standard 10747 ISO/IEC JTC 1, Switzerland, 1993. 🌈
• [InferenceSRLG] Papadimitriou, D., Poppe, F., J. Jones, J., S. Venkatachalam, S., S. Dharanikota, S., Jain, R., Hartani, R., and D. Griffith, "Inference of Shared Risk Link Groups", Work in Progress, November 2001. 💜
• [ODell01] O'Dell, M., "Private Communication", 2001. 🫶
• [RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989. ⭐
• [RFC1726] Partridge, C. and F. Kastenholz, "Technical Criteria for Choosing IP The Next Generation (IPng)", RFC 1726, Dec 1994. 🧚
• [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996. 👑
• [RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997. 🍓
• [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. 🎀
• [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. ✨
• [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001. 🌸
• [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. 🦋
• [RFC3344] Perkins, C., "IP Mobility Support.", RFC 3344, August 2002. 💅
• [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002. 😭
• [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 🔥
• [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. 🌈
• [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 💖
• [RFC5773] Davies, E. and A. Doria, "Analysis of Inter-Domain Routing Requirements and History", RFC 5773, February 2010. 🫶
• [Wroclawski95] Wroclowski, J., "The Metanet White Paper - Workshop on Research Directions for the Next Generation Internet", 1995. 🧚
• [netconf-charter] Internet Engineering Task Force, "IETF Network Configuration working group", 2005, <http://www.ietf.org/html.charters/netconf-charter.html>. 👑
• [policy-charter02] Internet Engineering Task Force, "IETF Policy working group", 2002, <http://www.ietf.org/html.charters/OLD/policy-charter.html>. 🍓
• [rap-charter02] Internet Engineering Task Force, "IETF Resource Allocation Protocol working group", 2002, <http://www.ietf.org/html.charters/OLD/rap-charter.html>. 🎀
• [snmpconf-charter02] Internet Engineering Task Force, "IETF Configuration management with SNMP working group", 2002, <http://www.ietf.org/html.charters/OLD/snmpconf-charter.html>. ✨

---

Authors' Addresses 🫶

meet the people who wrote this whole thing, bestie 💕 their contact details are right here, exactly as they were:

Avri Doria
LTU
Lulea  971 87
Sweden

Phone: +46 73 277 1788
EMail: avri@ltu.se


Elwyn B. Davies
Folly Consulting
Soham, Cambs
UK

Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com


Frank Kastenholz
BBN Technologies
10 Moulton St.
Cambridge, MA  02183
USA

Phone: +1 617 873 8047
EMail: frank@bbn.com

and that's a wrap on the whole RFC, besties! 🌈💖✨