RFC 7789
Impact of BGP Filtering on Inter-Domain Routing Policies
Impact of BGP Filtering on Inter-Domain Routing Policies 💖
Okay bestie, let's get into it ✨
Quick title-block tea 🫶
- This is RFC 7789 🎀
- Authors: C. Cardona (IMDEA Networks/UC3M), P. Francois, and P. Lucente (Cisco Systems) 👑
- Category: Informational, so it's published for info and is not a standards-track spec 📚
- Date: April 2016 🌸
- ISSN: 2070-1721
- It doesn't obsolete or update anything, so it's a fresh start 🦋
Abstract ✨
Okay so the abstract is giving "here's the drama" 😭 It explains how weird, unexpected traffic flows can show up across an autonomous system when other ASes filter or restrict the propagation of more-specific prefixes. It also reviews ways to detect this and defend against it. Iconic, honestly 💅
Status of This Memo 📝
This doc is not an Internet Standards Track spec. It's just here for informational purposes 🧚
It's a product of the Internet Engineering Task Force (IETF) 🌈 and it represents the consensus of the IETF community. It got public review and was 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 5741 for the details 🫶
You can find the current status, any errata, and feedback info at http://www.rfc-editor.org/info/rfc7789 💜
Copyright Notice 💅
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 🙈
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🔥
Table of Contents 🗺️
- Introduction 1.1. Terminology
- Unexpected Traffic Flows 2.1. Local Filtering 2.1.1. Unexpected Traffic Flows Caused by Local Filtering of More-Specific Prefixes 2.2. Remote Filtering 2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered Filtering of More-Specific Prefixes
- Techniques to Detect Unexpected Traffic Flows Caused by Filtering of More-Specific Prefixes 3.1. Existence of Unexpected Traffic Flows within an AS 3.2. Contribution to the Existence of Unexpected Traffic Flows in Another AS
- Techniques to Traffic Engineer Unexpected Flows 4.1. Reactive Traffic Engineering 4.2. Proactive Measures 4.2.1. Access Lists 4.2.2. Neighbor-Specific Forwarding
- Conclusions
- Security Considerations
- References 7.1. Normative References 7.2. Informative References Acknowledgements Authors' Addresses
1. Introduction 🦋
Okay so it's super common for network operators to propagate a more-specific prefix in the BGP routing system alongside the less-specific prefix they originate 💅 And some Autonomous Systems (ASes) can apply different policies to the more-specific and the less-specific prefix 👀
Here's the thing: BGP makes its own policy-driven choices about the best path for any given IP prefix 🧠 But routers have to forward packets using the longest-prefix-match rule, which "precedes" any BGP policy [RFC1812].
So if the Forwarding Information Base (FIB) has a prefix p that's more specific than a prefix p', packets whose destination matches p get forwarded to the next hop picked as best for p (the more-specific one) ✨ That happens by ignoring the control-plane policies used to pick the best next hop for p' 😭 When an AS filters more-specific prefixes but still forwards packets based on the less-specific prefix, the mismatch between the policies on the two prefixes can create unexpected traffic flows. Those can step on the toes of other ASes that still have a path toward the more-specific prefix 🙈
The goal here is to shed light on the side effects of more-specific prefix filtering 🔍 That kind of action could be traffic engineering, a misconfiguration, or even malicious intent 👀 The doc walks through examples of these side effects and talks about approaches to solving the problem 🧚
The rest of the document goes like this: Section 2 has scenarios where filtering more-specific prefixes creates unexpected traffic flows 🌸 Section 3 and Section 4 cover techniques ASes can use to detect these flows and react to them, respectively 💜 And then Section 5 wraps it all up 🎀
1.1. Terminology 📖
More-specific prefix: A prefix in the routing table whose address range is covered by a shorter prefix that's also in the routing table 💕
Less-specific prefix: A prefix in the routing table whose address range is partially covered by other prefixes 🌷
Customer-provider peering: A peering arrangement where a transit network gives connectivity to a customer in exchange for a fee, as derived from RFC 4384 [RFC4384] 💸
Settlement-free peering: A peering arrangement where two networks agree on settlement-free traffic exchange, usually covering only their customer traffic, as derived from RFC 4384 [RFC4384] 🤝
Selective advertisement: The behavior of only advertising a self-originated BGP path for a prefix over a strict subset of the External BGP (eBGP) sessions of the AS 📣
Selective propagation: The behavior of only propagating a BGP path for a prefix over a strict subset of the eBGP sessions of an AS 🎯
Local filtering: The behavior of explicitly ignoring a BGP path received over an eBGP session 🙅♀️
Remote filtering: The behavior of triggering selective propagation of a BGP path at a distant AS. Note that this is typically achieved by tagging a self-originated path with BGP communities defined by the distant AS 🌍
Unexpected traffic flow: Traffic flowing between two neighboring ASes of an AS, even though that AS's transit policy is to not provide connectivity between those two neighbors 😳 A traffic flow across an AS between two of its transit providers, or between a transit provider and one of its settlement-free peers, are the classic examples 🫣
2. Unexpected Traffic Flows 🌊
In this section we look at how more-specific prefix filtering can lead to unexpected traffic flows in other, remote, ASes 🛰️ We split things into cases where the filtering happens locally and cases where it gets triggered remotely 💅
2.1. Local Filtering 🏠
There are different reasons someone might do local filtering, for example:
Traffic engineering: An ISP can decide to filter more-specific prefixes when it wants to control its local outbound traffic distribution using only the policy applied to the less-specific prefix 🎛️ This practice was notably documented in a presentation by Init7 [INIT7-RIPE63] 🎤
Enforcing contract compliance: An ISP can decide to filter more-specific prefixes to enforce clauses of its peering agreements 📜 For instance, a settlement-free peer of an ISP can use selective advertisement of more-specific prefixes to attract traffic to one link. If that practice isn't allowed by their peering agreement, the ISP can filter the more-specific prefixes to stop it 🚫
Memory preservation: An ISP can decide to filter more-specific prefixes in order to preserve FIB memory on its routers 🧠💾
Figure 1 shows a scenario where one AS does local filtering because of outbound traffic engineering 🗺️ The figure shows AS64504 and two of its neighboring ASes, AS64502 and AS64505. AS64504 has a settlement-free peering with AS64502 and is a customer of AS64505 💁 AS64504 receives prefixes 2001:DB8::/32 and 2001:DB8::/34 from AS64505, and it only gets the less-specific prefix 2001:DB8::/32 from AS64502 🌸
,-----.
/ \
( AS64505 )
\ /
`--+--'
2001:DB8::/32 | |
2001:DB8::/34 v |
|
,--+--. 2001:DB8::/32 ,-----.
/ \ <-- / \
( AS64504 )-------------( AS64502 )
\ / \ /
`-----' `-----'Figure 1: Local Filtering 🎀
Okay so here's the tea 🍵 AS64504 might prefer sending traffic to AS64502 instead of AS64505 for economic reasons 💸 But even if paths from AS64502 get a large local preference, the routers in AS64504 will still send traffic to prefix 2001:DB8::/34 via neighbor AS64505 😤 That can push AS64504 to apply an inbound filter for the more-specific prefix 2001:DB8::/34 on the session with AS64505 🚧 Once that filter is in place, AS64504 sends traffic for the more-specific prefix to AS64502 instead, and it's giving main character energy 👑✨
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of More-Specific Prefixes 🎀
Okay so in this bit we're showing how AS64504 deciding to do local filtering ends up creating unexpected traffic flows in AS64502 😭. Figure 2 gives you the whole picture: AS64501 is a customer of AS64503 and AS64502, AS64503 is a settlement-free peer with AS64502, and AS64503 and AS64502 are both customers of AS64505. The AS originating the two prefixes, AS64501, does selective advertisement with the more-specific prefix and only announces it to AS64503 💅.
After AS64504 locally filters the more-specific prefix, traffic from AS64504 to 2001:DB8::/34 gets forwarded towards AS64502. Because AS64502 receives the more-specific prefix from AS64503, that traffic follows the path AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are set up to avoid carrying traffic between AS64504 and AS64503. BUT due to the discrepancies of routes between the more-specific and the less-specific prefixes, unexpected traffic flows between AS64504 and AS64503 still exist in AS64502's network 💀.
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| |________| |
| | /32 | |/32 /32| |
'. ,' . ,' /34 . ,'
`. ,' `. ,' +-> <-+ `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
Figure 2: Unexpected Traffic Flows Due to Local Filtering2.2. Remote Filtering 🦋
ISPs can tag the BGP paths they propagate to neighboring ASes with communities, which lets them tweak how the ASes handling those paths propagate them. See a paper from 2008 by Donnet and Bonaventure [on_BGP_communities] for more on that. Some ISPs let their customers use these communities to tell the receiving AS not to export the path to some selected neighboring ASes. Combine communities and the prefix can be advertised only to a given peer of the AS that provides this feature. A network operator can use remote filtering to, for instance, limit the scope of prefixes and get more granular inbound traffic engineering. Lowkey genius, honestly ✨.
Figure 3 shows a scenario where an AS uses BGP communities to command its provider to selectively propagate a more-specific prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501 originates 2001:DB8::/32 and advertises it to AS64502 and AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501 do selective advertisement and only propagate 2001:DB8::/34 over AS64503. Normally, AS64503 would propagate this prefix to its customers, providers, and peers, including AS64502.
Now let's say AS64501 decides to limit the scope of the more-specific prefix. AS64501 can make that call based on its traffic engineering strategy 🧚. To pull it off, AS64501 can tag the more-specific prefix with a set of communities that leads AS64503 to only propagate the path to AS64502.
^ \ / ^ ^ \ / ^
| /32 \ / /32 | | /32 \ / /32 |
,-----. ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' -> /34 `. ,'
'-----; <- / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +-- / AS64501 \ --+
( )
\ /
`. ,'
'-----'
Figure 3: Remote-Triggered Filtering2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered Filtering of More-Specific Prefixes 🙈
Figure 4 expands the Figure 3 scenario and adds other ASes peering with AS64502 and AS64503. Because the scope of the more-specific prefix is limited, ASes that are not customers of AS64502 won't receive a path for 2001:DB8::/34. These ASes will forward packets destined to 2001:DB8::/34 according to their routing state for 2001:DB8::/32. Let's assume AS64505 is one of those ASes and that its best path towards 2001:DB8::/32 goes through AS64502.
Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502. However, in the data plane of AS64502's nodes, the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached through AS64503, a settlement-free peer of AS64502. Since AS64505 is not in AS64502's customer branch, traffic flows between two noncustomer ASes inside AS64502 💅💀.
,-----.
,' `.
/ AS64505 \
( )
\ /
,`. ,' \
/ '-----' \
/ ^ ^ \
/32 | | /32 '
,-----.' + + ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' +-> /34 `. ,'
'-----; <-+ / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +--+ / AS64501 \ +--+
( )
\ /
`. ,'
'-----'
Figure 4: Unexpected Traffic Flows Due to Remote-Triggered Filtering3. Techniques to Detect Unexpected Traffic Flows Caused by Filtering of More-Specific Prefixes 🔥
3.1. Existence of Unexpected Traffic Flows within an AS 🌈
To check whether unexpected traffic flows are happening in its network, an ISP can monitor its traffic data and look for cases where it's providing transit between two of its peers, even though its policy is configured not to provide that transit. IPFIX [RFC7011] is an example of a technology that can export information about traffic flows across the network. Traffic information needs to be analyzed from the perspective of the business relationships with neighboring ASes so the flows that don't fit the policy show up. Operators can use collection systems that combine traffic statistics with policy information for this. See the pmacct project [PMACCT] for an open-source application that meets these requirements 🍓.
Note that the AS detecting the unexpected traffic flow may simply realize its policy configuration is broken. The first recommended action after detecting an unexpected traffic flow is to verify that the BGP configuration is correct 🫶.
Once the local configuration is confirmed correct, the operator should check whether the unexpected flow arose from filtering of BGP paths for more-specific prefixes by neighboring ASes. This can be done in two steps. First, the operator should check whether the neighboring AS that originates the unexpected flow is forwarding traffic using a less-specific prefix that is announced to it by the affected network. The second step is to try to work out why the neighboring AS isn't using the more-specific path for forwarding, which means finding out why the more-specific prefix was filtered. Because BGP policy steering is distributed and visibility into it is restricted, this second step can't identify the origin of the problem with guaranteed accuracy 😭.
For the first step, the operator should check whether the destination address of the unexpected traffic flow is locally routed by a more-specific prefix that was only received from noncustomer peers. The operator should also check whether there are paths to a less-specific prefix received from a customer and therefore propagated to peers. If both of these situations happen at the same time, the neighboring AS at the entry point of the unexpected flow is routing the traffic based on the less-specific prefix, even though the ISP is actually forwarding it over noncustomer links 👑.
For the second step, one can rely on human interaction or looking glasses to find out whether local filtering, remote filtering, or selective propagation was performed on the more-specific prefix. No openly available tools that can automatically perform this operation have been identified 🥺.
3.2. Contribution to the Existence of Unexpected Traffic Flows in Another AS 💅
Okay bestie, this one's a little spicy 🌶️ Triggering unexpected traffic flows in another AS is considered problematic, so it's advisable for an AS to assess the risks before filtering more-specific prefixes. The move is to gather as much info as possible about its surrounding routing environment first 🔍
Now, there can be totally valid reasons for one ISP to filter. It might be enforcing established policies, or offering prefix-advertisement scoping features to its customers 🎀 These can range from troubleshooting to business-relationship stuff. Restricting these features just to avoid creating unexpected traffic flows is not a practical option, sadly 😭
To assess the risk of filtering more-specific prefixes, the AS would need info on the routing policies and the relationships among external ASes, so it can detect whether its actions could trigger unexpected traffic flows 🧐 With that info, the operator could spot other ASes that receive the more-specific prefix from noncustomer ASes while announcing the less-specific prefix to other noncustomer ASes. If filtering the more-specific prefix makes those other ASes send traffic for the more-specific prefix to these ASes, an unexpected traffic flow can arise 🌊 The catch? That info is hard to get, because it's frequently considered confidential 🙈
4. Techniques to Traffic Engineer Unexpected Flows ✨
Network operators have different approaches when it comes to unexpected traffic flows 🦋 Note that inter-domain routing policies are complicated, so there is not a single solution that works in every situation. This section gives potential solutions that ISPs must evaluate against each particular case 💜 We sort these actions into proactive or reactive buckets.
Reactive approaches are the ones where the operator tries to detect the situations through monitoring and solves unexpected traffic flows manually, case by case 🕵️♀️
Anticipant or preventive approaches are the ones where the routing system won't let the unexpected traffic flows actually happen when the scenario shows up 🛑
We'll use the scenario in Figure 5 to walk through these two kinds of approaches 🗺️ Since proactive approaches can be complex to implement and can lead to undesired effects, the reactive approach is the more reasonable recommendation for dealing with unexpected flows 💖
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| | | |
| | /32 | | | |
'. ,' . ,' . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
Figure 5: Traffic Engineering of Unexpected Traffic Flows -
Base Example4.1. Reactive Traffic Engineering 🔥
An operator who detects unexpected traffic flows caused by any of the cases from Section 2 can contact the ASes that are likely to have done the propagation tweaks, tell them what's going on, and persuade them to change their behavior 🥰
If the situation sticks around, the operator can implement prefix filtering to stop the unexpected flows 🚫 The operator can do this over the session with the operator announcing the more-specific prefix, or over the session with the neighboring AS it's receiving the traffic from. Each option has a different repercussion for the affected AS, so let's break down both 👀
- An operator can stop announcing the less-specific prefix at the peering session with the neighboring AS it's receiving traffic to the more-specific prefix from. In the Figure 5 example, AS64502 would filter out the prefix 2001:DB8::/32 from the eBGP session with AS64504. In this case, traffic heading to the prefix 2001:DB8::/32 from AS64501 would no longer traverse AS64502. AS64502 should evaluate whether solving the issues caused by the unexpected traffic flows is worth losing that traffic share 🤔
- An operator can filter out the more-specific prefix at the peering session where it was received. In the Figure 5 example, AS64502 would filter out the incoming prefix 2001:DB8::/34 from the eBGP session with AS64505. As a result, the traffic destined to that /32 would be forwarded by AS64502 along its link with AS64501, even though AS64501 did stuff to have this traffic come in through its link with AS64503. However, since AS64502 will no longer know a route to the more-specific prefix, it risks losing the traffic share from customers other than AS64501 going to that prefix 😬 Also, this action can create conflicts between AS64502 and AS64501, since AS64502 doesn't follow the routing info AS64501 expressed in its BGP announcements 💢
Note that the behavior of the neighboring AS causing the unexpected traffic flows might violate a contractual agreement between the two networks 📜
4.2. Proactive Measures 🛡️
4.2.1. Access Lists 📋
An operator could install access lists to stop unexpected traffic flows from happening in the first place 🙅♀️ In the Figure 5 example, AS64502 would install an access list denying packets matching 2001:DB8::/34 on the interface connecting to AS64504. As a result, traffic destined to that prefix would be dropped, even though a valid route toward 2001:DB8::/32 exists 😭
The operational overhead of this solution is considered high, since the operator would have to constantly adapt these access lists to keep up with inter-domain routing changes 🥱 Even worse, this technique lets packets destined to a valid prefix get dropped while they're sent from a neighboring AS that may not know about the policy conflict, so it had no way to avoid creating the unexpected traffic flows. For this reason, this technique can be considered harmful ☠️
4.2.2. Neighbor-Specific Forwarding 🧚
An operator can technically make sure traffic destined to a given prefix is forwarded from an entry point of the network based only on the set of paths that were advertised over that entry point ✨
Let's look at the Figure 5 scenario from AS64502's point of view 👑 The edge router connecting to AS64504 forwards packets destined to prefix 2001:DB8::/34 towards AS64505. Likewise, it forwards packets destined to prefix 2001:DB8::/32 towards AS64501. The router, however, only propagates the path of the less-specific prefix (2001:DB8::/32) to AS64504. An operator could implement the techniques needed to force the edge router to forward packets coming from AS64504 based only on the paths propagated to AS64504. Then the edge router would forward packets destined to 2001:DB8::/34 towards AS64501, and no unexpected traffic flow would occur 🎉
Different techniques could provide this functionality, but their technical implementation can be complex to design and operate 🫠 An operator could, for instance, use VPN Routing and Forwarding (VRF) tables [RFC4364] to store the routes announced to a neighbor and forward traffic exclusively based on those routes. A presentation from 2009 [on_BGP_RS_VPNs] describes the use of such an architecture for Internet routing and provides a description of its limitations 📽️
In such an architecture, packets received from a peer would be forwarded solely based on the paths that fit the path propagation policy for that peer, not on the router's global routing table. As a result, a more-specific path that wouldn't be propagated to a peer won't be used to forward a packet from that peer, and the unexpected flow won't happen. Packets get forwarded based on the policy-compliant, less-specific prefix. However, note that an operator must make sure all their routers could support the potential performance impact of this approach 💻
Similar to the solution in Section 4.1, this approach could create conflicts between AS64502 and AS64501, since the traffic forwarding AS64502 performs goes against the policy of AS64501 💅
5. Conclusions 🌸
This document describes how filtering and selective propagation of more-specific prefixes can potentially create unexpected traffic flows across some ASes 🌊 We gave examples of scenarios where these practices lead to unexpected traffic flows, and we introduced some techniques for detecting and preventing them 🔍 Although there are reasonable situations where ASes could filter more-specific prefixes, network operators are encouraged to implement this type of filter after considering the cases described in this document 💜 Operators can implement monitoring systems to detect unexpected traffic flows and react to them according to their own policy 🫶
6. Security Considerations 🚨
It is possible for an AS to use any of the methods described in this document to deliberately reroute traffic flowing through another AS. This document described the potential routing security issue and analyzed ways for operators to defend against it. 💀
It must be noted that, at the time of this document, there are no existing or proposed tools to automatically protect against such behavior. Operators can use network monitoring and collection tools to detect unexpected flows and deal with them on a case-by-case basis 🔐
7. References 📚
7.1. Normative References
- [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995,
<http://www.rfc-editor.org/info/rfc1812>. 📚 - [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
<http://www.rfc-editor.org/info/rfc4364>. 🌸 - [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, DOI 10.17487/RFC4384, February 2006,
<http://www.rfc-editor.org/info/rfc4384>. 🦋 - [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>. ✨
7.2. Informative References
- [INIT7-RIPE63] Kunzler, F., "How More Specifics increase your transit bill (and ways to avoid it)", Reseaux IP Europeens (RIPE) 63rd Meeting, October 2011,
<http://ripe63.ripe.net/presentations/48-How-more-specifics-increase-your-transit-bill-v0.2.pdf>. 🧚 - [on_BGP_communities] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM Computer Communication Review, Volume 38, Number 2, pp. 55-59, DOI 10.1145/1355734.1355743, April 2008,
<http://www.sigcomm.org/sites/default/files/ccr/papers/2008/April/1355734-1355743.pdf>. 💜 - [on_BGP_RS_VPNs] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford, "Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco Systems, Routing Symposium, October 2009,
<http://inl.info.ucl.ac.be/system/files/Cisco_NAG_2009_ns_bgp.pdf>. 🔥 - [PMACCT] "pmacct project: IP accounting iconoclasm",
<http://www.pmacct.net>. 🎀
Acknowledgements 🫶
The authors would like to thank Wes George, Jon Mitchell, Bruno Decraene, and Job Snijders for their useful suggestions and comments. Honestly, the whole squad deserves a group hug for this one. 💖
Authors' Addresses 💅
Camilo Cardona
IMDEA Networks/UC3M
Avenida del Mar Mediterraneo, 22
Leganes 28919
Spain
Email: juancamilo.cardona@imdea.org
Pierre Francois
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States
Email: pifranco@cisco.com
Paolo Lucente
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States
Email: plucente@cisco.com📦 where this page comes from
- ietf: rfc7789 2016-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms