draft-ietf-idr-route-reflect-v2-00.txt   draft-ietf-idr-route-reflect-v2-01.txt 
INTERNET-DRAFT Tony Bates INTERNET-DRAFT Tony Bates
<draft-ietf-idr-route-reflect-v2-00.txt> Ravi Chandra <draft-ietf-idr-route-reflect-v2-01.txt> Ravi Chandra
Enke Chen Enke Chen
Cisco Systems Cisco Systems
November 1998 April 1999
BGP Route Reflection BGP Route Reflection
An alternative to full mesh IBGP An alternative to full mesh IBGP
<draft-ietf-idr-route-reflect-v2-00.txt> <draft-ietf-idr-route-reflect-v2-01.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 1, line 41 skipping to change at page 1, line 41
The Border Gateway Protocol [1] is an inter-autonomous system routing The Border Gateway Protocol [1] is an inter-autonomous system routing
protocol designed for TCP/IP internets. Currently in the Internet BGP protocol designed for TCP/IP internets. Currently in the Internet BGP
deployments are configured such that that all BGP speakers within a deployments are configured such that that all BGP speakers within a
single AS must be fully meshed so that any external routing single AS must be fully meshed so that any external routing
information must be re-distributed to all other routers within that information must be re-distributed to all other routers within that
AS. This represents a serious scaling problem that has been well AS. This represents a serious scaling problem that has been well
documented with several alternatives proposed [2,3]. documented with several 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, BGP deployments are configured such that Currently in the Internet, BGP deployments are configured such that
that all BGP speakers within a single AS must be fully meshed and any that all BGP speakers within a single AS must be fully meshed and any
external routing information must be re-distributed to all other external routing information must be re-distributed to all other
routers within that AS. For n BGP speakers within an AS that routers within that AS. For n BGP speakers within an AS that
requires to maintain n*(n-1)/2 unique IBGP sessions. This "full requires to maintain n*(n-1)/2 unique IBGP sessions. This "full
mesh" requirement clearly does not scale when there are a large mesh" requirement clearly does not scale when there are a large
number of IBGP speakers each exchanging a large volume of routing number of IBGP speakers each exchanging a large volume of routing
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Length is the number of octets. Where Length is the number of octets.
When a RR reflects a route, it must append the local CLUSTER_ID to When a RR reflects a route, it must prepend the local CLUSTER_ID to
the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new
one. Using this attribute an RR can identify if the routing one. Using this attribute an RR can identify if the routing
information is looped back to the same cluster due to mis- information is looped back to the same cluster due to mis-
configuration. If the local CLUSTER_ID is found in the cluster-list, configuration. If the local CLUSTER_ID is found in the cluster-list,
the advertisement received will be ignored. the advertisement received will be ignored.
8. Implementation Considerations 8. Implementation 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
skipping to change at page 8, line 17 skipping to change at page 8, line 17
there exist multiple paths for a prefix. One commonly used approach there exist multiple paths for a prefix. One commonly used approach
is the POP-based reflection, in which each POP maintains its own is the POP-based reflection, in which each POP maintains its own
route reflectors serving clients in the POP, and all route reflectors route reflectors serving clients in the POP, and all route reflectors
are fully meshed. In addition, clients of the reflectors in each POP are fully meshed. In addition, clients of the reflectors in each POP
are often fully meshed for the purpose of optimal intra-POP routing, are often fully meshed for the purpose of optimal intra-POP routing,
and the intra-POP IGP metrics are configured to be better than the and the intra-POP IGP metrics are configured to be better than the
inter-POP IGP metrics. inter-POP IGP metrics.
10. Security 10. Security
Security considerations are not discussed in this memo. This extension to BGP does not change the underlying security issues
inherent in the existing IBGP.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Dennis Ferguson, John Scudder, Paul The authors would like to thank Dennis Ferguson, John Scudder, Paul
Traina and Tony Li for the many discussions resulting in this work. Traina and Tony Li for the many discussions resulting in this work.
This idea was developed from an earlier discussion between Tony Li This idea was developed from an earlier discussion between Tony Li
and Dimitri Haskin. and Dimitri Haskin.
In addition, the authors would like to acknowledge valuable review In addition, the authors would like to acknowledge valuable review
and suggestions from Yakov Rekhter on this document, and helpful and suggestions from Yakov Rekhter on this document, and helpful
 End of changes. 

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