RFC 3345
Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
Border Gateway Protocol (BGP) Persistent Route Oscillation Condition 🦋
okay bestie, this one is RFC 3345 💖 It's titled "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition," and it's from the Network Working Group. The authors are D. McPherson (TCB), V. Gill (AOL Time Warner, Inc.), D. Walton, and A. Retana (Cisco Systems, Inc.). It came out in August 2002 and it's Informational 🎀, so it's sharing info, not setting a standard. The title block doesn't list anything it obsoletes or updates ✨
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. 🫶
Abstract
okay so in certain configurations, the BGP scaling mechanisms defined in "BGP Route Reflection - An Alternative to Full Mesh IBGP" and "Autonomous System Confederations for BGP" will introduce persistent BGP route oscillation 🌀 This doc talks about the two types of persistent route oscillation that have been identified, explains when these conditions happen, and gives some network design guidelines to avoid causing them 💅
1. Introduction ✨
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol 🌍 The main job of a BGP speaking system is to exchange network reachability information with other BGP systems 💜
In certain configurations, the BGP [1] scaling mechanisms defined in "BGP Route Reflection - An Alternative to Full Mesh IBGP" [2] and "Autonomous System Confederations for BGP" [3] will introduce persistent BGP route oscillation 😭
The problem is baked into how BGP works: locally defined routing policies may conflict globally, and certain types of conflicts can cause persistent oscillation of the protocol 🔥 Given current practices, we happen to see the problem show up in the context of MED + route reflectors or confederations 🙈
The current specification of BGP-4 [4] says the MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS. This limitation matches the description of the attribute:
"The MULTI_EXIT_DISC attribute may be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS." [1,4]
In a full mesh iBGP network, all the internal routers have complete visibility of the available exit points into a neighboring AS 👑 So comparing the MULTI_EXIT_DISC for only some paths isn't a problem there 🍓
Full mesh iBGP can get really hard to scale, so two alternatives have been standardized: route reflectors [2] and AS confederations [3] 🧚 Both describe ways to get route distribution done without a full iBGP mesh in an AS.
The route reflector option lets iBGP-learned routes get re-advertised (reflected) to other iBGP peers once the best path is selected [2] 🦋 AS confederations let a collection of autonomous systems under a common administration operate as a single entity. From the outside, the internal topology and the existence of separate autonomous systems aren't visible 🫣 In both cases, shrinking the iBGP full mesh means not all the BGP speakers in the AS have complete visibility of the available exit points into a neighboring AS. Honestly the visibility can be partial and inconsistent, depending on where the router sits in the AS and what it does 👀
In certain topologies with either route reflectors or confederations (we'll get the detailed description later in this doc), that partial visibility into exit points can lead to an inconsistent best path selection decision, because the routers don't have all the relevant info 💀 If the inconsistencies span more than one peering router, they may cause a persistent route oscillation 🌈 The best path selection rules used in this document are consistent with the current specification [4] ✨
The persistent route oscillation behavior is deterministic, and it can be avoided by using some rudimentary BGP network design principles until protocol enhancements fix the problem 🎀
Coming up next, the doc lays out a taxonomy of the oscillation types and describes the set of conditions that trigger route oscillations. Then it gives several network design alternatives that remove the potential for this to happen 💅
The authors want this document to increase operator awareness of the problem, and also to kick off discussion and proposals for protocol enhancements that make it impossible for this to occur 🫶
The oscillations are classified into Type I and Type II depending on the criteria documented below 🦋
2. Discussion of Type I Churn 💜
In the following two subsections we give configurations where Type I Churn will occur. We start with the problem when using Route Reflection, then move on to how it relates to AS Confederations 🌸
In general, Type I Churn occurs only when BOTH of the following conditions are met:
1) a single-level Route Reflection or AS Confederations design is
used in the network AND
2) the network accepts the BGP MULTI_EXIT_DISC (MED) attribute
from two or more ASs for a single prefix and the MED values are
unique.It's also possible for the non-deterministic ordering of paths to cause the route oscillation problem 🌀 [1] doesn't specify that paths should be ordered based on MEDs, but it has been proven that non-deterministic ordering can lead to loops and inconsistent routing decisions 😭 Most vendors have either implemented deterministic ordering as default behavior, or they provide a knob that lets the operator configure the router to order paths deterministically based on MEDs 🍓
2.1. Route Reflection and Type I Churn
okay bestie, let's talk about Type I oscillation and how it shows up with Route Reflection 🦋 this part is giving main character energy, so buckle up 💅
Here's the setup. We're looking at the topology in Figure 1, and it's a whole vibe ✨
---------------------------------------------------------------
/ -------------------- -------------------- \
| / \ / \ |
| | Cluster 1 | | Cluster 2 | |
| | | | | |
| | | *1 | | |
| | Ra(RR) . . . . . . . . . . . . . . Rd(RR) | |
| | . . | | . | |
| | .*5 .*4 | | .*12 | |
| | . . | | . | |
| | Rb(C) Rc(C) | | Re(C) | |
| | . . | | . | |
| \ . . / \ . / |
| ---.------------.--- ---------.---------- |
\ .(10) .(1) AS1 .(0) /
-------.------------.---------------------------.--------------
. . .
------ . ------------ .
/ \ . / \ .
| AS10 | | AS6 |
\ / \ /
------ ------------
. .
. .
. --------------
. / \
| AS100 |- 10.0.0.0/8
\ /
--------------
Figure 1: Example Route Reflection TopologySo AS1 has two Route Reflector Clusters, Cluster 1 and Cluster 2 🎀 Each cluster gets one Route Reflector (RR), which is Ra in Cluster 1 and Rd in Cluster 2. Cluster 1 has two RR Clients (Rb and Rc), and Cluster 2 has one (Re). Those little (RR) and (C) tags are just how we label who's who 🌸 The dotted lines are BGP peering sessions.
The number in parentheses on the AS1 EBGP sessions is the MED that the peer advertises for the 10.0.0.0/8 reachability advertisement. And the number after each * on the IBGP sessions is the additive IGP metric that gets attached to the BGP NEXT_HOP attribute for that route. For example, Ra's IGP metric for a NEXT_HOP learned via Rb is 5, and for one learned via Re it's 13 🧚
Now here's Table 1, which shows the 10.0.0.0/8 route attributes as seen by Rb, Rc and Re, in that order 📋 Quick note: the IGP metrics in Figure 1 only matter when you're advertising the route to an IBGP peer, so don't stress about them otherwise 💖
Router MED AS_PATH
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 1: Route Attribute TableOkay, the main event 😭 We're going through steps 1 through 5, and the best path gets marked with a *.
- Ra has these installed in its BGP table, with the path learned via AS2 marked as best:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 1 4
* 10 100 10 5The 10 100 route should NOT be marked as best 🙈 (Not the cause of the persistent oscillation though, we'll get there.) Ra realizes it has the wrong one marked since the 6 100 path has a lower IGP metric. So Ra fixes it and sends an UPDATE message to its neighbors to say it now considers the 6 100, 1, 4 route as best 💅
- Rd gets that UPDATE from Ra, so Rd now has this in its BGP table:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
* 6 100 0 12
6 100 1 5Rd marks the 6 100, 0, 12 route as best because it has a lower MED 🍓 Then Rd sends an UPDATE message to its neighbors to tell them that's the best route.
- Ra gets the UPDATE from Rd and now has this:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 0 13
6 100 1 4
* 10 100 10 5So the first route (6 100, 0, 13) beats the second route (6 100, 1, 4) because of the lower MED. Then the third route (10 100, 10, 5) beats the first one because of its lower IGP metric to NEXT_HOP 👀 Ra sends an UPDATE message to its peers to inform them of the new best route.
- Rd gets the UPDATE from Ra, which leaves Rd with this BGP table:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 0 12
* 10 100 10 6Rd picks the 10 100, 10, 6 path as best because of the IGP metric 🦋 Rd sends an UPDATE/withdraw to its peers to let them know this is the best route.
- Ra gets the UPDATE message from Rd, which leaves Ra with this BGP table:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 1 4
* 10 100 10 5Ra got an UPDATE/withdraw for 6 100, 0, 13, and that changes what Ra considers the best route. This is exactly why Ra has the 10 100, 10, 5 route selected as best in Step 1, even though 6 100, 1, 4 is actually better 😭
And that's the loop, babe. We've made a full circle and we're right back at Step 1. The router realizes it's using the incorrect best path and the whole cycle starts over again 🌀 This is an example of Type I Churn when using Route Reflection, and honestly it's giving chaos 💀
2.2. AS Confederations and Type I Churn ✨
okay so now we get a Type I Churn example with AS Confederations 🎀 bestie this one is giving main character energy. Start with the topology in Figure 2 👀
---------------------------------------------------------------
/ -------------------- -------------------- \
| / \ / \ |
| | Sub-AS 65000 | | Sub-AS 65001 | |
| | | | | |
| | | *1 | | |
| | Ra . . . . . . . . . . . . . . . . . Rd | |
| | . . | | . | |
| | .*3 .*2 | | .*6 | |
| | . . | | . | |
| | Rb . . . . . Rc | | Re | |
| | . *5 . | | . | |
| \ . . / \ . / |
| ---.------------.--- ---------.---------- |
\ .(10) .(1) AS1 .(0) /
-------.------------.---------------------------.--------------
. . .
------ . ------------ .
/ \ . / \ .
| AS10 | | AS6 |
\ / \ /
------ ------------
. .
. .
. --------------
. / \
| AS100 |- 10.0.0.0/8
\ /
--------------
Figure 2: Example AS Confederations TopologyThe number in parentheses on each AS1 EBGP peering session is the MED value that the peer advertises for the 10.0.0.0/8 network reachability advertisement 🍓
The number after each * on the IBGP peering sessions is the additive IGP metric that goes with the BGP NEXT_HOP attribute for that route 🧚
So for example, Ra's IGP metric for a NEXT_HOP learned via Rb is 3, and the one for a NEXT_HOP learned via Re is 6 💅
Table 2 shows the 10.0.0.0/8 route attributes as Rb, Rc and Re each see them. Also, the IGP metrics in Figure 2 only matter when you're advertising the route to an IBGP peer, so keep that in mind 🫶
Router MED AS_PATH
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 2: Route Attribute TableFor the next steps 1 through 6, the best route gets marked with a * ⭐
Step 1) Ra has this BGP table 👑
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
* 10 100 10 3
(65001) 6 100 0 7
6 100 1 2The 10 100 route gets picked as best and is advertised to Rd. Real talk though, that isn't what's causing the persistent route oscillation 🙈
Step 2) Rd has this in its BGP table 🦋
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
6 100 0 6
* (65000) 10 100 10 4The (65000) 10 100 route wins as best because it has the lowest IGP metric. So Rd sends an UPDATE/withdraw to Ra for the 6 100 route it had previously advertised 💌
Step 3) Ra gets the withdraw from Rd. Ra now has this in its BGP table 🌸
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
* 10 100 10 3
6 100 1 2Ra got a withdraw for (65001) 6 100, and that changes what Ra considers the best route. Ra doesn't recompute the best path for a prefix unless its best route was withdrawn. That's why Ra is stuck with the 10 100, 10, 3 route as best, even though the 6 100, 1, 2 route is better 😭
Step 4) Ra's periodic BGP scanner runs and notices that the 6 100 route is better because of its lower IGP metric. So Ra sends an UPDATE/withdraw to Rd for the 10 100 route, since Ra is now using the 6 100 path as its best route 💜
Ra's BGP table now looks like this:
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
10 100 10 3
* 6 100 1 2Step 5) Rd gets the UPDATE from Ra and now has this in its BGP table 🌈
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
(65000) 6 100 1 3
* 6 100 0 6Rd picks the 6 100, 0, 6 route as best because of its lower MED value. Rd then sends an UPDATE message to Ra, saying that 6 100, 0, 6 is now the best route 🔥
Step 6) Ra gets the UPDATE from Rd. Ra now has this in its BGP table 🎀
NEXT_HOP
AS_PATH MED IGP Cost
-------------------------------
* 10 100 10 3
(65001) 6 100 0 7
6 100 1 2At this point we've gone all the way around and we're back at step 1. That's an example of Type I Churn with AS Confederations 😭💀
2.3. Potential Workarounds for Type I Churn 🧚
There are a bunch of options you can use to dodge this problem ✨
- When you're using Route Reflection, make sure the inter-Cluster links have a higher IGP metric than the intra-Cluster links. This is the preferred choice when using Route Reflection 👑 If the inter-Cluster IGP metrics were much larger than the intra-Cluster IGP metrics, the above wouldn't have happened.
- When you're using AS Confederations, make sure the inter-Sub-AS links have a higher IGP metric than the intra-Sub-AS links. This is the preferred option when using AS Confederations 💅 If the inter-Sub-AS IGP metrics were much larger than the intra-Sub-AS IGP metrics, the above wouldn't have happened.
- Don't accept MEDs from peers. (Heads up, this might not be a feasible option 🙈)
- Use other BGP attributes higher up in the decision process, so the BGP decision algorithm never gets as far as the MED step. Since this completely overrides MEDs, option 3 might make more sense 🦋
- Always compare BGP MEDs, even if they came from different ASs. This is probably a bad idea 🫠 MEDs can be derived in a number of ways, and they're usually set as a matter of operator-specific policy. So comparing MED values for a single prefix learned from multiple ASs is ill-advised. Also, this mostly defeats the purpose of MEDs, so option 3 may be the more viable alternative 💜
- Use a full IBGP mesh. This isn't a feasible solution for ASs with a large number of BGP speakers 🍓
3. Discussion of Type II Churn 🌸
Okay, next up is the configurations where Type II Churn happens when you're using AS Confederations 🎀 We're skipping the Route Reflection version of this just to keep things brief 💖
In general, Type II churn only happens when BOTH of these conditions are met 👀
- More than one tier of Route Reflection or Sub-ASs is used in the network AND
- the network accepts the BGP MULTI_EXIT_DISC (MED) attribute from two or more ASs for a single prefix and the MED values are unique ✨
3.1. AS Confederations and Type II Churn ✨
okay bestie, now we get to see Type II churn with AS Confederations 🦋 and honestly this is where it gets dramatic. Here's our sample topology:
---------------------------------------------------------------
/ ------------------- \
| AS 1 / Sub-AS 65500 \ |
| | | |
| | Rc . . . . Rd | |
| | . *2 . | |
| \ . . / |
| .-----------------. |
| .*40 .*40 |
| --------------.----- --.----------------- |
| / . \ / . \ |
| | Sub-AS . | | . Sub-AS | |
| | 65501 . | | . 65502 | |
| | Rb | | Re | |
| | . | | . . | |
| | .*10 | | *2. .*3 | |
| | . | | . . | |
| | Ra | | . Rg . . . Rf | |
| \ . / . . / |
| ----------.---------- . -------------.------- |
\ .(0) .(1) .() /
----------------.---------------.-------------------.----------
. . .
--------- . ---------
|AS 200 | |AS 300 |
--------- ---------
. .
. .
-------------------
| AS 400 | - 10.0.0.0/8
-------------------
Figure 3: Example AS Confederations TopologyIn Figure 3, AS 1 has three Sub-ASs: 65500, 65501 and 65502. No RR is used inside the Sub-AS, so all routers within each Sub-AS are fully meshed 🫶. Ra and Rb live in Sub-AS 65501, and Rc and Rd live in Sub-AS 65500. Ra and Rg are EBGP peering with AS 200, and router Rf has an EBGP peering with AS 300. AS 200 and AS 300 both provide transit for AS 400, specifically the 10/8 network. The dotted lines are the BGP peering sessions.
The number after each '*' on a BGP peering session is the additive IGP metric that gets associated with the BGP NEXT_HOP. The number in parentheses on each AS 1 EBGP peering session is the MED value that the peer advertises for the network reachability advertisement (10.0.0.0/8). 💅
Rc, Rd and Re are the main routers involved in the churn, so they're the only BGP tables we'll watch step by step 👀. For steps 1 through 8, each router's best route is marked with a '*'.
Step 1. Re gets the AS 400 10.0.0.0/8 route advertisement from Rg through AS 200, and from Rf through AS 300. Re picks the path through Rg and AS 200 because of the IGP metric. (Re didn't look at MED here since the advertisements came from different ASs.)
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Re * 200 400 1 2
300 400 3Re sends an UPDATE to Rd advertising its new best path, '200 400, 1'.
Step 2. The '200 400, 0' path was advertised from Ra to Rb, and then from Rb to Rc. Rd learns the '200 400, 1' path from Re.
NEXT_HOP
Router AS_PATH MED IGP Cost
-------------------------------
Rc * 200 400 0 50
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2Step 3. Rc and Rd advertise their best paths to each other, and Rd picks '200 400, 0' because of the MED.
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
200 400 1 44
Rd * 200 400 0 52
200 400 1 42
Re 300 400 3
* 200 400 1 2Rd has a new best path, so it sends an UPDATE to Re announcing the new path, and an UPDATE/withdraw for '200 400, 1' to Rc.
Step 4. Re now selects '300 400' (with no MED). '200 400, 0' beats '200 400, 1' based on MED, and then '300 400' beats '200 400, 0' because of the IGP metric. 😭
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
Rd * 200 400 0 52
200 400 1 42
Re * 300 400 3
200 400 0 92Re has a new best path and sends an UPDATE to Rd for '300 400'.
Step 5. Rd selects the '300 400' path because of the IGP metric.
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
Rd 200 400 0 52
* 300 400 43
Re * 300 400 3
200 400 0 92
200 400 1 2Rd has a new best path, so it sends an UPDATE to Rc and an UPDATE/withdraw to Re for '200 400, 0'.
Step 6. Rc selects '300 400' because of the IGP metric. Re selects '200 400, 1' because of the IGP metric.
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc 200 400 0 50
* 300 400 45
Rd 200 400 0 52
* 300 400 43
Re 300 400 3
* 200 400 1 2Rc sends an UPDATE/withdraw for '200 400, 0' to Rd. Re sends an UPDATE for '200 400, 1' to Rd.
Step 7. Rd selects '200 400, 1' as its new best path based on the IGP metric.
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc 200 400 0 50
* 300 400 45
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2Rd sends an UPDATE to Rc announcing '200 400, 1', which implicitly withdraws '300 400'.
Step 8. Rc selects '200 400, 0'.
NEXT_HOP
Router AS_PATH MED IGP Cost
------------------------------
Rc * 200 400 0 50
200 400 1 44
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2At this point we are back to Step 2, and we are stuck in a loop 🌀 (this is the scary part, bestie).
3.2. Potential Workarounds for Type II Churn
okay so here are the ways people try to dodge Type II churn 🎀
- Do not accept MEDs from peers. (This may not be a feasible alternative.)
- Use other BGP attributes higher up in the decision process so that the BGP decision algorithm picks a single AS before it reaches the MED step. For example, if local-pref were set based on the advertising AS, then you'd first eliminate all routes except the ones from a single AS. In the example, router Re would pick either X or Y based on your local-pref and never change selections.
This leaves two simple workarounds for the two types of problems.
Type I: Make inter-cluster or inter-sub-AS link metrics higher than intra-cluster or intra-sub-AS metrics.
Type II: Make route selections based on local-pref assigned to the advertising AS first, and then use IGP cost and MED to choose among routes from the same AS.
Note that this requires per-prefix policies, plus near intimate knowledge of other networks by the network operator. The authors are not aware of ANY [large] provider today that performs per-prefix policies on routes learned from peers. Implicitly removing this dynamic portion of route selection does not appear to be a viable option in today's networks. The main point is that an available workaround using local-pref, so that no two AS's advertise a given prefix at the same local-pref, solves Type II churn. 🫠
- Always compare BGP MEDs, regardless of whether or not they came from a single AS. This is probably a bad idea, since MEDs may be derived in a number of ways, and are typically set as a matter of operator-specific policy and largely depend on the metric space the employed IGP provides. So comparing MED values for a single prefix learned from multiple ASs is ill-advised. This mostly defeats the purpose of MEDs, and Option 1 may be a more viable alternative.
- Do not use more than one tier of Route Reflection or Sub-ASs in the network. The risk of route oscillation should be considered when designing networks that might use a multi-tiered routing isolation architecture.
- In an RR topology, mesh the clients. For confederations, mesh the border routers at each level in the hierarchy. In Figure 3, for example, if Rb and Re are peers, then there's no churn. 🧚
4. Future Work ✨
okay so here's the plan: protocol enhancements for this problem must be pursued 🔥. Imposing network design requirements, like the ones outlined above, is clearly an unreasonable long-term solution. Problems like this should not occur under 'default' protocol configurations.
5. Security Considerations 🔐
This discussion introduces no new security concerns to BGP or other specifications referenced in this document. (Phew, no new drama on the security front 💜)
6. Acknowledgments 🫶
The authors would like to thank Curtis Villamizar, Tim Griffin, John Scudder, Ron Da Silva, Jeffrey Haas and Bill Fenner.
7. References 📚
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[2] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] Traina, P., McPherson, D. and J. Scudder, J., "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress.
8. Authors' Addresses 💌
Danny McPherson TCB EMail: danny@tcb.net
Vijay Gill AOL Time Warner, Inc. 12100 Sunrise Valley Drive Reston, VA 20191 EMail: vijay@umbc.edu
Daniel Walton Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: dwalton@cisco.com
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 EMail: aretana@cisco.com
9. Full Copyright Statement ✨
Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀
okay so the gist is you can copy and share this doc, and translations of it too 🦋. You can also write derivative works that comment on it, explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 💅.
BUT the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can change it as needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed, or you can change it to translate it into languages other than English 🌈.
The permissions above are perpetual, meaning they will never be revoked by the Internet Society or its successors or assigns 💜.
The document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🌸
📦 where this page comes from
- ietf: rfc3345 2002-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms