--- 1/draft-ietf-idr-route-reflect-v2-00.txt 2006-02-04 23:31:50.000000000 +0100 +++ 2/draft-ietf-idr-route-reflect-v2-01.txt 2006-02-04 23:31:50.000000000 +0100 @@ -1,20 +1,20 @@ INTERNET-DRAFT Tony Bates - Ravi Chandra + Ravi Chandra Enke Chen Cisco Systems - November 1998 + April 1999 BGP Route Reflection An alternative to full mesh IBGP - + Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by @@ -30,21 +30,21 @@ The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3]. 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 Currently in the Internet, BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed and any external routing information must be re-distributed to all other routers within that AS. For n BGP speakers within an AS that requires to maintain n*(n-1)/2 unique IBGP sessions. This "full mesh" requirement clearly does not scale when there are a large number of IBGP speakers each exchanging a large volume of routing @@ -250,21 +250,21 @@ code 10. It is a sequence of CLUSTER_ID values representing the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr. Flags |Attr. Type Code| Length | value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 one. Using this attribute an RR can identify if the routing information is looped back to the same cluster due to mis- configuration. If the local CLUSTER_ID is found in the cluster-list, the advertisement received will be ignored. 8. Implementation Considerations Care should be taken to make sure that none of the BGP path attributes defined above can be modified through configuration when @@ -322,21 +322,22 @@ there exist multiple paths for a prefix. One commonly used approach is the POP-based reflection, in which each POP maintains its own route reflectors serving clients in the POP, and all route reflectors are fully meshed. In addition, clients of the reflectors in each POP 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 inter-POP IGP metrics. 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 The authors would like to thank Dennis Ferguson, John Scudder, Paul Traina and Tony Li for the many discussions resulting in this work. This idea was developed from an earlier discussion between Tony Li and Dimitri Haskin. In addition, the authors would like to acknowledge valuable review and suggestions from Yakov Rekhter on this document, and helpful