BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
RFC 4456

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                           T. Bates
Request for Comments: 4456                                       E. Chen
Obsoletes: 2796, 1966                                      Cisco Systems
Category: Standards Track                                     R. Chandra
                                                           Sonoa Systems
                                                              April 2006

                         BGP Route Reflection:
            An Alternative to Full Mesh Internal BGP (IBGP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for TCP/IP internets.  Typically, 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 Autonomous System (AS).  This represents a serious
   scaling problem that has been well documented with several
   alternatives proposed.

   This document describes the use and design of a method known as
   "route reflection" to alleviate the need for "full mesh" Internal BGP
   (IBGP).

   This document obsoletes RFC 2796 and RFC 1966.

Bates, et al.               Standards Track                     [Page 1]
RFC 4456                  BGP Route Reflection                April 2006

Table of Contents

   1. Introduction ....................................................2
   2. Specification of Requirements ...................................2
   3. Design Criteria .................................................3
   4. Route Reflection ................................................3
   5. Terminology and Concepts ........................................4
   6. Operation .......................................................5
   7. Redundant RRs ...................................................6
   8. Avoiding Routing Information Loops ..............................6
   9. Impact on Route Selection .......................................7
   10. Implementation Considerations ..................................7
   11. Configuration and Deployment Considerations ....................7
   12. Security Considerations ........................................8
   13. Acknowledgements ...............................................9
   14. References .....................................................9
      14.1. Normative References ......................................9
      14.2. Informative References ....................................9
   Appendix A: Comparison with RFC 2796 ..............................10
   Appendix B: Comparison with RFC 1966 ..............................10

1.  Introduction

   Typically, 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 Internal BGP (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 information, as is common in many of today's networks.

   This scaling problem has been well documented, and a number of
   proposals have been made to alleviate this [2,3].  This document
   represents another alternative in alleviating the need for a "full
   mesh" and is known as "route reflection".  This approach allows a BGP
   speaker (known as a "route reflector") to advertise IBGP learned
   routes to certain IBGP peers.  It represents a change in the commonly
   understood concept of IBGP, and the addition of two new optional
   non-transitive BGP attributes to prevent loops in routing updates.

   This document obsoletes RFC 2796 [6] and RFC 1966 [4].

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7].

Bates, et al.               Standards Track                     [Page 2]
RFC 4456                  BGP Route Reflection                April 2006

3.  Design Criteria

   Route reflection was designed to satisfy the following criteria.

      o  Simplicity

         Any alternative must be simple to configure and easy to
         understand.

      o  Easy Transition

         It must be possible to transition from a full-mesh
         configuration without the need to change either topology or AS.