RFC 7948
Internet Exchange BGP Route Server Operations
RFC 7948: Internet Exchange BGP Route Server Operations 🎀
okay bestie, this is the title card 💅 It's an Informational doc, so it's not a standard, just really good advice 🌸 It was published in September 2016 and has ISSN 2070-1721. The authors are N. Hilliard (INEX), E. Jasinska (BigWave IT), R. Raszuk (Bloomberg LP), and N. Bakker (Akamai Technologies B.V.). The header doesn't say it obsoletes or updates anything 🦋
Abstract
okay so IXPs (Internet Exchange Points) are blowing up 💖 and that brings new problems for networks trying to connect to each other. Bilateral External BGP (EBGP) sessions between exchange participants used to be the main way to swap reachability info over an IXP. But the overhead of that approach causes serious operational and administrative scaling problems for IXP participants 😭
Multilateral interconnection through Internet route servers can seriously cut down that admin and operational overhead ✨ In some cases, route servers are literally the way IXP participants prefer to exchange routing info 👑
This document covers operational considerations for multilateral interconnections at IXPs 🧚
Status of This Memo
this one is not an Internet Standards Track spec, it's published for informational purposes 🎀
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for that 🙈
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7948.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons 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 in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 💅 Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3
3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4
4. Operational Considerations for Route Server Installations . . 6
4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6
4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 7
4.2.1.1. View Merging and Decomposition . . . . . . . . . 7
4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 8
4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8
4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8
4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 9
4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9
4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 10
4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 10
4.6.2. Internet Routing Registries . . . . . . . . . . . . . 10
4.6.3. Client-Accessible Databases . . . . . . . . . . . . . 10
4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 11
4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 11
4.9. BGP Operations and Security . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151. Introduction ✨
IXPs give their participants IP data interconnection facilities, running over data link-layer protocols like Ethernet 🌈 The Border Gateway Protocol (BGP) [RFC4271] is normally what handles swapping network reachability info over those links.
Bilateral interconnection between IXP participants means a lot of admin and operational overhead 😩 So IXP operators often deploy BGP route servers [RFC7947] to give everyone a simple, convenient way to connect with each other. A route server passes along BGP routes it gets from its BGP clients to its other clients, following a prespecified policy. You can think of it as an EBGP version of an Internal BGP (IBGP) [RFC4456] route reflector 💜
Route servers at IXPs need careful management, and operators really need to understand how they work and what their limits are 🧐 This document talks through several operationally relevant issues and gives recommendations to help route server operators set up a reliable interconnection service 🦋
1.1. Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🎀
The phrase "BGP route" in this document should be interpreted as the term "Route" described in [RFC4271] 💅
2. Bilateral BGP Sessions 🌸
Bilateral interconnection means connecting routers with individual BGP sessions between each pair of participant routers at an IXP so they can swap reachability info. Say an IXP participant wants an open interconnection policy, meaning they want to connect with as many other IXP participants as possible. Then they have to liaise with each of their intended interconnection partners 🫠 Once that's sorted, the interconnection gets set up bilaterally by configuring a BGP session on both participants' routers to exchange network reachability info. If every exchange participant connects with every other participant, you need a full mesh of BGP sessions, like in Figure 1 🕸️
___ ___
/ \ / \
..| AS1 |..| AS2 |..
: \___/____\___/ :
: | \ / | :
: | \ / | :
: IXP | \/ | :
: | /\ | :
: | / \ | :
: _|_/____\_|_ :
: / \ / \ :
..| AS3 |..| AS4 |..
\___/ \___/
Figure 1: Full-Mesh Interconnection at an IXPFigure 1 shows an IXP platform with four connected routers, run by four separate exchange participants, each with its own locally unique Autonomous System (AS) number: AS1, AS2, AS3, and AS4 🍓 The lines are BGP sessions, and the dotted edge is the IXP border. Each of these four participants wants to trade traffic with all the others, so you set up a full mesh of BGP sessions on every router connected to the exchange. That gives you six BGP sessions across the IXP fabric 🙌
The number of BGP sessions at an exchange has an upper bound of n*(n-1)/2, where n is the number of routers at the exchange. Lots of exchanges have huge numbers of participating networks, so the admin and operational overhead needed for an open interconnection scales quadratically 😭 New participants need a lot of up-front resourcing before they get value from their IXP connection, and existing participants have to keep committing ongoing resources to benefit from connecting with those newcomers. Main character problems, fr 💀
3. Multilateral Interconnection ✨
okay so multilateral interconnection runs on a route server 🧚 that's set up to pass BGP routes out to the client routers. The route server keeps the BGP NEXT_HOP attribute from every route it receives, and it hands those routes on with NEXT_HOP unchanged, following its configured routing policy as described in [RFC7947]. This is the lowkey genius part: an IXP participant router can grab an aggregated list of routes from every other route server client over a single BGP session to the route server, instead of needing a session with every router at the exchange 💖. That drops the total number of BGP sessions at an Internet exchange from n*(n-1)/2 to n, where n is the number of routers at the exchange 🫶.
Even though the route server talks BGP with each of its clients, it does not forward traffic itself, so it is not a router 🙈.
In real life, this gives you dense interconnection between IXP participants with very little admin overhead and much simpler, smaller router configs 💅. New IXP participants get immediate, extensive interconnection, and existing route server participants receive reachability information from those newcomers without necessarily having to touch their configurations. Iconic behaviour 👑.
___ ___
/ \ / \
..| AS1 |..| AS2 |..
: \___/ \___/ :
: \ / :
: \ / :
: \__/ :
: IXP / \ :
: | RS | :
: \____/ :
: / \ :
: / \ :
: __/ \__ :
: / \ / \ :
..| AS3 |..| AS4 |..
\___/ \___/Figure 2: IXP-Based Interconnection with Route Server 🌸
As you can see in Figure 2, each router on the IXP fabric only needs a single BGP session to the route server 🦋. From that one session it gets reachability information for all the other routers at the IXP that also connect to the route server.
Multilateral and bilateral interconnections between different autonomous systems aren't exclusive of each other, and it's super common to have both kinds of sessions running in parallel at an IXP 🌈. When that happens, the extra paths become available to the BGP Decision Process, which calculates a best path as normal ✨.
4. Operational Considerations for Route Server Installations 💅
4.1. Path Hiding
"Path hiding" is the term [RFC7947] uses for when a route server masks individual paths by applying conflicting routing policies to its Loc-RIB 🙈. When that happens, route server clients get incomplete information from the route server about network reachability, which is not a vibe 💀.
There are several ways to mitigate path hiding, and those are described in [RFC7947] 📚. The only one that doesn't need explicit support from the route server client, though, is for the route server itself to maintain an individual Loc-RIB for each client that's subject to conflicting routing policies 🎀.
4.2. Route Server Scaling
Deploying multiple Loc-RIBs on the route server is a simple way to dodge the path-hiding problem from Section 4.1 💖. The catch is that this approach needs way more computing resources on the route server than deploying a single Loc-RIB for all clients 😭. The BGP Decision Process [RFC4271] has to be applied to every Loc-RIB on the route server, so both the CPU and memory requirements on the host computer scale roughly as O(P * N), where P is the total number of unique paths the route server receives, and N is the number of route server clients that need a unique Loc-RIB 🧮. That's a super-linear scaling relationship, so big route servers may benefit from only deploying per-client Loc-RIBs where they're actually needed 🫶.
No matter whether any Loc-RIB optimization is in play, the route server's theoretical upper-bound network bandwidth requirements scale as O(P_tot * N), where P_tot is the total number of unique paths the route server receives, and N is the total number of route server clients 🌊. If P_avg (the arithmetic mean number of unique paths received per route server client) stays roughly constant even as the number of connected clients goes up, then the total number of prefixes equals the average number of prefixes multiplied by the number of clients. Symbolically, that's P_tot = P_avg * N. Now, if we assume the worst case, where every prefix has its own distinct set of BGP path attributes and so has to be sent individually, the bandwidth scaling function can be rewritten as O((P_avg * N) * N) or O(N^2) 😱. This quadratic upper bound on network traffic means the route server model may not scale well for larger numbers of clients 💀.
In practice though, most prefixes are tied to a limited number of BGP path attribute sets, so the route server can transmit BGP routes way more efficiently than the theoretical analysis suggests 🦋. In that analysis, P_tot keeps climbing with the number of clients, but it's capped by the size of the full default-free routing table of the network the IXP is located in 🌸. Observations from production route servers have shown that most route server clients don't really use custom routing policies, so the route server may not need per-client Loc-RIBs at all 🙌. These practical bounds shrink the theoretical worst case enough that route server deployments stay manageable, even on larger IXPs ✨.
4.2.1. Tackling Scaling Issues
Scaling route servers still presents serious practical challenges and needs careful attention 😤. Scaling analysis points to problems in three key areas: route processor CPU overhead from BGP Decision Process calculations, the memory needed to handle lots of different BGP path entries, and the network traffic bandwidth required to distribute those BGP routes from the route server to each route server client 💜.
4.2.1.1. View Merging and Decomposition
View merging and decomposition, outlined in [RS-ARCH], is a way to optimize memory and CPU requirements when multiple route server clients are subject to exactly the same routing policies 🧠. In that case, multiple Loc-RIB views can be merged into a single view ✨.
There are a few variations of this approach. If the route server operator already knows the interconnection relationships between route server clients, they can configure separate Loc-RIBs only for route server clients with unique routing policies 🎀. Since this approach needs that prior knowledge, the operator has to depend on each client sharing their interconnection policies, either in an internal provisioning database the operator controls or in an external data store such as an Internet Routing Registry Database 📋.
On the flip side, the route server implementation itself can do internal view decomposition by creating virtual Loc-RIBs based on a single in-memory master Loc-RIB, with delta differences for each prefix that's subject to different routing policies 🦋. This is a more fine-grained and flexible way to tackle Loc-RIB scaling, but the trade-off is a more complex in-memory Loc-RIB structure 🧩.
Whichever method of view merging and decomposition gets picked on a route server, pathological edge cases can be created where it scales no better than fully non-optimized per-client Loc-RIBs 💀. Still, since most route server clients connect to a route server to reduce overhead rather than to implement complex per-client routing policies, those edge cases tend not to show up in practice 🫶.
4.2.1.2. Destination Splitting
Destination splitting, also described in [RS-ARCH], is a method where route server clients connect to multiple route servers and send a non-overlapping set of prefixes to each one 🌈. Each route server computes the best path for its own set of prefixes, so the quadratic scaling requirement now applies to several smaller sets of prefixes instead of one big one 💅. That lowers the overall computational and memory requirements for managing multiple Loc-RIBs and running the best-path calculation on each 🙌.
In practice, the route server operator would need every route server client to send a full set of BGP routes to each route server 🌸. The operator can then selectively filter those prefixes for each route server, either by using BGP Outbound Route Filtering [RFC5291] or by configuring inbound prefix filters on client BGP sessions 🎀.
4.2.1.3. NEXT_HOP Resolution
Route servers are usually deployed at IXPs where every connected router is on the same Layer 2 broadcast domain 🧃. Because of that, recursive resolution of the NEXT_HOP attribute is generally not required, and it can be replaced by a simple check that the NEXT_HOP value for each received BGP route is a network address within the IXP LAN's IP address range ✨.
4.3. Prefix Leakage Mitigation
⚠️ Prefix leakage is when a BGP client accidentally distributes BGP routes to one or more neighboring BGP routers 😱. If each route server client is configured to accept all BGP routes from the route server, prefix leakage of this kind sent to a route server can cause serious connectivity problems at an IXP 🚨.
Because of how much collateral damage a BGP route leak can cause, deploying route servers comes with a firm recommendation: route server operators RECOMMENDED prefix leakage mitigation measures to either prevent unintentional prefix announcements or limit the scale of any such leak 🛡️. Okay so I know the wording there is a bit much, but the point is the operator should deploy those measures 💖. Per-client inbound prefix limits aren't foolproof, but they can restrict the damage from prefix leakage in many cases 🦋. Per-client inbound prefix filtering on the route server is a more deterministic and usually more reliable way to prevent prefix leakage, but it takes more administrative effort to maintain properly 🧹.
If a route server operator implements per-client inbound prefix filtering, then it is RECOMMENDED that the operator also builds in mechanisms that automatically compare the Adj-RIB-In received from each client with the inbound prefix lists configured for those clients 🔍. Naturally, the route server client is responsible for making sure their stated prefix list matches what they announce to an IXP route server 🫶. Still, plenty of network operators don't carefully manage their published routing policies, so it's not uncommon to see a big gap between the two sets of prefixes 😭. Route server operator visibility into that discrepancy can be a huge win for both the operator and the client 👑.
4.4. Route Server Redundancy 💖
okay so, bestie, the whole point of an IXP route server is to be a reliable reachability broker 🤝✨ so it is RECOMMENDED that exchange operators who run route server systems set up multiple route servers on each shared Layer 2 domain 🫶 you don't have to use the same BGP implementation or operating system on every one of them 🌈 BUT, and this is a big but 💅, if an operator does put more than one server on the same shared Layer 2 domain, it is RECOMMENDED that each route server implementation is configured equivalently, so the path reachability information from each system is identical 👑
4.5. AS_PATH Consistency Check 🎀
so [RFC4271] says that every BGP speaker that advertises a BGP route to another external BGP speaker MUST prepend its own AS number as the last element of the AS_PATH sequence 😭 which means the leftmost AS in an AS_PATH attribute should be equal to the AS number of the BGP speaker that sent the BGP route 🦋
now, as [RFC7947] suggests that route servers should NOT modify the AS_PATH attribute 🙈, a consistency check on the AS_PATH of a BGP route received by a route server client would normally fail 💀 so it is RECOMMENDED that route server clients disable the AS_PATH consistency check towards the route server 💜
4.6. Export Routing Policies 🌸
policy filtering is commonly implemented on route servers to give route server clients prefix distribution control 💅 a route server "export" policy is a policy that affects prefixes sent from the route server to a route server client 🧚 there are a few different strategies people commonly use for this 🔥
4.6.1. BGP Communities 🍓
prefixes sent to the route server get tagged with specific standard BGP Communities [RFC1997] or Extended Communities [RFC4360] attributes 🦋 based on predefined values agreed between the operator and all clients ✨ based on those Communities values, BGP routes may be propagated to all other clients, a subset of clients, or none 👑 this lets route server clients tell the route server how to apply per-client export routing policies 💖
ngl, here's the tricky part 🙈 standard BGP Communities and Extended Communities values are both restricted to 6 octets or fewer, so it is not possible for both the global and local administrator fields in the BGP Communities value to fit a 4-octet AS number 😭 bearing this in mind, the route server operator SHOULD take care to make sure that the predefined BGP Communities values mechanism used on their route server is compatible with 4-octet AS numbers [RFC6793] 🫶
4.6.2. Internet Routing Registries 🌈
Internet Routing Registry databases (IRRDBs) may be used by route server operators to construct per-client routing policies 💅 "Routing Policy Specification Language (RPSL)" [RFC2622] gives a comprehensive grammar for describing interconnection relationships ✨ and several toolsets exist that can translate RPSL policy descriptions into route server configurations 🧚
4.6.3. Client-Accessible Databases 🌸
okay so if the route server operator does NOT want to use either BGP Communities or the public IRRDBs for implementing client export policies 🙈 they MAY implement their own routing policy database system for managing their clients' requirements 💜 a database of this form SHOULD allow a route server client operator to update their routing policy 🫶 and provide a mechanism for the client to specify whether they wish to exchange all their prefixes with any other route server client 🦋 optionally, the implementation MAY allow a client to specify unique routing policies for individual prefixes over which they have routing policy control 🎀
4.7. Layer 2 Reachability Problems ⚡
layer 2 reachability problems on an IXP can cause seriously bad operational problems for IXP participants that depend on route servers for interconnection 😭 Ethernet switch forwarding bugs have occasionally been observed to cause non-transitive reachability 💀 for example, say there's a route server and two IXP participants, A and B 🧚 if the two participants can reach the route server but can't reach each other, then traffic between them may be dropped until the Layer 2 forwarding problem is fixed 🔥 this doesn't really happen in bilateral interconnection arrangements, because the routing control path between the two hosts is usually (but not always, thanks to IXP inter-switch connectivity load-balancing algorithms) the same as the data path between them 🌈
problems like this can be partially mitigated by using Bidirectional Forwarding Detection (BFD) [RFC5881] 💖 however, BFD is a bilateral protocol configured between routers, and there is currently no protocol to automatically configure BFD sessions between route server clients 🙈 so BFD does not currently provide an optimal way of handling the problem 💅 even if automatic BFD session configuration were possible, practical problems would remain 💀 say two IXP route server clients were configured to run BFD between each other and the protocol detected a non-transitive loss of reachability between them 😭 each of those routers would internally mark the other's prefixes as unreachable via the BGP path announced by the route server 🦋 and since the route server only propagates a single best path to each client, this could cause either sub-optimal routing or complete connectivity loss if there were no alternative paths learned from other BGP sessions 👑
4.8. BGP NEXT_HOP Hijacking 🚨
okay bestie, Item 2 in Section 5.1.3 of [RFC4271] lets EBGP speakers change the NEXT_HOP address of a received BGP route to be a different Internet address on the same subnet 🌸 this is the mechanism that lets route servers work on a shared Layer 2 IXP network ✨ but route server clients can abuse it to redirect traffic for their prefixes to other IXP participant routers 😤
____
/ \
| AS99 |
\____/
/ \
/ \
__/ \__
/ \ / \
..| AS1 |..| AS2 |..
: \___/ \___/ :
: \ / :
: \ / :
: \__/ :
: IXP / \ :
: | RS | :
: \____/ :
: :
....................
Figure 3: BGP NEXT_HOP Hijacking Using a Route Serverso in Figure 3, if AS1 and AS2 both announce BGP routes for AS99 to the route server, AS1 could set the NEXT_HOP address for AS99's routes to be the address of AS2's router 🙈 thereby diverting traffic for AS99 via AS2 💀 this may override the routing policies of AS99 and AS2 😭
worse still 😱 if the route server operator does not use inbound prefix filtering, AS1 could announce any arbitrary prefix to the route server with a NEXT_HOP address of any other IXP participant 🔥 this could be used as a denial-of-service mechanism against either the users of the address space being announced (by illicitly diverting their traffic) or the other IXP participant (by overloading their network with traffic that would not normally be sent there) 💀
this problem isn't specific to route servers 🧚 it can also be done using bilateral BGP sessions 🌈 but the potential damage is amplified by route servers, because a single BGP session can affect many networks at once 😭
because route server clients cannot easily implement next-hop policy checks against route server BGP sessions, route server operators SHOULD check that the BGP NEXT_HOP attribute for BGP routes received from a route server client matches the interface address of the client 💅 if the route server receives a BGP route where these addresses are different, and where the announcing route server client is in a different AS to the route server client that uses the next-hop address, the BGP route SHOULD be dropped 🚫 permitting next-hop rewriting for the same AS lets an organization with multiple connections into an IXP configured with different IP addresses direct traffic off the IXP infrastructure through any of their connections, for traffic engineering or other purposes 🎀
4.9. BGP Operations and Security 🛡️
BGP route servers SHOULD be configured and operated in compliance with [RFC7454] 💖 with the exception of Section 11, "BGP Community Scrubbing", which may not necessarily apply on a route server, depending on the route server operator policy 🙈
5. Security Considerations 😱
okay this section is serious, so let's go 🔥
on route server installations that do NOT employ path-hiding mitigation techniques, the path-hiding problem outlined in Section 4.1 could be used by an IXP participant to stop the route server from sending any BGP routes for a particular prefix to other route server clients 💀 even if there was a valid path to that destination via another route server client 😭
if the route server operator does NOT implement prefix leakage mitigation as described in Section 4.3, it is trivial for route server clients to launch denial-of-service attacks against arbitrary Internet networks by leaking BGP routes to a route server 🚨 literally anyone could do it 💀
route server installations SHOULD be secured against BGP NEXT_HOP hijacking, as described in Section 4.8 🛡️🫶
6. References 📚
6.1. Normative References 🎀
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <http://www.rfc-editor.org/info/rfc7947>.
6.2. Informative References 📚
okay these are the informative ones, aka the background reads that help you understand the vibe 🤓💅
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999,
<http://www.rfc-editor.org/info/rfc2622>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291,
August 2008, <http://www.rfc-editor.org/info/rfc5291>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<http://www.rfc-editor.org/info/rfc5881>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
Estrin, "A Route Server Architecture for Inter-Domain
Routing", 1995,
<http://www.cs.usc.edu/assets/003/83191.pdf>.Acknowledgments ✨
The authors gave a big shoutout to Chris Hall, Ryan Bickhart, Steven Bakker, and Eduardo Ascenco Reis for their valuable input 🫶💖
Authors' Addresses 🦋
Here's where you can find the authors, bestie 💌
Nick Hilliard
INEX
4027 Kingswood Road
Dublin 24
Ireland
Email: nick@inex.ie
Elisa Jasinska
BigWave IT
ul. Skawinska 27/7
Krakow, MP 31-066
Poland
Email: elisa@bigwaveit.org
Robert Raszuk
Bloomberg LP
731 Lexington Ave.
New York, NY 10022
United States of America
Email: robert@raszuk.net
Niels Bakker
Akamai Technologies B.V.
Kingsfordweg 151
Amsterdam 1043 GR
Netherlands
Email: nbakker@akamai.com📦 where this page comes from
- ietf: rfc7948 2016-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms