draft-ietf-idr-route-reflect-01.txt   draft-ietf-idr-route-reflect-02.txt 
INTERNET-DRAFT Tony Bates INTERNET-DRAFT Tony Bates
<draft-ietf-idr-route-reflect-01.txt> MCI <draft-ietf-idr-route-reflect-02.txt> MCI
Ravi Chandra Ravi Chandra
cisco Systems cisco Systems
March 1996 April 1996
BGP Route Reflection BGP Route Reflection
An alternative to full mesh IBGP An alternative to full mesh IBGP
<draft-ietf-idr-route-reflect-01.txt> <draft-ietf-idr-route-reflect-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 2, line 7 skipping to change at page 2, line 7
fully meshed so that any external routing information must be re- fully meshed so that any external routing information must be re-
distributed to all other routers within that AS. This represents a distributed to all other routers within that AS. This represents a
serious scaling problem that has been well documented with several serious scaling problem that has been well documented with several
alternatives proposed [2,3]. alternatives proposed [2,3].
This document describes the use and design of a method known as This document describes the use and design of a method known as
"Route Reflection" to alleviate the the need for "full mesh" IBGP. "Route Reflection" to alleviate the the need for "full mesh" IBGP.
1. Introduction 1. Introduction
Currently in the Internet today, BGP deployments are configured such Currently in the Internet, BGP deployments are configured such that
that that all BGP speakers within a single AS must be fully meshed that all BGP speakers within a single AS must be fully meshed and any
and any external routing information must be re-distributed to all external routing information must be re-distributed to all other
other routers within that AS. This "full mesh" requirement clearly routers within that AS. This "full mesh" requirement clearly does not
does not scale when there are a large number of IBGP speakers as is scale when there are a large number of IBGP speakers as is common in
common in many of todays internet networks. many of todays internet networks.
For n BGP speakers within an AS you must maintain n*(n-1)/2 unique For n BGP speakers within an AS you must maintain n*(n-1)/2 unique
IBGP sessions. With finite resources in both bandwidth and router CPU IBGP sessions. With finite resources in both bandwidth and router CPU
this clearly does not scale. this clearly does not scale.
This scaling problem has been well documented and a number of This scaling problem has been well documented and a number of
proposals have been made to alleviate this [2,3]. This document proposals have been made to alleviate this [2,3]. This document
represents another alternative in alleviating the need for a "full represents another alternative in alleviating the need for a "full
mesh" and is known as "Route Reflection". It represents a change in mesh" and is known as "Route Reflection". It represents a change in
the commonly understood concept of IBGP and the addition of two new the commonly understood concept of IBGP and the addition of two new
skipping to change at page 3, line 36 skipping to change at page 3, line 36
In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR- In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR-
C). With the existing BGP model, if RTR-A receives an external route C). With the existing BGP model, if RTR-A receives an external route
and it is selected as the best path it must advertise the external and it is selected as the best path it must advertise the external
route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers) route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers)
will not re-advertise these IBGP learned routes to other IBGP will not re-advertise these IBGP learned routes to other IBGP
speakers. speakers.
If this rule is relaxed and RTR-C is allowed to reflect IBGP learned If this rule is relaxed and RTR-C is allowed to reflect IBGP learned
routes, then it could re-advertise (or reflect) the IBGP routes routes, then it could re-advertise (or reflect) the IBGP routes
learned from RTR-A to RTR-B and vice versa. This would eliminate the learned from RTR-A to RTR-B and vice versa. This would eliminate the
need for the IBGP session between RTR-A and RTR-C as shown in Figure need for the IBGP session between RTR-A and RTR-B as shown in Figure
2 below. 2 below.
+------ + +-------+ +------ + +-------+
| | | | | | | |
| RTR-A | | RTR-B | | RTR-A | | RTR-B |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
\ / \ /
IBGP \ ASX / IBGP IBGP \ ASX / IBGP
\ / \ /
skipping to change at page 5, line 19 skipping to change at page 5, line 19
the following depending on the type of the peer it is receiving the the following depending on the type of the peer it is receiving the
best path from: best path from:
1) A Route from a Non-Client peer 1) A Route from a Non-Client peer
Reflect to all other Clients. Reflect to all other Clients.
2) A Route from a Client peer 2) A Route from a Client peer
Reflect to all the Non-Client peers and also to the Reflect to all the Non-Client peers and also to the
Client peers (Hence the Client peers are not required Client peers other than the originator. (Hence the
to be fully meshed). Client peers are not required to be fully meshed).
3) Route from an EBGP peer 3) Route from an EBGP peer
Send to all the Client and Non-Client Peers. Send to all the Client and Non-Client Peers.
An Autonomous System could have many RRs. A RR treats other RRs just An Autonomous System could have many RRs. A RR treats other RRs just
like any other internal BGP speakers. A RR could be configured to like any other internal BGP speakers. A RR could be configured to
have other RRs in a Client group or Non-client group. have other RRs in a Client group or Non-client group.
In a simple configuration the backbone could be divided into many In a simple configuration the backbone could be divided into many
clusters. Each RR would be configured with other RRs as Non-Client clusters. Each RR would be configured with other RRs as Non-Client
peers (thus all the RRs will be fully meshed.). The Clients will be peers (thus all the RRs will be fully meshed.). The Clients will be
configured to maintain IBGP session only with the RR in their configured to maintain IBGP session only with the RR in their
cluster. Due to route reflection, all the IBGP speakers will receive cluster. Due to route reflection, all the IBGP speakers will receive
reflected routing information. reflected routing information.
It is normal in a Autonomous System to have BGP speakers that do not It is normal in a Autonomous System to have BGP speakers that do not
understand the concept of Route-Reflectors (let us call them as understand the concept of Route-Reflectors (let us call them
conventional BGP speakers). The Route-Reflector Scheme allows such conventional BGP speakers). The Route-Reflector Scheme allows such
conventional BGP speakers to co-exist. Conventional BGP speakers conventional BGP speakers to co-exist. Conventional BGP speakers
could be either members of Non-Client group or Client group. This could be either members of a Non-Client group or a Client group. This
allows for an easy and gradual migration from the current IBGP model allows for an easy and gradual migration from the current IBGP model
to the Route Reflection model. One could start creating clusters by to the Route Reflection model. One could start creating clusters by
configuring a single router as the designated RR and configuring configuring a single router as the designated RR and configuring
other RRs and their clients as normal IBGP peers. Additional clusters other RRs and their clients as normal IBGP peers. Additional clusters
can be created gradually. can be created gradually.
6. Redundant RRs 6. Redundant RRs
Usually a cluster of clients will have a single RR. In that case, the Usually a cluster of clients will have a single RR. In that case, the
cluster will be identified by the ROUTER_ID of the RR. However, this cluster will be identified by the ROUTER_ID of the RR. However, this
skipping to change at page 6, line 23 skipping to change at page 6, line 23
configuration to form route re-distribution loops. The Route configuration to form route re-distribution loops. The Route
Reflection method defines the following attributes to detect and Reflection method defines the following attributes to detect and
avoid routing information loops. avoid routing information loops.
ORIGINATOR_ID ORIGINATOR_ID
ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
code 9. This attribute is 4 bytes long and it will be created by a code 9. This attribute is 4 bytes long and it will be created by a
RR. This attribute will carry the ROUTER_ID of the originator of the RR. This attribute will carry the ROUTER_ID of the originator of the
route in the local AS. A BGP speaker should not create an route in the local AS. A BGP speaker should not create an
ORIGINATOR_ID attribute if one already exists If routing information ORIGINATOR_ID attribute if one already exists. A route reflector
comes back to the originator, it must be ignored. must never send routing information back to the router specified in
ORIGINATOR_ID.
CLUSTER_LIST CLUSTER_LIST
Cluster-list is a new optional, non-transitive BGP attribute of Type Cluster-list is a new optional, non-transitive BGP attribute of Type
code 10. It is a sequence of CLUSTER_ID values representing the code 10. It is a sequence of CLUSTER_ID values representing the
reflection path that the route has passed. It is encoded as follows: reflection path that the route has passed. It is encoded as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code| Length | value ... | Attr. Flags |Attr. Type Code| Length | value ...
skipping to change at page 7, line 15 skipping to change at page 7, line 15
8. Implementation and Configuration Considerations 8. Implementation and Configuration Considerations
Care should be taken to make sure that none of the BGP path Care should be taken to make sure that none of the BGP path
attributes defined above can be modified through configuration when attributes defined above can be modified through configuration when
exchanging internal routing information between RRs and Clients and exchanging internal routing information between RRs and Clients and
Non-Clients. This could result is looping of routes. Non-Clients. This could result is looping of routes.
In some implementations, modification of the BGP path attribute, In some implementations, modification of the BGP path attribute,
NEXT_HOP is possible. For example, there could be a need for a RR to NEXT_HOP is possible. For example, there could be a need for a RR to
modify NEXT_HOP for EBGP learned routes sent to its internal peers. modify NEXT_HOP for EBGP learned routes sent to its internal peers.
However, this must not be possible for an RR to set on reflected IBGP However, it must not be possible for an RR to set on reflected IBGP
routes as this breaks the basic principle of Route Reflection and routes as this breaks the basic principle of Route Reflection and
will result in potential black holes. will result in potential black holeing of traffic.
An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED, An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED,
DPA)that could change consistent route selection. This could DPA)that could change consistent route selection. This could result
resulting in potential loops. in potential loops.
The BGP protocol provides no way for a Client to identify itself The BGP protocol provides no way for a Client to identify itself
dynamically as a Client to an RR configured BGP speaker and the dynamically as a Client to an RR configured BGP speaker and the
simplest way to achieve this is by manual configuration. simplest way to achieve this is by manual configuration.
9. Security 9. Security
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
10. Acknowledgments 10. Acknowledgments
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/