Network Working Group                                           T. Bates
Request for Comments: 2796                                 Cisco Systems
Updates: 1966                                                 R. Chandra
Category: Standards Track                                        E. Chen
                                                        Redback Networks
                                                              April 2000
        
Network Working Group                                           T. Bates
Request for Comments: 2796                                 Cisco Systems
Updates: 1966                                                 R. Chandra
Category: Standards Track                                        E. Chen
                                                        Redback Networks
                                                              April 2000
        

BGP Route Reflection - An Alternative to Full Mesh IBGP

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 (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

Abstract

摘要

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].

边界网关协议[1]是为TCP/IP互联网设计的自治系统间路由协议。目前,Internet中的BGP部署配置为,单个AS中的所有BGP扬声器必须完全啮合,以便任何外部路由信息必须重新分发到该AS中的所有其他路由器。这代表了一个严重的缩放问题,已经有了很好的记录,并提出了几种备选方案[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.

本文档描述了一种称为“路由反射”的方法的使用和设计,以缓解对“全网格”IBGP的需求。

1. Introduction
1. 介绍

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 information, as is common in many of todays internet networks.

目前在Internet上,BGP部署的配置方式是,单个AS内的所有BGP扬声器必须完全啮合,并且任何外部路由信息必须重新分发到该AS内的所有其他路由器。适用于AS中需要维持n*(n-1)/2个唯一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 "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 transitive BGP attributes to prevent loops in routing updates.

这种缩放问题已经有了很好的记录,并且已经提出了许多建议来缓解这一问题[2,3]。本文档代表了另一种减轻“全网格”需求的替代方案,称为“路由反射”。这种方法允许BGP演讲者(称为“路由反射器”)向某些IBGP对等方公布IBGP学习的路由。它代表了对通常理解的IBGP概念的改变,并添加了两个新的可选可传递BGP属性,以防止路由更新中的循环。

This document is a revision of RFC1966 [4], and it includes editorial changes, clarifications and corrections based on the deployment experience with route reflection. These revisions are summarized in the Appendix.

本文件是RFC1966[4]的修订版,包括基于路线反射部署经验的编辑性修改、澄清和更正。附录中总结了这些修订。

2. Design Criteria
2. 设计标准

Route Reflection was designed to satisfy the following criteria.

路线反射的设计满足以下标准。

o Simplicity

o 简单

Any alternative must be both simple to configure as well as 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 non compliant IBGP peers to continue 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.

这些标准是由具有许多外部连接的非常大且拓扑丰富的网络的运行经验推动的。

3. Route Reflection
3. 路由反射

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 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.

在ASX中有三个IBGP扬声器(路由器RTR-A、RTR-B和RTR-C)。在现有的BGP模型中,如果RTR-A接收到一条外部路由,并且该路由被选为最佳路径,则必须向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.

路由反射方案基于这一基本原则。

4. Terminology and Concepts
4. 术语和概念

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 a RR are divided into two groups:

RR的内部对等点分为两组:

1) Client Peers

1) 客户端对等点

2) Non-Client Peers

2) 非客户端对等点

A RR reflects routes between these groups, and may reflect routes among client peers. A 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组件

5. Operation
5. 活动

When a 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 the 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. A RR treats other RRs just like any other internal BGP speakers. A 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 a 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 co-exist. Conventional BGP speakers 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 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对等机来开始创建集群。可以逐步创建其他集群。

6. Redundant RRs
6. 冗余RRs

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 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的路由器_ID标识。但是,这表示单点故障,因此为了使同一集群中有多个RRs成为可能,同一集群中的所有RRs都可以配置一个4字节的集群ID,以便RR可以放弃来自同一集群中其他RRs的路由。

7. Avoiding Routing Information Loops
7. 避免路由信息循环

When a route is reflected, it is possible through mis-configuration 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 a RR in reflecting a route. This attribute will carry the ROUTER_ID 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 which recognizes the ORIGINATOR_ID attribute should ignore a route received with its ROUTER_ID as the ORIGINATOR_ID.

