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
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)
BGP路由反射：全网格内部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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
边界网关协议（BGP）是一种为TCP/IP互联网设计的自治系统间路由协议。通常，单个AS内的所有BGP扬声器必须完全啮合，以便任何外部路由信息必须重新分发到该自治系统（AS）内的所有其他路由器。这是一个严重的缩放问题，已经有很多文件记录，并提出了几种替代方案。
This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).
本文档描述了一种称为“路由反射”的方法的使用和设计，以缓解对“全网格”内部BGP（IBGP）的需求。
This document obsoletes RFC 2796 and RFC 1966.
本文件废除了RFC 2796和RFC 1966。
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 ....................................................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
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.
通常，单个AS内的所有BGP扬声器必须完全啮合，并且任何外部路由信息必须重新分发到该AS内的所有其他路由器。适用于AS中需要维护n*（n-1）/2个唯一内部BGP（IBGP）会话的n名BGP发言人。当有大量IBGP扬声器交换大量路由信息时，这种“全网状”需求显然无法扩展，这在当今的许多网络中很常见。
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.
这一缩放问题已经有了很好的记录，并且已经提出了许多建议来缓解这一问题[2,3]。本文档代表了另一种减轻“全网格”需求的替代方案，称为“路由反射”。这种方法允许BGP演讲者（称为“路由反射器”）向某些IBGP对等方公布IBGP学习的路由。它代表了对通常理解的IBGP概念的改变，以及添加了两个新的可选非传递BGP属性，以防止路由更新中的循环。
This document obsoletes RFC 2796 [6] and RFC 1966 [4].
本文件废除了RFC 2796[6]和RFC 1966[4]。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释。
Route reflection was designed to satisfy the following criteria.
路线反射的设计满足以下标准。
o Simplicity
o 简单
Any alternative must be simple to configure and easy to understand.
任何替代方案都必须易于配置和理解。
o Easy Transition
o 易过渡
It must be possible to transition from a full-mesh configuration without the need to change either topology or AS. This is an unfortunate management overhead of the technique proposed in [3].
必须能够从全网格配置过渡，而无需更改拓扑或AS。这是[3]中提出的技术的一个不幸的管理开销。
o Compatibility
o 兼容性
It must be possible for noncompliant IBGP peers to continue to be part of the original AS or domain without any loss of BGP routing information.
不兼容的IBGP对等方必须能够继续作为原始AS或域的一部分，而不会丢失任何BGP路由信息。
These criteria were motivated by operational experiences of a very large and topology-rich network with many external connections.
这些标准是由具有许多外部连接的非常大且拓扑丰富的网络的运行经验推动的。
The basic idea of route reflection is very simple. Let us consider the simple example depicted in Figure 1 below.
路由反射的基本思想非常简单。让我们考虑下面的图1所示的简单示例。
+-------+ +-------+
| | IBGP | |
| RTR-A |--------| RTR-B |
| | | |
+-------+ +-------+
\ /
IBGP \ ASX / IBGP
\ /
+-------+
| |
| RTR-C |
| |
+-------+
+-------+ +-------+
| | IBGP | |
| RTR-A |--------| RTR-B |
| | | |
+-------+ +-------+
\ /
IBGP \ ASX / IBGP
\ /
+-------+
| |
| RTR-C |
| |
+-------+
Figure 1: Full-Mesh IBGP
图1：全网格IBGP
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
在ASX中，有三个IBGP扬声器（路由器RTR-A、RTR-B和RTR-C）。对于现有BGP模型，如果RTR-A接收到外部
route 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) will not re-advertise these IBGP learned routes to other IBGP speakers.
路由和它被选为最佳路径，它必须向RTR-B和RTR-C播发外部路由。RTR-B和RTR-C（作为IBGP扬声器）不会向其他IBGP扬声器重新播发这些IBGP学习的路由。
If this rule is relaxed and RTR-C is allowed to advertise IBGP learned routes to IBGP peers, then it could re-advertise (or reflect) the IBGP routes learned from RTR-A to RTR-B and vice versa. This would eliminate the need for the IBGP session between RTR-A and RTR-B as shown in Figure 2 below.
如果放宽此规则，并且允许RTR-C向IBGP对等方通告IBGP学习的路由，那么它可以将从RTR-A学到的IBGP路由重新通告（或反映）到RTR-B，反之亦然。这将消除RTR-A和RTR-B之间的IBGP会话需求，如下图2所示。
+-------+ +-------+
| | | |
| RTR-A | | RTR-B |
| | | |
+-------+ +-------+
\ /
IBGP \ ASX / IBGP
\ /
+-------+
| |
| RTR-C |
| |
+-------+
+-------+ +-------+
| | | |
| RTR-A | | RTR-B |
| | | |
+-------+ +-------+
\ /
IBGP \ ASX / IBGP
\ /
+-------+
| |
| RTR-C |
| |
+-------+
Figure 2: Route Reflection IBGP
图2：路由反射IBGP
The route reflection scheme is based upon this basic principle.
路由反射方案基于这一基本原则。
We use the term "route reflection" to describe the operation of a BGP speaker advertising an IBGP learned route to another IBGP peer. Such a BGP speaker is said to be a "route reflector" (RR), and such a route is said to be a reflected route.
我们使用术语“路由反射”来描述BGP演讲者向另一个IBGP对等方宣传IBGP学习的路由的操作。这样的BGP扬声器被称为“路由反射器”（RR），并且这样的路由被称为反射路由。
The internal peers of an RR are divided into two groups:
RR的内部对等点分为两组：
1) Client peers
1) 客户端对等点
2) Non-Client peers
2) 非客户端对等点
An RR reflects routes between these groups, and may reflect routes among client peers. An RR along with its client peers form a cluster. The Non-Client peer must be fully meshed but the Client peers need not be fully meshed. Figure 3 depicts a simple example outlining the basic RR components using the terminology noted above.
RR反映这些组之间的路由，并且可能反映客户端对等点之间的路由。RR及其客户机对等点构成一个集群。非客户端对等点必须完全网格化，但客户端对等点不需要完全网格化。图3描述了一个简单的示例，使用上述术语概述了基本RR组件。
/ - - - - - - - - - - - - - -
| Cluster |
+-------+ +-------+
| | | | | |
| RTR-A | | RTR-B |
| |Client | |Client | |
+-------+ +-------+
| \ / |
IBGP \ / IBGP
| \ / |
+-------+
| | | |
| RTR-C |
| | RR | |
+-------+
| / \ |
- - - - - /- - -\- - - - - - /
IBGP / \ IBGP
+-------+ +-------+
| RTR-D | IBGP | RTR-E |
| Non- |---------| Non- |
|Client | |Client |
+-------+ +-------+
/ - - - - - - - - - - - - - -
| Cluster |
+-------+ +-------+
| | | | | |
| RTR-A | | RTR-B |
| |Client | |Client | |
+-------+ +-------+
| \ / |
IBGP \ / IBGP
| \ / |
+-------+
| | | |
| RTR-C |
| | RR | |
+-------+
| / \ |
- - - - - /- - -\- - - - - - /
IBGP / \ IBGP
+-------+ +-------+
| RTR-D | IBGP | RTR-E |
| Non- |---------| Non- |
|Client | |Client |
+-------+ +-------+
Figure 3: RR Components
图3：RR组件
When an RR receives a route from an IBGP peer, it selects the best path based on its path selection rule. After the best path is selected, it must do the following depending on the type of peer it is receiving the best path from
当RR从IBGP对等方接收到路由时，它会根据其路径选择规则选择最佳路径。选择最佳路径后，它必须根据接收最佳路径的对等方的类型执行以下操作
1) A route from a Non-Client IBGP peer:
1) 来自非客户端IBGP对等方的路由：
Reflect to all the Clients.
向所有客户反映。
2) A route from a Client peer:
2) 来自客户端对等方的路由：
Reflect to all the Non-Client peers and also to the Client peers. (Hence the Client peers are not required to be fully meshed.)
向所有非客户端对等方以及客户端对等方反映。（因此，客户端对等点不需要完全网格化。）
An Autonomous System could have many RRs. An RR treats other RRs just like any other internal BGP speakers. An RR could be configured to have other RRs in a Client group or Non-client group.
一个自治系统可以有许多RRs。RR对待其他RRs就像对待任何其他内部BGP扬声器一样。RR可以配置为在客户端组或非客户端组中具有其他RR。
In a simple configuration, the backbone could be divided into many 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 configured to maintain IBGP session only with the RR in their cluster. Due to route reflection, all the IBGP speakers will receive reflected routing information.
在一个简单的配置中，主干可以分为多个集群。每个RR将配置其他RRs作为非客户端对等（因此所有RRs将完全啮合）。客户机将被配置为仅使用其集群中的RR维护IBGP会话。由于路由反射，所有IBGP扬声器将接收反射的路由信息。
It is possible in an Autonomous System to have BGP speakers that do not understand the concept of route reflectors (let us call them conventional BGP speakers). The route reflector scheme allows such conventional BGP speakers to coexist. Conventional BGP speakers could be members of either a Non-Client group or a Client group. This allows for an easy and gradual migration from the current IBGP model to the route reflection model. One could start creating clusters by configuring a single router as the designated RR and configuring other RRs and their clients as normal IBGP peers. Additional clusters can be created gradually.
在自治系统中，可能会有不了解路由反射器概念的BGP扬声器（我们称之为传统BGP扬声器）。路由反射器方案允许此类传统BGP扬声器共存。传统的BGP演讲者可以是非客户组或客户组的成员。这使得从当前IBGP模型到路由反射模型的迁移变得简单而渐进。可以通过将单个路由器配置为指定的RR，并将其他RRs及其客户端配置为普通IBGP对等机来开始创建集群。可以逐步创建其他集群。
Usually, a cluster of clients will have a single RR. In that case, the cluster will be identified by the BGP Identifier of the RR. However, this represents a single point of failure so to make it possible to have multiple RRs in the same cluster, all RRs in the same cluster can be configured with a 4-byte CLUSTER_ID so that an RR can discard routes from other RRs in the same cluster.
通常，一个客户端集群将有一个RR。在这种情况下，集群将由RR的BGP标识符标识。但是，这表示单点故障，因此为了使同一集群中有多个RRs成为可能，同一集群中的所有RRs都可以配置一个4字节的集群ID，以便RR可以放弃来自同一集群中其他RRs的路由。
When a route is reflected, it is possible through misconfiguration to form route re-distribution loops. The route reflection method defines the following attributes to detect and avoid routing information loops:
当路线被反射时，可能通过错误配置形成路线重新分配回路。路由反射方法定义以下属性以检测和避免路由信息循环：
ORIGINATOR_ID
发起人
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 an RR in reflecting a route. This attribute will carry the BGP Identifier of the originator of the route in the local AS. A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists. A router that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its BGP Identifier as the ORIGINATOR_ID.
发起人ID是一个新的可选的、不可传递的BGP属性，类型代码为9。此属性的长度为4字节，将由RR在反映路由时创建。该属性将携带本地AS中路由发起人的BGP标识符。BGP演讲者不应创建发起者ID属性（如果已经存在）。识别发起者标识属性的路由器应忽略以其BGP标识符作为发起者标识接收的路由。
CLUSTER_LIST
群集列表
CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type code 10. It is a sequence of CLUSTER_ID values representing the reflection path that the route has passed.
CLUSTER_LIST是一个新的、可选的、不可传递的BGP属性，类型代码为10。它是一系列表示路由经过的反射路径的CLUSTER_ID值。
When an 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 has looped back to the same cluster due to misconfiguration. If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement received SHOULD be ignored.
当RR反映路由时，它必须将本地集群ID前置到集群列表。如果集群列表为空，则必须创建一个新列表。使用此属性，RR可以识别路由信息是否由于配置错误而循环回同一集群。如果在CLUSTER_列表中找到本地CLUSTER_ID，则应忽略收到的播发。
The BGP Decision Process Tie Breaking rules (Sect. 9.1.2.2, [1]) are modified as follows:
BGP决策过程平局打破规则（第9.1.2.2节[1]）修改如下：
If a route carries the ORIGINATOR_ID attribute, then in Step f) the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the BGP speaker that has advertised the route.
如果路由带有发起者ID属性，则在步骤f）中，发起者ID应被视为已通告路由的BGP说话者的BGP标识符。
In addition, the following rule SHOULD be inserted between Steps f) and g): a BGP Speaker SHOULD prefer a route with the shorter CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route does not carry the CLUSTER_LIST attribute.
此外，应在步骤f）和g）之间插入以下规则：BGP演讲者应选择簇列表长度较短的路由。如果路由不带有CLUSTER_LIST属性，则CLUSTER_LIST长度为零。
Care should be taken to make sure that none of the BGP path attributes defined above can be modified through configuration when exchanging internal routing information between RRs and Clients and Non-Clients. Their modification could potentially result in routing loops.
在RRs与客户端和非客户端之间交换内部路由信息时，应注意确保上面定义的BGP路径属性不能通过配置进行修改。它们的修改可能会导致路由循环。
In addition, when a RR reflects a route, it SHOULD NOT modify the following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification could potentially result in routing loops.
此外，当RR反映路由时，它不应修改以下路径属性：下一跳、AS\U路径、本地\U PREF和MED。它们的修改可能会导致路由循环。
The BGP protocol provides no way for a Client to identify itself dynamically as a Client of an RR. The simplest way to achieve this is by manual configuration.
BGP协议无法让客户端动态地将自己标识为RR的客户端。实现这一点的最简单方法是手动配置。
One of the key component of the route reflection approach in addressing the scaling issue is that the RR summarizes routing information and only reflects its best path.
路由反射方法在解决缩放问题时的一个关键组成部分是RR总结路由信息并仅反映其最佳路径。
Both Multi-Exit Discriminators (MEDs) and Interior Gateway Protocol (IGP) metrics may impact the BGP route selection. Because MEDs are not always comparable and the IGP metric may differ for each router, with certain route reflection topologies the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach. A way to make route selection the same as it would be with the full IBGP mesh approach is to make sure that route reflectors are never forced to perform the BGP route selection based on IGP metrics that are significantly different from the IGP metrics of their clients, or based on incomparable MEDs. The former can be achieved by configuring the intra-cluster IGP metrics to be better than the inter-cluster IGP metrics, and maintaining full mesh within the cluster. The latter can be achieved by
多出口鉴别器（MED）和内部网关协议（IGP）指标都可能影响BGP路由选择。由于MED并不总是可比较的，并且每个路由器的IGP度量可能不同，因此对于某些路由反射拓扑，路由反射方法可能不会产生与全IBGP网状方法相同的路由选择结果。使路由选择与完整IBGP网格方法相同的一种方法是确保路由反射器不会被迫基于与其客户的IGP度量显著不同的IGP度量或基于不可比较的MED来执行BGP路由选择。前者可以通过将集群内IGP度量配置为优于集群间IGP度量，并在集群内保持完全网格来实现。后者可以实现
o setting the local preference of a route at the border router to reflect the MED values, or
o 在边界路由器上设置路由的本地首选项以反映MED值，或
o making sure the AS-path lengths from different ASes are different when the AS-path length is used as a route selection criteria, or
o 当AS路径长度用作路由选择标准时，确保来自不同ASE的AS路径长度不同，或
o configuring community-based policies to influence the route selection.
o 配置基于社区的策略以影响路由选择。
One could argue though that the latter requirement is overly restrictive, and perhaps impractical in some cases. One could further argue that as long as there are no routing loops, there are no compelling reasons to force route selection with route reflectors to be the same as it would be with the full IBGP mesh approach.
有人可能会争辩说，后一项要求过于严格，在某些情况下可能不切实际。有人可能会进一步争辩说，只要没有路由环路，就没有令人信服的理由迫使使用路由反射器的路由选择与使用完整IBGP网格方法的路由选择相同。
To prevent routing loops and maintain consistent routing view, it is essential that the network topology be carefully considered in designing a route reflection topology. In general, the route reflection topology should be congruent with the network topology when there exist multiple paths for a prefix. One commonly used approach is the reflection based on Point of Presence (POP), 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.
为了防止路由循环并保持一致的路由视图，在设计路由反射拓扑时必须仔细考虑网络拓扑。通常，当前缀存在多条路径时，路由反射拓扑应与网络拓扑一致。一种常用的方法是基于存在点（POP）的反射，其中每个POP维护其自己的路由反射器，服务于POP中的客户端，并且所有路由反射器都是完全网格化的。此外，每个POP中的反射器的客户端通常被完全网格化以实现最佳的POP内路由，并且POP内IGP度量被配置为优于POP间IGP度量。
This extension to BGP does not change the underlying security issues inherent in the existing IBGP [1, 5].
BGP的这一扩展并没有改变现有IBGP中固有的基本安全问题[1,5]。
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 comments from Tony Li, Rohit Dube, John Scudder, and Bruce Cole.
此外，作者希望感谢雅科夫·雷克特对本文件的宝贵评论和建议，以及托尼·李、罗希特·杜贝、约翰·斯卡德尔和布鲁斯·科尔的有益评论。
[1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[1] Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[2] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, October 2005.
[2] Savola，P.，“将RFC 1863重新分类为历史”，RFC 42232005年10月。
[3] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[3] Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 3065，2001年2月。
[4] Bates, T. and R. Chandra, "BGP Route Reflection An alternative to full mesh IBGP", RFC 1966, June 1996.
[4] Bates，T.和R.Chandra，“BGP路线反射是全网IBGP的替代方案”，RFC 1966，1996年6月。
[5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[5] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[6] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[6] Bates，T.，Chandra，R.，和E.Chen，“BGP路线反射-全网格IBGP的替代方案”，RFC 2796，2000年4月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Appendix A: Comparison with RFC 2796
附录A：与RFC 2796的比较
The impact on route selection is added.
增加了对路线选择的影响。
The pictorial description of the encoding of the CLUSTER_LIST attribute is removed as the description is redundant to the BGP specification, and the attribute length field is inadvertently described as one octet.
CLUSTER_LIST属性编码的图形描述被删除，因为该描述对BGP规范是冗余的，并且属性长度字段无意中被描述为一个八位字节。
Appendix B: Comparison with RFC 1966
附录B：与RFC 1966的比较
All the changes listed in Appendix A, plus the following.
附录A中列出的所有变更，以及以下内容。
Several terminologies related to route reflection are clarified, and the reference to EBGP routes/peers are removed.
澄清了与路由反射相关的几个术语，删除了对EBGP路由/对等点的引用。
The handling of a routing information loop (due to route reflection) by a receiver is clarified and made more consistent.
接收器对路由信息循环（由于路由反射）的处理被澄清并变得更加一致。
The addition of a CLUSTER_ID to the CLUSTER_LIST has been changed from "append" to "prepend" to reflect the deployed code.
向CLUSTER_列表中添加的CLUSTER_ID已从“append”更改为“prepend”，以反映部署的代码。
The section on "Configuration and Deployment Considerations" has been expanded to address several operational issues.
“配置和部署注意事项”一节已经扩展，以解决几个操作问题。
Authors' Addresses
作者地址
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Tony Bates Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: tbates@cisco.com
EMail: tbates@cisco.com
Ravi Chandra Sonoa Systems, Inc. 3255-7 Scott Blvd. Santa Clara, CA 95054
拉维·钱德拉·索诺亚系统公司，斯科特大道3255-7号。加利福尼亚州圣克拉拉市，95054
EMail: rchandra@sonoasystems.com
EMail: rchandra@sonoasystems.com
Enke Chen Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Enke Chen Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: enkechen@cisco.com
EMail: enkechen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。