As per Relevance of the word following, we have this rfc below:
Network Working Group D.
Request for Comments: 3345
Category: Informational V.
AOL Time Warner, Inc
D.
A.
Cisco Systems, Inc
August 2002
Border Gateway Protocol (BGP) Persistent Route Oscillation
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
In particular configurations, the BGP scaling mechanisms defined
"BGP Route Reflection - An Alternative to Full Mesh IBGP"
"Autonomous System Confederations for BGP" will introduce
BGP route oscillation. This document discusses the two types
persistent route oscillation that have been identified,
when these conditions will occur, and provides some network
guidelines to avoid introducing such occurrences
1.
The Border Gateway Protocol (BGP) is an inter-Autonomous
routing protocol. The primary function of a BGP speaking system
to exchange network reachability information with other BGP systems
In particular configurations, the BGP [1] scaling mechanisms
in "BGP Route Reflection - An Alternative to Full Mesh IBGP" [2]
"Autonomous System Confederations for BGP" [3] will
persistent BGP route oscillation
The problem is inherent in the way BGP works: locally defined
policies may conflict globally, and certain types of conflicts
cause persistent oscillation of the protocol. Given
practices, we happen to see the problem manifest itself in
context of MED + route reflectors or confederations
McPherson, et al. Informational [Page 1]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
The current specification of BGP-4 [4] states that
MULTI_EXIT_DISC is only comparable between routes learned from
same neighboring AS. This limitation is consistent with
description of the attribute: "The MULTI_EXIT_DISC attribute may
used on external (inter-AS) links to discriminate among multiple
or entry points to the same neighboring AS." [1,4]
In a full mesh iBGP network, all the internal routers have
visibility of the available exit points into a neighboring AS.
comparison of the MULTI_EXIT_DISC for only some paths is not
problem
Because of the scalability implications of a full mesh iBGP network
two alternatives have been standardized: route reflectors [2] and
confederations [3]. Both alternatives describe methods by
route distribution may be achieved without a full iBGP mesh in an AS
The route reflector alternative defines the ability to re-
(reflect) iBGP-learned routes to other iBGP peers once the best
is selected [2]. AS Confederations specify the operation of
collection of autonomous systems under a common administration as
single entity (i.e. from the outside, the internal topology and
existence of separate autonomous systems are not visible). In
cases, the reduction of the iBGP full mesh results in the fact
not all the BGP speakers in the AS have complete visibility of
available exit points into a neighboring AS. In fact, the
may be partial and inconsistent depending on the location (
function) of the router in the AS
In certain topologies involving either route reflectors
confederations (detailed description later in this document),
partial visibility of the available exit points into a neighboring
may result in an inconsistent best path selection decision as
routers don't have all the relevant information. If
inconsistencies span more than one peering router, they may result
a persistent route oscillation. The best path selection
applied in this document are consistent with the
specification [4].
The persistent route oscillation behavior is deterministic and can
avoided by employing some rudimentary BGP network design
until protocol enhancements resolve the problem
In the following sections a taxonomy of the types of oscillations
presented and a description of the set of conditions that
trigger route oscillations is given. We continue by
several network design alternatives that remove the potential of
occurrence
McPherson, et al. Informational [Page 2]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
It is the intent of the authors that this document serve to
operator awareness of the problem, as well as to trigger
and subsequent proposals for potential protocol enhancements
remove the possibility of this to occur
The oscillations are classified into Type I and Type II
upon the criteria documented below
2. Discussion of Type I
In the following two subsections we provide configurations
which Type I Churn will occur. We begin with a discussion of
problem when using Route Reflection, and then discuss the problem
it relates to AS Confederations
In general, Type I Churn occurs only when BOTH of the
conditions are met
1) a single-level Route Reflection or AS Confederations design
used in the network
2) the network accepts the BGP MULTI_EXIT_DISC (MED)
from two or more ASs for a single prefix and the MED values
unique
It is also possible for the non-deterministic ordering of paths
cause the route oscillation problem. [1] does not specify that
should be ordered based on MEDs but it has been proven that non
deterministic ordering can lead to loops and inconsistent
decisions. Most vendors have either implemented
ordering as default behavior, or provide a knob that permits
operator to configure the router to order paths in a
manner based on MEDs
McPherson, et al. Informational [Page 3]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
2.1. Route Reflection and Type I
We now discuss Type I oscillation as it relates to Route Reflection
To begin, consider the topology depicted in Figure 1:
---------------------------------------------------------------
/ -------------------- -------------------- \
| / \ / \ |
| | 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
In Figure 1 AS1 contains two Route Reflector Clusters, Clusters 1
2. Each Cluster contains one Route Reflector (RR) (i.e., Ra and Rd
respectively). An associated 'RR' in parentheses represents each RR
Cluster 1 contains two RR Clients (Rb and Rc), and Cluster 2
one RR Client (Re). An associated 'C' in parentheses indicates
Client status. The dotted lines are used to represent BGP
sessions
The number contained in parentheses on the AS1 EBGP peering
represents the MED value advertised by the peer to be associated
the 10.0.0.0/8 network reachability advertisement
McPherson, et al. Informational [Page 4]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
The number following each '*' on the IBGP peering sessions
the additive IGP metrics that are to be associated with the
NEXT_HOP attribute for the concerned route. For example, the Ra
metric value associated with a NEXT_HOP learned via Rb would be 5;
while the metric value associated with the NEXT_HOP learned via
would be 13.
Table 1 depicts the 10.0.0.0/8 route attributes as seen by
Rb, Rc and Re, respectively. Note that the IGP metrics in Figure 1
are only of concern when advertising the route to an IBGP peer
Router MED AS_
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 1: Route Attribute
For the following steps 1 through 5, the best path will be
with a '*'.
1) Ra has the following installed in its BGP table, with the
learned via AS2 marked best
NEXT_
AS_PATH MED IGP
-----------------------
6 100 1 4
* 10 100 10 5
The '10 100' route should not be marked as best, though this
not the cause of the persistent route oscillation. Ra
it has the wrong route marked as best since the '6 100'
has a lower IGP metric. As such, Ra makes this change
advertises an UPDATE message to its neighbors to let them
that it now considers the '6 100, 1, 4' route as best
2) Rd receives the UPDATE from Ra, which leaves Rd with
following installed in its BGP table
NEXT_
AS_PATH MED IGP
-----------------------
* 6 100 0 12
6 100 1 5
McPherson, et al. Informational [Page 5]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
Rd then marks the '6 100, 0, 12' route as best because it has
lower MED. Rd sends an UPDATE message to its neighbors to
them know that this is the best route
3) Ra receives the UPDATE message from Rd and now has
following in its BGP table
NEXT_
AS_PATH MED IGP
-----------------------
6 100 0 13
6 100 1 4
* 10 100 10 5
The first route (6 100, 0, 13) beats the second route (6 100,
1, 4) because of a lower MED. Then the third route (10 100,
10, 5) beats the first route because of lower IGP metric
NEXT_HOP. Ra sends an UPDATE message to its peers
them of the new best route
4) Rd receives the UPDATE message from Ra, which leaves Rd
the following BGP table
NEXT_
AS_PATH MED IGP
-----------------------
6 100 0 12
* 10 100 10 6
Rd selects the '10 100, 10, 6' path as best because of the
metric. Rd sends an UPDATE/withdraw to its peers letting
know this is the best route
5) Ra receives the UPDATE message from Rd, which leaves Ra
the following BGP table
NEXT_
AS_PATH MED IGP
-----------------------
6 100 1 4
* 10 100 10 5
Ra received an UPDATE/withdraw for '6 100, 0, 13',
changes what is considered the best route for Ra. This is
Ra has the '10 100, 10, 5' route selected as best in Step 1,
even though '6 100, 1, 4' is actually better
McPherson, et al. Informational [Page 6]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
At this point, we've made a full loop and are back at Step 1.
router realizes it is using the incorrect best path, and
the cycle. This is an example of Type I Churn when using
Reflection
2.2. AS Confederations and Type I
Now we provide an example of Type I Churn occurring with
Confederations. To begin, consider the topology depicted in
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
The number contained in parentheses on each AS1 EBGP peering
represents the MED value advertised by the peer to be associated
the 10.0.0.0/8 network reachability advertisement
McPherson, et al. Informational [Page 7]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
The number following each '*' on the IBGP peering sessions
the additive IGP metrics that are to be associated with the
NEXT_HOP attribute for the concerned route
For example, the Ra IGP metric value associated with a NEXT_
learned via Rb would be 3; while the metric value associated with
NEXT_HOP learned via Re would be 6.
Table 2 depicts the 10.0.0.0/8 route attributes as seen by
Rb, Rc and Re, respectively. Note that the IGP metrics in Figure 2
are only of concern when advertising the route to an IBGP peer
Router MED AS_
--------------------
Rb 10 10 100
Rc 1 6 100
Re 0 6 100
Table 2: Route Attribute
For the following steps 1 through 6 the best route will be
with an '*'.
1) Ra has the following BGP table
NEXT_
AS_PATH MED IGP
-------------------------------
* 10 100 10 3
(65001) 6 100 0 7
6 100 1 2
The '10 100' route is selected as best and is advertised to Rd
though this is not the cause of the persistent
oscillation
2) Rd has the following in its BGP table
NEXT_
AS_PATH MED IGP
-------------------------------
6 100 0 6
* (65000) 10 100 10 4
The '(65000) 10 100' route is selected as best because it
the lowest IGP metric. As a result, Rd sends
UPDATE/withdraw to Ra for the '6 100' route that it
previously advertised
McPherson, et al. Informational [Page 8]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
3) Ra receives the withdraw from Rd. Ra now has the following
its BGP table
NEXT_
AS_PATH MED IGP
-------------------------------
* 10 100 10 3
6 100 1 2
Ra received a withdraw for '(65001) 6 100', which changes
is considered the best route for Ra. Ra does not compute
best path for a prefix unless its best route was withdrawn
This is why Ra has the '10 100, 10, 3' route selected as best
even though the '6 100, 1, 2' route is better
4) Ra's periodic BGP scanner runs and realizes that the '6 100'
route is better because of the lower IGP metric. Ra sends
UPDATE/withdraw to Rd for the '10 100' route since Ra is
using the '6 100' path as its best route
Ra's BGP table looks like this
NEXT_
AS_PATH MED IGP
-------------------------------
10 100 10 3
* 6 100 1 2
5) Rd receives the UPDATE from Ra and now has the following in
BGP table
NEXT_
AS_PATH MED IGP
-------------------------------
(65000) 6 100 1 3
* 6 100 0 6
Rd selects the '6 100, 0, 6' route as best because of the
MED value. Rd sends an UPDATE message to Ra, reporting that '6
100, 0, 6' is now the best route
McPherson, et al. Informational [Page 9]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
6) Ra receives the UPDATE from Rd. Ra now has the following
its BGP table
NEXT_
AS_PATH MED IGP
-------------------------------
* 10 100 10 3
(65001) 6 100 0 7
6 100 1 2
At this point we have made a full cycle and are back to step 1.
This is an example of Type I Churn with AS Confederations
2.3. Potential Workarounds for Type I
There are a number of alternatives that can be employed to avoid
problem
1) When using Route Reflection make sure that the inter-
links have a higher IGP metric than the intra-Cluster links
This is the preferred choice when using Route Reflection.
the inter-Cluster IGP metrics been much larger than the intra
Cluster IGP metrics, the above would not have occurred
2) When using AS Confederations ensure that the inter-Sub-AS
have a higher IGP metric than the intra-Sub-AS links. This
the preferred option when using AS Confederations. Had
inter-Sub-AS IGP metrics been much larger than the intra-Sub-
IGP metrics, the above would not have occurred
3) Do not accept MEDs from peers (this may not be a
alternative).
4) Utilize other BGP attributes higher in the decision process
that the BGP decision algorithm never reaches the MED step.
using this completely overrides MEDs, Option 3 may make
sense
5) Always compare BGP MEDs, regardless of whether or not they
obtained from a single AS. This is probably a bad idea
MEDs may be derived in a number of ways, and are typically
so as a matter of operator-specific policy. As such,
MED values for a single prefix learned from multiple ASs
ill-advised. Of course, this mostly defeats the purpose
MEDs, and as such, Option 3 may be a more viable alternative
6) Use a full IBGP mesh. This is not a feasible solution for
with a large number of BGP speakers
McPherson, et al. Informational [Page 10]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
3. Discussion of Type II
In the following subsection we provide configurations under
Type II Churn will occur when using AS Confederations. For the
of brevity, we avoid similar discussion of the occurrence when
Route Reflection
In general, Type II churn occurs only when BOTH of the
conditions are met
1) More than one tier of Route Reflection or Sub-ASs is used
the network
2) the network accepts the BGP MULTI_EXIT_DISC (MED)
from two or more ASs for a single prefix and the MED values
unique
McPherson, et al. Informational [Page 11]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
3.1. AS Confederations and Type II
Let's now examine the occurrence of Type II Churn as it relates to
Confederations. Figure 3 provides 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
In Figure 3 AS 1 contains three Sub-ASs, 65500, 65501 and 65502.
RR is used within the Sub-AS, and as such, all routers within
Sub-AS are fully meshed. Ra and Rb are members of Sub-AS 65501.
and Rd are members of Sub-AS 65500. Ra and Rg are EBGP peering
AS 200, router Rf has an EBGP peering with AS 300. AS 200 and AS 300
provide transit for AS 400, and in particular, the 10/8 network.
dotted lines are used to represent BGP peering sessions
McPherson, et al. Informational [Page 12]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
The number following each '*' on the BGP peering sessions
the additive IGP metrics that are to be associated with the
NEXT_HOP. The number contained in parentheses on each AS 1
peering session represents the MED value advertised by the peer to
associated with the network reachability advertisement (10.0.0.0/8).
Rc, Rd and Re are the primary routers involved in the churn, and
such, will be the only BGP tables that we will monitor step by step
For the following steps 1 through 8 each router's best route will
marked with a '*'.
1) Re receives the AS 400 10.0.0.0/8 route advertisement via
200 from Rg and AS 300 from Rf. Re selects the path via Rg
AS 200 because of IGP metric (Re didn't consider MED
the advertisements were received from different ASs).
NEXT_
Router AS_PATH MED IGP
------------------------------
Re * 200 400 1 2
300 400 3
Re sends an UPDATE message to Rd advertising its new best
'200 400, 1'.
2) The '200 400, 0' path was advertised from Ra to Rb, and
from Rb to Rc. Rd learns the '200 400, 1' path from Re
NEXT_
Router AS_PATH MED IGP
-------------------------------
Rc * 200 400 0 50
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2
McPherson, et al. Informational [Page 13]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
3) Rc and Rd advertise their best paths to each other; Rd
'200 400, 0' because of the MED
NEXT_
Router AS_PATH MED IGP
------------------------------
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 2
Rd has a new best path so it sends an UPDATE to to Re
announcing the new path and an UPDATE/withdraw for '200 400, 1'
to Rc
4) Re now selects '300 400' (with no MED) because '200 400, 0'
beats '200 400, 1' based on MED and '300 400' beats '200 400,
0' because of IGP metric
NEXT_
Router AS_PATH MED IGP
------------------------------
Rc * 200 400 0 50
Rd * 200 400 0 52
200 400 1 42
Re * 300 400 3
200 400 0 92
Re has a new best path and sends an UPDATE to Rd for '300 400'.
5) Rd selects the '300 400' path because of IGP metric
NEXT_
Router AS_PATH MED IGP
------------------------------
Rc * 200 400 0 50
Rd 200 400 0 52
* 300 400 43
Re * 300 400 3
200 400 0 92
200 400 1 2
Rd has a new best path so it sends an UPDATE to Rc and
UPDATE/withdraw to Re for '200 400, 0'.
McPherson, et al. Informational [Page 14]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
6) Rc selects '300 400' because of the IGP metric. Re
'200 400, 1' because of the IGP metric
NEXT_
Router AS_PATH MED IGP
------------------------------
Rc 200 400 0 50
* 300 400 45
Rd 200 400 0 52
* 300 400 43
Re 300 400 3
* 200 400 1 2
Rc sends an UPDATE/withdraw for '200 400, 0' to Rd. Re
an UPDATE for '200 400, 1' to Rd
7) Rd selects '200 400, 1' as its new best path based on the
metric
NEXT_
Router AS_PATH MED IGP
------------------------------
Rc 200 400 0 50
* 300 400 45
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2
Rd sends an UPDATE to Rc, announcing '200 400, 1'
implicitly withdraws '300 400'.
8) Rc selects '200 400, 0'.
NEXT_
Router AS_PATH MED IGP
------------------------------
Rc * 200 400 0 50
200 400 1 44
Rd * 200 400 1 42
Re 300 400 3
* 200 400 1 2
At this point we are back to Step 2 and are in a loop
McPherson, et al. Informational [Page 15]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
3.2. Potential Workarounds for Type II
1) Do not accept MEDs from peers (this may not be a
alternative).
2) Utilize other BGP attributes higher in the decision process
that the BGP decision algorithm selects a single AS before
reaches the MED step. For example, if local-pref were set
on the advertising AS, then you first eliminate all routes
those in a single AS. In the example, router Re would pick
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
than intra-cluster or intra-sub-AS metrics
Type II: Make route selections based on local-pref assigned to
advertising AS first and then use IGP cost and MED to
selection among routes from the same AS
Note that this requires per-prefix policies, as well as
intimate knowledge of other networks by the network operator.
authors are not aware of ANY [large] provider today that
per-prefix policies on routes learned from peers.
removing this dynamic portion of route selection does not
to be a viable option in today's networks. The main point is
an available workaround using local-pref so that no two AS'
advertise a given prefix at the same local-pref solves type
churn
3) Always compare BGP MEDs, regardless of whether or not they
obtained from a single AS. This is probably a bad idea since
may be derived in a number of ways, and are typically done so as
matter of operator-specific policy and largely a function
available metric space provided by the employed IGP. As such
comparing MED values for a single prefix learned from multiple
is ill-advised. This mostly defeats the purpose of MEDs; Option 1
may be a more viable alternative
4) Do not use more than one tier of Route Reflection or Sub-ASs
the network. The risk of route oscillation should be
when designing networks that might use a multi-tiered
isolation architecture
5) In a RR topology, mesh the clients. For confederations, mesh
border routers at each level in the hierarchy. In Figure 3,
example, if Rb and Re are peers, then there's no churn
McPherson, et al. Informational [Page 16]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
4. Future
It should be stated that protocol enhancements regarding this
must be pursued. Imposing network design requirements, such as
outlined above, are clearly an unreasonable long-term solution
Problems such as this should not occur under 'default'
configurations
5. Security
This discussion introduces no new security concerns to BGP or
specifications referenced in this document
6.
The authors would like to thank Curtis Villamizar, Tim Griffin,
Scudder, Ron Da Silva, Jeffrey Haas and Bill Fenner
7.
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
1771, March 1995.
[2] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection -
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] Traina, P., McPherson, D. and J. Scudder, J., "Autonomous
Confederations for BGP", RFC 3065, February 2001.
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
Work in Progress
McPherson, et al. Informational [Page 17]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
8. Authors'
Danny
EMail: danny@tcb.
Vijay
AOL Time Warner, Inc
12100 Sunrise Valley
Reston, VA 20191
EMail: vijay@umbc.
Daniel
Cisco Systems, Inc
7025 Kit Creek Rd
Research Triangle Park, NC 27709
EMail: dwalton@cisco.
Alvaro
Cisco Systems, Inc
7025 Kit Creek Rd
Research Triangle Park, NC 27709
EMail: aretana@cisco.
McPherson, et al. Informational [Page 18]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
9. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
McPherson, et al. Informational [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