发起人ID是一个新的可选的、不可传递的BGP属性,类型代码为9。此属性的长度为4字节,将由RR在反映路由时创建。此属性将携带本地AS中路由发起者的路由器ID。BGP演讲者不应创建发起者ID属性(如果已经存在)。识别发起者标识属性的路由器应忽略以其路由器标识作为发起者标识接收的路由。

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. It is encoded as follows:

Cluster list是一个新的可选、不可传递的BGP属性,类型代码为10。它是一系列表示路由经过的反射路径的CLUSTER_ID值。其编码如下:

             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 ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
             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.

其中Length是八位字节数。

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 should be ignored.

当RR反映路由时,它必须将本地集群ID前置到集群列表。如果集群列表为空,则必须创建一个新列表。使用此属性,RR可以识别路由信息是否由于配置错误而循环回同一集群。如果在群集列表中找到本地群集ID,则应忽略收到的播发。

8. Implementation Considerations
8. 实施考虑

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 potential 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 potential result in routing loops.

此外,当RR反映路由时,它不应修改以下路径属性:下一跳、AS\U路径、本地\U PREF和MED。它们的修改可能导致路由循环。

9. Configuration and Deployment Considerations
9. 配置和部署注意事项

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 MEDs and 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 which 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.

o 在边界路由器上设置路由的本地首选项以反映MED值。

o or by making sure the AS-path lengths from different ASs are different when the AS-path length is used as a route selection criteria.

o 或者,当AS路径长度用作路由选择标准时,确保来自不同ASs的AS路径长度不同。

o or by configuring community based policies using which the reflector can decide on the best route.

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 congruent with the network topology when 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

为了防止路由循环并保持一致的路由视图,在设计路由反射拓扑时必须仔细考虑网络拓扑。通常,当前缀存在多条路径时,路由反射拓扑应与网络拓扑一致。一种常用的方法是基于POP的反射,其中每个POP维护其自己的路由反射器,为POP中的客户端服务,并且所有路由反射器都是完全网格化的。此外,每个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 IGP度量被配置为优于内部POP IGP度量。

10. Security Considerations
10. 安全考虑

This extension to BGP does not change the underlying security issues inherent in the existing IBGP [5].

BGP的这一扩展并没有改变现有IBGP中固有的基本安全问题[5]。

11. Acknowledgments
11. 致谢

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, and John Scudder on Section 9, and from Bruce Cole.

此外,作者希望感谢Yakov Rekhter对本文件的宝贵评论和建议,以及Tony Li、Rohit Dube和John Scudder对第9节以及Bruce Cole的有益评论。

13. References
13. 工具书类

[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[1] Rekhter,Y.和T.Li,“边境网关协议4(BGP-4)”,RFC 17711995年3月。

[2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh routing", RFC 1863, October 1995.

[2] Haskin,D.,“全网状路由的BGP/IDRP路由服务器替代方案”,RFC 1863,1995年10月。

[3] Traina, P., "Limited Autonomous System Confederations for BGP", RFC 1965, June 1996.

[3] Trana,P.,“BGP有限自治系统联合会”,RFC 19651996年6月。

[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月。

14. Authors' Addresses
14. 作者地址

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 Redback Networks Inc. 350 Holger Way. San Jose, CA 95134

拉维钱德拉红背网络公司,霍尔格路350号。加利福尼亚州圣何塞95134

   EMail: rchandra@redback.com
        
   EMail: rchandra@redback.com
        

Enke Chen Redback Networks Inc. 350 Holger Way. San Jose, CA 95134

陈恩科红背网络公司,霍尔格路350号。加利福尼亚州圣何塞95134

   EMail: enke@redback.com
        
   EMail: enke@redback.com
        

Appendix Comparison with RFC 1966

附录与RFC 1966的比较

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.

“配置和部署注意事项”一节已经扩展,以解决几个操作问题。

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。