Internet Engineering Task Force (IETF) E. Jasinska
Request for Comments: 7947 BigWave IT
Category: Standards Track N. Hilliard
ISSN: 2070-1721 INEX
R. Raszuk
Bloomberg LP
N. Bakker
Akamai Technologies B.V.
September 2016
Internet Engineering Task Force (IETF) E. Jasinska
Request for Comments: 7947 BigWave IT
Category: Standards Track N. Hilliard
ISSN: 2070-1721 INEX
R. Raszuk
Bloomberg LP
N. Bakker
Akamai Technologies B.V.
September 2016
Internet Exchange BGP Route Server
因特网交换BGP路由服务器
Abstract
摘要
This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.
本文件概述了互联网交换点（IXP）多边互连规范。多边互连是一种使用单个中间代理系统（称为路由服务器）在三个或更多外部BGP（EBGP）扬声器之间交换路由信息的方法。路由服务器通常用于共享访问媒体网络（如IXP），以简化多个Internet路由器之间的互连。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7947.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7947.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction to Multilateral Interconnection . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Technical Considerations for Route Server Implementations . . 4
2.1. Client UPDATE Messages . . . . . . . . . . . . . . . . . 4
2.2. Attribute Transparency . . . . . . . . . . . . . . . . . 4
2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . 4
2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 5
2.2.2.1. Route Server AS_PATH Management . . . . . . . . . 5
2.2.2.2. Route Server client AS_PATH Management . . . . . 5
2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 5
2.2.4. Communities Attributes . . . . . . . . . . . . . . . 5
2.3. Per-Client Policy Control in Multilateral Interconnection 6
2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 6
2.3.2. Mitigation of Path Hiding . . . . . . . . . . . . . . 7
2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . 7
2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . 8
2.3.3. Implementation Suggestions . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Normative References . . . . . . . . . . . . . . . . . . 10
4.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction to Multilateral Interconnection . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Technical Considerations for Route Server Implementations . . 4
2.1. Client UPDATE Messages . . . . . . . . . . . . . . . . . 4
2.2. Attribute Transparency . . . . . . . . . . . . . . . . . 4
2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . 4
2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 5
2.2.2.1. Route Server AS_PATH Management . . . . . . . . . 5
2.2.2.2. Route Server client AS_PATH Management . . . . . 5
2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 5
2.2.4. Communities Attributes . . . . . . . . . . . . . . . 5
2.3. Per-Client Policy Control in Multilateral Interconnection 6
2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 6
2.3.2. Mitigation of Path Hiding . . . . . . . . . . . . . . 7
2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . 7
2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . 8
2.3.3. Implementation Suggestions . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Normative References . . . . . . . . . . . . . . . . . . 10
4.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Internet Exchange Points (IXPs) provide IP data interconnection facilities for their participants, typically using shared Layer 2 networking media such as Ethernet. The Border Gateway Protocol (BGP) [RFC4271], an inter-Autonomous System (inter-AS) routing protocol, is commonly used to facilitate exchange of network reachability information over such media.
Internet交换点（IXP）为其参与者提供IP数据互连设施，通常使用共享的第2层网络媒体，如以太网。边界网关协议（BGP）[RFC4271]，一种跨自治系统（inter-AS）路由协议，通常用于促进通过此类介质交换网络可达性信息。
While bilateral EBGP sessions between exchange participants were previously the most common means of exchanging reachability information, the overhead associated with dense interconnection can cause substantial operational scaling problems for participants of larger IXPs.
虽然exchange参与者之间的双边EBGP会话以前是交换可达性信息的最常见方式，但与密集互连相关的开销可能会对较大IXP的参与者造成严重的操作扩展问题。
Multilateral interconnection is a method of interconnecting BGP speaking routers using a third-party brokering system, commonly referred to as a route server and typically managed by the IXP operator. Each multilateral interconnection participant (usually referred to as a "route server client") announces network reachability information to the route server using EBGP. The route server, in turn, forwards this information to each route server client connected to it, according to its configuration. Although a route server uses BGP to exchange reachability information with each of its clients, it does not forward traffic itself and is therefore not a router.
多边互连是使用第三方代理系统互连讲BGP的路由器的一种方法，通常称为路由服务器，通常由IXP运营商管理。每个多边互连参与者（通常称为“路由服务器客户端”）使用EBGP向路由服务器宣布网络可达性信息。路由服务器根据其配置将此信息转发给与其连接的每个路由服务器客户端。尽管路由服务器使用BGP与每个客户端交换可达性信息，但它本身并不转发流量，因此不是路由器。
A route server can be viewed as similar in function to a route reflector [RFC4456], except that it operates using EBGP instead of Internal BGP (IBGP). Certain adaptions to [RFC4271] are required to enable an EBGP router to operate as a route server; these are outlined in Section 2 of this document. Route server functionality is not mandatory in BGP implementations.
路由服务器在功能上与路由反射器[RFC4456]类似，只是它使用EBGP而不是内部BGP（IBGP）运行。需要对[RFC4271]进行某些自适应，以使EBGP路由器能够作为路由服务器运行；本文件第2节概述了这些内容。路由服务器功能在BGP实施中不是强制性的。
The term "route server" is often used in a different context to describe a BGP node whose purpose is to accept BGP feeds from multiple clients for the purpose of operational analysis and troubleshooting. A system of this form may alternatively be known as a "route collector" or a "route-views server". This document uses the term "route server" exclusively to describe multilateral peering brokerage systems.
术语“路由服务器”通常在不同的上下文中用于描述BGP节点，其目的是接受来自多个客户端的BGP馈送，以便进行操作分析和故障排除。这种形式的系统也可以称为“路由收集器”或“路由视图服务器”。本文档专门使用术语“路由服务器”来描述多边对等代理系统。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
A route server uses BGP [RFC4271] to broker network reachability information amongst its clients. There are some differences between the behavior of a BGP route server and a BGP implementation that is strictly compliant with [RFC4271]. These differences are described as follows.
路由服务器使用BGP[RFC4271]在其客户端之间代理网络可达性信息。BGP路由服务器的行为与严格遵守[RFC4271]的BGP实现之间存在一些差异。这些差异描述如下。
A route server MUST accept all UPDATE messages received from each of its clients for inclusion in its Adj-RIB-In. These UPDATE messages MAY be omitted from the route server's Loc-RIB or Loc-RIBs, due to filters configured for the purpose of implementing routing policy. The route server SHOULD perform one or more BGP Decision Processes to select routes for subsequent advertisement to its clients, taking into account possible configuration to provide multiple Network Layer Reachability Information (NLRI) paths to a particular client as described in Section 2.3.2.2 or multiple Loc-RIBs as described in Section 2.3.2.1. The route server SHOULD forward UPDATE messages from its Loc-RIB or Loc-RIBs to its clients as determined by local policy.
路由服务器必须接受从其每个客户端接收的所有更新消息，以便包含在其Adj RIB in中。由于为实现路由策略而配置的过滤器，路由服务器的Loc RIB或Loc RIB中可能会忽略这些更新消息。路由服务器应执行一个或多个BGP决策过程，以选择用于随后向其客户端播发的路由，同时考虑提供多个网络层可达性信息（NLRI）的可能配置至第2.3.2.2节所述特定客户的路径或第2.3.2.1节所述的多个Loc肋骨。路由服务器应根据本地策略将更新消息从其Loc RIB或Loc RIB转发至其客户端。
As a route server primarily performs a brokering service, modification of attributes could cause route server clients to alter their BGP Decision Process for received prefix reachability information, thereby changing the intended routing policies of exchange participants. Therefore, contrary to what is specified in Section 5 of [RFC4271], route servers SHOULD NOT by default (unless explicitly configured) update well-known BGP attributes received from route server clients before redistributing them to their other route server clients. Optional recognized and unrecognized BGP attributes, whether transitive or non-transitive, SHOULD NOT be updated by the route server (unless enforced by local IXP operator configuration) and SHOULD be passed on to other route server clients.
由于路由服务器主要执行代理服务，修改属性可能会导致路由服务器客户端更改其BGP决策过程以获取接收到的前缀可达性信息，从而更改exchange参与者的预期路由策略。因此，与[RFC4271]第5节中的规定相反，路由服务器在将其重新分发到其他路由服务器客户端之前，默认情况下（除非明确配置）不应更新从路由服务器客户端接收的已知BGP属性。路由服务器不应更新可选的已识别和未识别的BGP属性，无论是可传递的还是不可传递的（除非由本地IXP操作员配置强制），而应将其传递给其他路由服务器客户端。
The NEXT_HOP is a well-known mandatory BGP attribute that defines the IP address of the router used as the next hop to the destinations listed in the NLRI field of the UPDATE message. As the route server does not participate in the actual routing of traffic, the NEXT_HOP attribute MUST be passed unmodified to the route server clients, similar to the "third-party" next-hop feature described in Section 5.1.3. of [RFC4271].
下一跳是众所周知的强制BGP属性，它定义了路由器的IP地址，该路由器用作到更新消息的NLRI字段中列出的目的地的下一跳。由于路由服务器不参与流量的实际路由，下一跳属性必须未经修改地传递给路由服务器客户端，类似于第5.1.3节中描述的“第三方”下一跳功能。属于[RFC4271]。
AS_PATH is a well-known mandatory attribute that identifies the ASes through which routing information carried in the UPDATE message has passed.
AS_PATH是一个众所周知的强制属性，用于标识更新消息中承载的路由信息所经过的ASE。
As a route server does not participate in the process of forwarding data between client routers, and because modification of the AS_PATH attribute could affect the route server client BGP Decision Process, the route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way. This differs from the behavior specified in Section 5.1.2 of [RFC4271], which requires that the BGP speaker prepends its own AS number as the last element of the AS_PATH segment. This is a recommendation rather than a requirement solely to provide backwards compatibility with legacy route server client implementations that do not yet support the requirements specified in Section 2.2.2.2.
由于路由服务器不参与在客户端路由器之间转发数据的过程，并且由于修改As_路径属性可能会影响路由服务器客户端BGP决策过程，因此路由服务器不应将其自身的As编号预先添加到As_路径段，也不应以任何其他方式修改As_路径段。这与[RFC4271]第5.1.2节中规定的行为不同，该行为要求BGP扬声器将其自身的AS编号作为AS_路径段的最后一个元素。这是一项建议，而不仅仅是一项要求，旨在提供与旧式路由服务器客户端实现的向后兼容性，这些客户端实现尚不支持第2.2.2.2节中规定的要求。
In contrast to what is recommended in Section 6.3 of [RFC4271], route server clients need to be able to accept UPDATE messages where the leftmost AS in the AS_PATH attribute is not equal to the AS number of the route server that sent the UPDATE message. If the route server client BGP system has implemented a check for this, the BGP implementation MUST allow this check to be disabled and SHOULD allow the check to be disabled on a per-peer basis.
与[RFC4271]第6.3节中的建议相反，当AS_PATH属性中最左侧的AS不等于发送更新消息的路由服务器的AS编号时，路由服务器客户端需要能够接受更新消息。如果路由服务器客户端BGP系统已对此实施检查，则BGP实施必须允许禁用此检查，并且应允许在每个对等基础上禁用此检查。
MULTI_EXIT_DISC is an optional non-transitive attribute intended to be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS. Contrary to Section 5.1.4 of [RFC4271], if applied to an NLRI UPDATE sent to a route server, this attribute SHOULD be propagated to other route server clients, and the route server SHOULD NOT modify its value.
MULTI_EXIT_DISC是一个可选的非传递属性，用于外部（AS间）链接，以区分到同一相邻AS的多个出口或入口点。与[RFC4271]第5.1.4节相反，如果应用于发送到路由服务器的NLRI更新，则该属性应传播到其他路由服务器客户端，且路由服务器不应修改其值。
The BGP Communities [RFC1997] and Extended Communities [RFC4360] attributes are intended for labeling information carried in BGP UPDATE messages. Transitive as well as non-transitive Communities attributes applied to an NLRI UPDATE sent to a route server SHOULD NOT be modified, processed, or removed, except as defined by local
BGP社区[RFC1997]和扩展社区[RFC4360]属性用于标记BGP更新消息中携带的信息。应用于发送到路由服务器的NLRI更新的可传递和不可传递社区属性不应修改、处理或删除，除非本地
policy. If a Communities attribute is intended for processing by the route server itself, as determined by local policy, it MAY be modified or removed.
政策如果由本地策略确定的Communities属性要由路由服务器本身进行处理，则可以修改或删除该属性。
While IXP participants often use route servers with the intention of interconnecting with as many other route server participants as possible, there are circumstances where control of path distribution on a per-client basis is important to ensure that desired interconnection policies are met.
虽然IXP参与者通常使用路由服务器，目的是与尽可能多的其他路由服务器参与者互连，但在某些情况下，基于每个客户端的路径分布控制对于确保满足所需的互连策略非常重要。
The control of path distribution on a per-client basis can lead to a path being hidden from the route server client. We refer to this as "path hiding".
基于每个客户端对路径分布的控制可能导致对路由服务器客户端隐藏路径。我们称之为“路径隐藏”。
Neither Section 2.3 nor its subsections form part of the normative specification of this document; they are included for information purposes only.
第2.3节及其子节均不构成本文件规范性规范的一部分；这些信息仅供参考。
___ ___
/ \ / \
..| AS1 |..| AS2 |..
: \___/ \___/ :
: \ / | :
: \ / | :
: IXP \/ | :
: /\ | :
: / \ | :
: ___/____\_|_ :
: / \ / \ :
..| AS3 |..| AS4 |..
\___/ \___/
___ ___
/ \ / \
..| AS1 |..| AS2 |..
: \___/ \___/ :
: \ / | :
: \ / | :
: IXP \/ | :
: /\ | :
: / \ | :
: ___/____\_|_ :
: / \ / \ :
..| AS3 |..| AS4 |..
\___/ \___/
Figure 1: Per-Client Policy Controlled Interconnection at an IXP
图1:IXP上每个客户端策略控制的互连
Using the example in Figure 1, AS1 does not directly exchange prefix information with either AS2 or AS3 at the IXP but only interconnects with AS4. The lines between AS1, AS2, AS3, and AS4 represent interconnection relationships, whether via bilateral or multilateral connections.
使用图1中的示例，AS1在IXP上不直接与AS2或AS3交换前缀信息，而只与AS4互连。AS1、AS2、AS3和AS4之间的线路表示互连关系，无论是通过双边连接还是多边连接。
In the traditional bilateral interconnection model, per-client policy control to a third-party exchange participant is accomplished either by not engaging in a bilateral interconnection with that participant or by implementing outbound filtering on the BGP session towards that
在传统的双边互连模型中，对第三方exchange参与者的每客户端策略控制要么通过不与该参与者进行双边互连，要么通过在BGP会话上对该参与者实施出站过滤来实现
participant. However, in a multilateral interconnection environment, only the route server can perform outbound filtering in the direction of the route server client; route server clients depend on the route server to perform their outbound filtering for them.
参与者然而，在多边互连环境中，只有路由服务器可以在路由服务器客户端的方向上执行出站过滤；路由服务器客户端依赖路由服务器为其执行出站筛选。
Assuming the BGP Decision Process [RFC4271] is used, when the same prefix is advertised to a route server from multiple route server clients, the route server will select a single path for propagation to all connected clients. If, however, the route server has been configured to filter the calculated best path from reaching a particular route server client, then that client will not receive a path for that prefix, although alternate paths received by the route server might have been policy compliant for that client. This phenomenon is referred to as "path hiding".
假设使用BGP决策过程[RFC4271]，当从多个路由服务器客户端向路由服务器播发相同的前缀时，路由服务器将选择一条路径传播到所有连接的客户端。但是，如果路由服务器已配置为过滤到达特定路由服务器客户端的计算出的最佳路径，则该客户端将不会收到该前缀的路径，尽管路由服务器接收的备用路径可能与该客户端的策略兼容。这种现象被称为“路径隐藏”。
For example, in Figure 1, if the same prefix were sent to the route server via AS2 and AS4, and the route via AS2 was preferred according to the BGP Decision Process on the route server, but AS2's policy prevented the route server from sending the path to AS1, then AS1 would never receive a path to this prefix, even though the route server had previously received a valid alternative path via AS4. This happens because the BGP Decision Process is performed only once on the route server for all clients.
例如，在图1中，如果通过AS2和AS4将相同的前缀发送到路由服务器，并且根据路由服务器上的BGP决策过程，通过AS2的路由是首选的，但是AS2的策略阻止路由服务器将路径发送到AS1，那么AS1将永远不会接收到此前缀的路径，即使路由服务器先前已通过AS4接收到有效的备用路径。这是因为BGP决策过程仅在路由服务器上对所有客户端执行一次。
Path hiding will only occur on route servers that employ per-client policy control; if an IXP operator deploys a route server without implementing a per-client routing policy control system, then path hiding does not occur, as all paths are considered equally valid from the point of view of the route server.
路径隐藏只会发生在采用每客户端策略控制的路由服务器上；如果IXP运营商部署路由服务器时未实施每客户端路由策略控制系统，则不会发生路径隐藏，因为从路由服务器的角度来看，所有路径都被视为同等有效。
There are several approaches that can be taken to mitigate against path hiding.
有几种方法可以用来减轻路径隐藏的影响。
The most portable method to allow for per-client policy control without the occurrence of path hiding is to use a route server BGP implementation that performs the per-client best path calculation for each set of paths to a prefix, which results after the route server's client policies have been taken into consideration. This can be implemented by using per-client Loc-RIBs, with path filtering implemented between the Adj-RIB-In and the per-client Loc-RIB. Implementations can optimize this by maintaining paths not subject to filtering policies in a global Loc-RIB, with per-client Loc-RIBs stored as deltas.
允许在不发生路径隐藏的情况下进行每客户端策略控制的最可移植的方法是使用路由服务器BGP实现，该实现对指向前缀的每一组路径执行每客户端最佳路径计算，这将在考虑路由服务器的客户端策略后产生。这可以通过使用每客户Loc肋骨实现，并在Adj肋骨In和每客户Loc肋骨之间实现路径过滤。实现可以通过在全局Loc RIB中维护不受过滤策略约束的路径来优化这一点，每个客户端Loc RIB存储为增量。
This implementation is highly portable, as it makes no assumptions about the feature capabilities of the route server clients.
此实现具有很高的可移植性，因为它不对路由服务器客户端的功能进行假设。
The path distribution model described above assumes standard BGP session encoding where the route server sends a single path to its client for any given prefix. This path is selected using the BGP path selection Decision Process described in [RFC4271]. If, however, it were possible for the route server to send more than a single path to a route server client, then route server clients would no longer depend on receiving a single path to a particular prefix; consequently, the path-hiding problem described in Section 2.3.1 would disappear.
上述路径分布模型假设标准BGP会话编码，其中路由服务器为任何给定前缀向其客户端发送单个路径。使用[RFC4271]中描述的BGP路径选择决策过程选择该路径。然而，如果路由服务器可以向路由服务器客户端发送多个路径，则路由服务器客户端将不再依赖于接收到特定前缀的单个路径；因此，第2.3.1节中描述的路径隐藏问题将消失。
We present two methods that describe how such increased path diversity could be implemented.
我们提出了两种方法来描述如何实现这种增加的路径多样性。
The diverse BGP path proposal as defined in [RFC6774] is a simple way to distribute multiple prefix paths from a route server to a route server client by using a separate BGP session from the route server to a client for each different path.
[RFC6774]中定义的多样化BGP路径方案是一种简单的方法，通过使用从路由服务器到客户端的单独BGP会话，为每个不同路径分配从路由服务器到路由服务器客户端的多个前缀路径。
The number of paths that may be distributed to a client is constrained by the number of BGP sessions that the server and the client are willing to establish with each other. The distributed paths may be established from the global BGP Loc-RIB on the route server in addition to any per-client Loc-RIB. As there may be more potential paths to a given prefix than configured BGP sessions, this method is not guaranteed to eliminate the path-hiding problem in all situations. Furthermore, this method may significantly increase the number of BGP sessions handled by the route server, which may negatively impact its performance.
可分配给客户机的路径数量受服务器和客户机愿意彼此建立的BGP会话数量的限制。除了每个客户端Loc RIB之外，还可以从路由服务器上的全局BGP Loc RIB建立分布式路径。由于到给定前缀的潜在路径可能比配置的BGP会话多，因此该方法不能保证在所有情况下消除路径隐藏问题。此外，此方法可能会显著增加路由服务器处理的BGP会话数，这可能会对其性能产生负面影响。
[RFC7911] proposes a different approach to multiple path propagation, by allowing a BGP speaker to forward multiple paths for the same prefix on a single BGP session. As [RFC4271] specifies that a BGP listener must implement an implicit withdraw when it receives an UPDATE message for a prefix that already exists in its Adj-RIB-In, this approach requires explicit support for the feature both on the route server and on its clients.
[RFC7911]提出了一种不同的多路径传播方法，允许BGP演讲者在单个BGP会话上转发同一前缀的多条路径。由于[RFC4271]规定BGP侦听器在收到其Adj RIB in中已经存在的前缀的更新消息时必须实现隐式撤回，因此这种方法需要路由服务器及其客户端对该功能的明确支持。
If the ADD-PATH capability is negotiated bidirectionally between the route server and a route server client, and the route server client propagates multiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid, or suboptimal paths to the route server, thereby causing loss of reachability to other route server clients. For this reason, ADD-PATH implementations on a route server should enforce a send-only mode with the route server clients, which would result in negotiating a receive-only mode from the client to the route server.
如果在路由服务器和路由服务器客户端之间双向协商添加路径功能，并且路由服务器客户端向路由服务器传播相同前缀的多条路径，则这可能会导致向路由服务器传播非活动、无效或次优路径，从而导致其他路由服务器客户端无法访问。因此，路由服务器上的添加路径实现应该对路由服务器客户端强制执行仅发送模式，这将导致从客户端到路由服务器协商仅接收模式。
Authors of route server implementations may wish to consider one of the methods described in Section 2.3.2 to allow per-client route server policy control without path hiding.
路由服务器实现的作者可能希望考虑在2.3.2节中描述的方法之一，以允许无路径隐藏的每个客户端路由服务器策略控制。
Recommendations for route server operations are described separately in [RFC7948].
[RFC7948]中分别介绍了路由服务器操作的建议。
The path-hiding problem outlined in Section 2.3.1 can be used in certain circumstances to proactively block third-party path announcements from other route server clients. Route server operators should be aware that security issues may arise unless steps are taken to mitigate against path hiding.
第2.3.1节中概述的路径隐藏问题可在某些情况下用于主动阻止来自其他路由服务器客户端的第三方路径公告。路由服务器操作员应注意，除非采取措施缓解路径隐藏，否则可能会出现安全问题。
The AS_PATH check described in Section 2.2.2 is normally enabled in order to check for malformed AS paths. If this check is disabled, the route server client loses the ability to check incoming UPDATE messages for certain categories of problems. This could potentially cause corrupted BGP UPDATE messages to be propagated where they might not be propagated if the check were enabled. Regardless of any problems relating to malformed UPDATE messages, this check is also used to detect BGP loops; removing the check could potentially cause routing loops to be formed. Consequently, this check SHOULD NOT be disabled by IXP participants unless it is needed to establish BGP sessions with a route server and, if possible, should only be disabled for peers that are route servers.
通常启用第2.2.2节中描述的AS_路径检查，以检查格式不正确的AS路径。如果禁用此检查，路由服务器客户端将无法检查传入的更新消息是否存在某些类型的问题。这可能会导致损坏的BGP更新消息在启用检查后可能无法传播的位置传播。无论与格式错误的更新消息有关的任何问题，此检查也用于检测BGP循环；删除检查可能会导致形成路由循环。因此，IXP参与者不应禁用此检查，除非需要与路由服务器建立BGP会话，并且如果可能，应仅对作为路由服务器的对等方禁用此检查。
Route server operators should carefully consider the security practices discussed in "BGP Operations and Security" [RFC7454].
路由服务器操作员应仔细考虑“BGP操作和安全”中讨论的安全实践[RCFC454 ]。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997]Chandra，R.，Traina，P.，和T.Li，“BGP社区属性”，RFC 1997，DOI 10.17487/RFC1997，1996年8月<http://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，DOI 10.17487/RFC4360，2006年2月<http://www.rfc-editor.org/info/rfc4360>.
[RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh routing", RFC 1863, DOI 10.17487/RFC1863, October 1995, <http://www.rfc-editor.org/info/rfc1863>.
[RFC1863]Haskin，D.，“全网状路由的BGP/IDRP路由服务器替代方案”，RFC 1863，DOI 10.17487/RFC1863，1995年10月<http://www.rfc-editor.org/info/rfc1863>.
[RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, DOI 10.17487/RFC4223, October 2005, <http://www.rfc-editor.org/info/rfc4223>.
[RFC4223]Savola，P.，“将RFC 1863重新分类为历史”，RFC 4223，DOI 10.17487/RFC4223，2005年10月<http://www.rfc-editor.org/info/rfc4223>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.
[RFC4456]Bates，T.，Chen，E.和R.Chandra，“BGP路由反射：全网格内部BGP（IBGP）的替代方案”，RFC 4456，DOI 10.17487/RFC4456，2006年4月<http://www.rfc-editor.org/info/rfc4456>.
[RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., and K. Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, DOI 10.17487/RFC6774, November 2012, <http://www.rfc-editor.org/info/rfc6774>.
[RFC6774]Raszuk，R.，Ed.，Fernando，R.，Patel，K.，McPherson，D.，和K.Kumaki，“不同BGP路径的分布”，RFC 6774，DOI 10.17487/RFC6774，2012年11月<http://www.rfc-editor.org/info/rfc6774>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>.
[RFC7454]Durand，J.，Pepelnjak，I.，和G.Doering，“BGP运营和安全”，BCP 194，RFC 7454，DOI 10.17487/RFC7454，2015年2月<http://www.rfc-editor.org/info/rfc7454>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <http://www.rfc-editor.org/info/rfc7911>.
[RFC7911]Walton，D.，Retana，A.，Chen，E.，和J.Scudder，“BGP中多路径的广告”，RFC 7911，DOI 10.17487/RFC7911，2016年7月<http://www.rfc-editor.org/info/rfc7911>.
[RFC7948] Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server Operations", RFC 7948, DOI 10.17487/RFC7948, September 2016, <http://www.rfc-editor.org/info/rfc7948>.
[RFC7948]Hilliard，N.，Jasinska，E.，Raszuk，R.，和N.Bakker，“互联网交换BGP路由服务器操作”，RFC 7948，DOI 10.17487/RFC7948，2016年9月<http://www.rfc-editor.org/info/rfc7948>.
Acknowledgments
致谢
The authors would like to thank Ryan Bickhart, Steven Bakker, Martin Pels, Chris Hall, Aleksi Suhonen, Bruno Decraene, Pierre Francois, and Eduardo Ascenco Reis for their valuable input.
作者要感谢Ryan Bickhart、Steven Bakker、Martin Pels、Chris Hall、Aleksi Suhonen、Bruno Decarene、Pierre Francois和Eduardo Ascenco Reis的宝贵意见。
In addition, the authors would like to acknowledge the developers of BIRD, OpenBGPD, Quagga, and IOS whose BGP implementations include route server capabilities that are compliant with this document.
此外，作者还要感谢BIRD、OpenBGPD、Quagga和IOS的开发人员，他们的BGP实现包括符合本文档的路由服务器功能。
Route server functionality was described in 1995 in [RFC1863], and modern route server implementations are based on concepts developed in the 1990s by the Routing Arbiter Project and the Route Server Next Generation (RSNG) Project, managed by ISI and Merit. Although the original RSNG code is no longer in use at any IXPs, the IXP community owes a debt of gratitude to the many people who were involved in route server development in the 1990s. Note that [RFC1863] was made historical by [RFC4223].
路由服务器功能于1995年在[RFC1863]中进行了描述，现代路由服务器的实现基于路由仲裁器项目和路由服务器下一代（RSNG）项目在1990年代开发的概念，由ISI和Merit管理。虽然最初的RSNG代码不再在任何IXP中使用，但IXP社区对20世纪90年代参与路由服务器开发的许多人表示感谢。注意，[RFC1863]被[RFC4223]作为历史记录。
Authors' Addresses
作者地址
Elisa Jasinska BigWave IT ul. Skawinska 27/7 Krakow, MP 31-066 Poland
伊莉莎·贾辛斯卡·比格瓦夫。波兰克拉科夫市斯卡温斯卡27/7号，邮编31-066
Email: elisa@bigwaveit.org
Email: elisa@bigwaveit.org
Nick Hilliard INEX 4027 Kingswood Road Dublin 24 Ireland
Nick Hilliard INEX 4027 Kingswood路都柏林24号爱尔兰
Email: nick@inex.ie
Email: nick@inex.ie
Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 United States of America
美国纽约市列克星敦大道731号罗伯特·拉祖克·布隆伯格有限公司，邮编：10022
Email: robert@raszuk.net
Email: robert@raszuk.net
Niels Bakker Akamai Technologies B.V. Kingsfordweg 151 Amsterdam 1043 GR Netherlands
Niels Bakker Akamai Technologies B.V.Kingsfordweg 151阿姆斯特丹1043格荷兰
Email: nbakker@akamai.com
Email: nbakker@akamai.com