Internet Engineering Task Force (IETF) H. Jeng
Request for Comments: 7024 J. Uttaro
Category: Standards Track AT&T
ISSN: 2070-1721 L. Jalil
Verizon
B. Decraene
Orange
Y. Rekhter
Juniper Networks
R. Aggarwal
Arktan
October 2013
Internet Engineering Task Force (IETF) H. Jeng
Request for Comments: 7024 J. Uttaro
Category: Standards Track AT&T
ISSN: 2070-1721 L. Jalil
Verizon
B. Decraene
Orange
Y. Rekhter
Juniper Networks
R. Aggarwal
Arktan
October 2013
Virtual Hub-and-Spoke in BGP/MPLS VPNs
BGP/MPLS VPN中的虚拟中心辐射
Abstract
摘要
With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
使用BGP/MPLS虚拟专用网络（VPN），在给定VPN的站点之间提供任意对任意连接需要连接到这些站点中一个或多个站点的每个提供商边缘（PE）路由器持有该VPN的所有路由。本文档中描述的方法允许VPN服务提供商通过只需要这些路由器的一个子集来维护所有这些路由，从而减少必须维护所有这些路由的PE路由器的数量。
Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.
此外，当PE路由器使用入口复制来承载VPN客户的多播流量时，在某些情况下，本文档中描述的方法可以降低与入口复制相关的带宽效率，并在PE路由器之间重新分配复制负载。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc7024.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7024.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Overview ........................................................3
2. Specification of Requirements ...................................4
3. Routing Information Exchange ....................................5
4. Forwarding Considerations .......................................7
5. Internet Connectivity ...........................................9
6. Deployment Considerations ......................................12
7. Multicast Considerations .......................................13
7.1. Terminology ...............................................14
7.2. Eligible Upstream Multicast Hop (UMH) Routes ..............14
7.3. Originating VPN-IP Default Route by a V-Hub ...............14
7.4. Handling C-Multicast Routes ...............................15
7.5. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ........15
7.6. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Hub ..........16
7.7. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ..........17
7.8. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Hub ............17
7.8.1. Case 1 .............................................17
7.8.2. Case 2 .............................................18
7.9. Use of Ingress Replication with I-PMSI A-D Routes .........20
8. An Example of RT Provisioning ..................................21
8.1. Unicast Routing ...........................................21
8.2. Multicast Routing .........................................22
9. Further Refinements ............................................23
10. Security Considerations .......................................23
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................24
1. Overview ........................................................3
2. Specification of Requirements ...................................4
3. Routing Information Exchange ....................................5
4. Forwarding Considerations .......................................7
5. Internet Connectivity ...........................................9
6. Deployment Considerations ......................................12
7. Multicast Considerations .......................................13
7.1. Terminology ...............................................14
7.2. Eligible Upstream Multicast Hop (UMH) Routes ..............14
7.3. Originating VPN-IP Default Route by a V-Hub ...............14
7.4. Handling C-Multicast Routes ...............................15
7.5. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ........15
7.6. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Hub ..........16
7.7. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ..........17
7.8. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Hub ............17
7.8.1. Case 1 .............................................17
7.8.2. Case 2 .............................................18
7.9. Use of Ingress Replication with I-PMSI A-D Routes .........20
8. An Example of RT Provisioning ..................................21
8.1. Unicast Routing ...........................................21
8.2. Multicast Routing .........................................22
9. Further Refinements ............................................23
10. Security Considerations .......................................23
11. Acknowledgements ..............................................23
12. References ....................................................24
12.1. Normative References .....................................24
12.2. Informative References ...................................24
With BGP/MPLS VPNs [RFC4364], providing any-to-any connectivity among sites of a given VPN is usually accomplished by requiring each Provider Edge (PE) router connected to one or more of these sites to hold all that VPN's routes. The approach described in this document allows the VPN service provider (SP) to reduce the number of PEs that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
使用BGP/MPLS VPN[RFC4364]，在给定VPN的站点之间提供任意对任意连接通常是通过要求连接到一个或多个这些站点的每个提供商边缘（PE）路由器持有该VPN的所有路由来实现的。本文档中描述的方法允许VPN服务提供商（SP）通过只需要这些路由器的一个子集来维护所有这些路由，从而减少必须维护所有这些路由的PE的数量。
Consider a set of PEs that maintain VPN Routing and Forwarding tables (VRFs) of a given VPN. In the context of this VPN, we designate a subset of these PEs as "Virtual Spoke" PEs (or just Virtual Spokes), while some other (non-overlapping) subset of these PEs will be "Virtual Hub" PEs (or just Virtual Hubs). The rest of the PEs in the set will be "vanilla" PEs (PEs that implement the procedures described in [RFC4364] but that do not implement the procedures specified in this document).
考虑一组保持给定VPN的VPN路由和转发表（VRFS）的PES。在该VPN的上下文中，我们将这些PE的一个子集指定为“虚拟辐条”PE（或仅虚拟辐条），而这些PE的一些其他（非重叠）子集将是“虚拟集线器”PE（或仅虚拟集线器）。集合中的其他PEs将为“普通”PEs（实施[RFC4364]中所述程序但不实施本文件中规定程序的PEs）。
For the sake of brevity, we will use the term "V-hub" to denote a Virtual Hub and "V-spoke" to denote a Virtual Spoke.
为了简洁起见，我们将使用术语“V-hub”表示虚拟中心，“V-spoke”表示虚拟分支。
For a given VPN, its set of V-hubs may include not only the PEs that have sites of that VPN connected to them but also PEs that have no sites of that VPN connected to them. On such PEs, the VRF associated with that VPN may import routes from other VRFs of that VPN, even if the VRF has no sites of that VPN connected to it.
对于给定的VPN，其V-Hub集可能不仅包括连接了该VPN站点的PE，还包括没有连接该VPN站点的PE。在此类PE上，与该VPN相关联的VRF可以从该VPN的其他VRF导入路由，即使VRF没有与之连接的该VPN的站点。
Note that while in the context of one VPN a given PE may act as a V-hub, in the context of another VPN, the same PE may act as a V-spoke, and vice versa. Thus, a given PE may act as a V-hub only for some, but not all, VPNs present on that PE. Likewise, a given PE may act as a V-spoke only for some, but not all, VPNs present on that PE.
请注意，在一个VPN的上下文中，给定的PE可以充当V-hub，而在另一个VPN的上下文中，相同的PE可以充当V-spoke，反之亦然。因此，给定的PE可能仅作为该PE上存在的部分而非全部VPN的V-hub。同样，给定的PE可能仅对该PE上存在的部分（而不是全部）VPN充当V形辐射。
For a given VPN, each V-spoke of that VPN is "associated" with one or more V-hubs of that VPN (one may use two V-hubs for redundancy to avoid a single point of failure). Note that a given V-hub may have no V-spokes associated with it. For more on how a V-spoke and a V-hub become "associated" with each other, see Section 3.
对于给定的VPN，该VPN的每个V形分支与该VPN的一个或多个V形集线器“关联”（可以使用两个V形集线器进行冗余以避免单点故障）。请注意，给定的V形轮毂可能没有与其关联的V形辐条。有关V形辐条和V形轮毂如何相互“关联”的更多信息，请参见第3节。
Consider a set of V-spokes that are associated with a given V-hub, V-hub-1. If one of these V-spokes is also associated with some other V-hub, V-hub-2, then other V-spokes in the set need not be associated with the same V-hub, V-hub-2, but may be associated with some other V-hubs (e.g., V-hub-3, V-hub-4, etc.).
考虑与给定的V-Hub，V-HUB-1相关的一组V型辐条。如果这些V形辐条中的一条还与其他V形轮毂、V形轮毂-2相关联，则集合中的其他V形辐条不必与相同的V形轮毂、V形轮毂-2相关联，但可能与其他一些V形轮毂（例如，V形轮毂-3、V形轮毂-4等）相关联。
This document defines a VPN-IP default route as a VPN-IP route whose VPN-IP prefix contains only a Route Distinguisher (RD) (for the definition of "VPN-IP route", see [RFC4364]).
本文档将VPN-IP默认路由定义为VPN-IP路由，其VPN-IP前缀仅包含路由识别器（RD）（有关“VPN-IP路由”的定义，请参阅[RFC4364]）。
A PE that acts as a V-hub of a given VPN maintains all routes of that VPN (such a PE imports routes from all other V-hubs and V-spokes, as well as from "vanilla" PEs of that VPN). A PE that acts as a V-spoke of a given VPN needs to maintain only the routes of that VPN that are originated by the sites of that VPN connected to that PE, plus one or more VPN-IP default routes originated by the V-hub(s) associated with that V-spoke (such a PE needs to import only VPN-IP default routes from certain V-hubs). This way, only a subset of PEs that maintain VRFs of a given VPN -- namely, only the PEs acting as V-hubs of that VPN -- has to maintain all routes of that VPN. PEs acting as V-spokes of that VPN need to maintain only a (small) subset of the routes of that VPN.
充当给定VPN的V-hub的PE维护该VPN的所有路由（此类PE从该VPN的所有其他V-hub和V-Spoke以及“普通”PE导入路由）。充当给定VPN V辐的PE只需要维护由连接到该PE的该VPN的站点发起的该VPN的路由，加上由与该V辐关联的V辐中心发起的一个或多个VPN-IP默认路由（这样的PE只需要从某些V辐中心导入VPN-IP默认路由）。这样，只有维护给定VPN的VRF的PEs子集——即，只有充当该VPN的V-集线器的PEs——必须维护该VPN的所有路由。充当该VPN的V形辐条的PE只需要维护该VPN路由的一（小）个子集。
This document assumes that a given V-hub and its associated V-spoke(s) are in the same Autonomous System (AS). However, if PEs that maintain a given VPN's VRFs span multiple ASes, this document does not restrict all V-hubs of that VPN to be in the same AS -- the V-hubs may be spread among these ASes.
本文档假设给定的V-hub及其相关的V-spoke位于同一自治系统（AS）中。但是，如果维护给定VPN的VRF的PE跨越多个ASE，则本文档不限制该VPN的所有V-Hub位于同一位置——V-Hub可能分布在这些ASE之间。
One could model the approach defined in this document as a two-level hierarchy, where the top level consists of V-hubs and the bottom level consists of V-spokes. Generalization of this approach to more than two levels of hierarchy is outside the scope of this document.
可以将本文档中定义的方法建模为两级层次结构，其中顶层由V形轮毂组成，底层由V形辐条组成。将此方法推广到两个以上的层次结构超出了本文档的范围。
When PEs use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among the PEs. This is because a PE that acts as a V-spoke of a given VPN would need to replicate multicast traffic only to other V-hubs (while other V-hubs would replicate this traffic to the V-spokes associated with these V-hubs), rather than to all PEs of that VPN. Likewise, a PE that acts as a V-hub of a given VPN would need to replicate multicast traffic to other V-hubs and the V-spokes, but only the V-spokes associated with that V-hub, rather than replicating the traffic to all PEs of that VPN. Limiting replication could be especially beneficial if the V-spoke PEs have limited replication capabilities and/or have links with limited bandwidth.
当PEs使用入口复制来承载VPN客户的多播流量时，在某些情况下，本文档中描述的方法可能会降低与入口复制相关的带宽效率，并在PEs之间重新分配复制负载。这是因为充当给定VPN的V形辐条的PE将只需要将多播通信复制到其他V形集线器（而其他V形集线器将此通信复制到与这些V形集线器关联的V形辐条），而不是复制到该VPN的所有PE。类似地，充当给定VPN的V-hub的PE需要将多播流量复制到其他V-hub和V-Spoke，但只复制与该V-hub关联的V-Spoke，而不是将流量复制到该VPN的所有PE。如果V-spoke PE具有有限的复制能力和/或具有有限带宽的链路，则限制复制可能特别有益。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Routing information exchange among all PEs of a given VPN is subject to the following rules.
给定VPN的所有PE之间的路由信息交换遵循以下规则。
A PE that has sites of a given VPN connected to it has to retain routing information received from these sites, irrespective of whether this PE acts as a V-hub or a V-spoke of that VPN and follows the rules specified in [RFC4364].
具有连接到其上的给定VPN站点的PE必须保留从这些站点接收的路由信息，无论该PE是充当该VPN的V-hub还是V-spoke，并遵循[RFC4364]中指定的规则。
A PE that has sites of a given VPN connected to it follows the rules specified in [RFC4364] when exporting (as VPN-IP routes) the routes received from these sites, irrespective of whether this PE acts as a V-hub or a V-spoke of that VPN.
当导出（作为VPN-IP路由）从这些站点接收的路由时，具有连接到其上的给定VPN站点的PE遵循[RFC4364]中指定的规则，无论该PE是作为该VPN的V-hub还是V-spoke。
In addition, a V-hub of a given VPN MUST export a VPN-IP default route for that VPN. This route MUST be exported to only the V-spokes of that VPN that are associated with that V-hub.
此外，给定VPN的V-hub必须导出该VPN的VPN-IP默认路由。此路由必须仅导出到与该V-hub关联的VPN的V-Spoke。
To enable a given VPN's V-spoke to share its outbound traffic load among the V-hubs associated with that V-spoke, each of the VPN's V-hubs MUST use a distinct RD (per V-hub, per VPN) when originating a VPN-IP default route. The use of Type 1 RDs may be an attractive option for such RDs.
要使给定VPN的V-spoke在与该V-spoke关联的V-hub之间共享其出站流量负载，每个VPN的V-hub在发起VPN-IP默认路由时必须使用不同的RD（每个V-hub，每个VPN）。对于此类RD，使用类型1 RD可能是一个有吸引力的选择。
If a V-spoke imports several VPN-IP default routes, each originated by its own V-hub, and these routes have the same preference, then traffic from the V-spoke to other sites of that VPN would be load shared among the V-hubs.
如果一个V-spoke导入多个VPN-IP默认路由，每个路由由其自己的V-hub发起，并且这些路由具有相同的首选项，则从V-spoke到该VPN的其他站点的流量将在V-hub之间进行负载共享。
Following the rules specified in [RFC4364], a V-hub of a given VPN imports all the non-default VPN-IP routes originated by all other PEs that have sites of that VPN connected to them (irrespective of whether these other PEs act as V-hubs or V-spokes or just "vanilla" PEs for that VPN, and irrespective of whether or not these V-spokes are associated with the V-hub).
按照[RFC4364]中规定的规则，给定VPN的V-hub导入所有由所有其他PE发起的非默认VPN-IP路由，这些PE的站点连接到该VPN（无论这些其他PE是充当V-hub还是V-Spoke还是“普通”）用于该VPN的PEs，无论这些V形辐条是否与V形集线器关联）。
A V-hub of a given VPN MUST NOT import a VPN-IP default route unless the imported route is the Internet VPN-IP default route (for the definition of "Internet VPN-IP default route" and information on how to distinguish between a VPN-IP default route and the Internet VPN-IP default route, see Section 5).
给定VPN的V-hub不得导入VPN-IP默认路由，除非导入的路由是Internet VPN-IP默认路由（有关“Internet VPN-IP默认路由”的定义以及如何区分VPN-IP默认路由和Internet VPN-IP默认路由的信息，请参阅第5节）。
Within a given VPN, a V-spoke MUST import all VPN-IP default routes that have been originated by the V-hubs associated with that V-spoke.
在给定的VPN中，V-spoke必须导入与该V-spoke关联的V-Hub发起的所有VPN-IP默认路由。
In addition, a V-spoke of a given VPN MAY import VPN-IP routes for that VPN that have been originated by some other V-spokes of that VPN, but only by the V-spokes that are associated with the same V-hub(s) as the V-spoke itself.
此外，给定VPN的V辐条可以为该VPN导入由该VPN的某些其他V辐条发起的VPN-IP路由，但仅由与V辐条本身相同的V-hub关联的V辐条发起。
The above rules are realized by using Route Target (RT) extended communities [RFC4360] and VRF export/import policies based on these RTs. This document defines the following procedures for implementing the above rules.
上述规则是通过使用路由目标（RT）扩展社区[RFC4360]和基于这些RTs的VRF导出/导入策略实现的。本文件规定了执行上述规则的以下程序。
Consider a "vanilla" any-to-any VPN. This document assumes that all the PEs of that VPN (or to be more precise, all VRFs of that VPN) are provisioned with the same export and import RT -- we will refer to this RT as "RT-VPN" (of course, for a given VPN service provider, each VPN would use its own RT-VPN, distinct from RT-VPNs used by other VPNs).
考虑到任何VPN的“香草”。本文档假设该VPN的所有PE（或者更准确地说，该VPN的所有VRF）都配置了相同的导出和导入RT——我们将此RT称为“RT-VPN”（当然，对于给定的VPN服务提供商，每个VPN将使用其自己的RT-VPN，不同于其他VPN使用的RT-VPN）。
To evolve this VPN into V-hubs and V-spokes, all PEs (or to be more precise, all VRFs) that are designated as either V-hubs or V-spokes of that VPN keep the same export RT-VPN. This RT-VPN is attached to all VPN-IP routes originated by these PEs. Also, all the V-hubs keep the same import RT-VPN.
要将此VPN发展为V集线器和V辐条，指定为该VPN的V集线器或V辐条的所有PE（或更准确地说，所有VRF）保持相同的导出RT-VPN。此RT-VPN连接到这些PE发起的所有VPN-IP路由。此外，所有V-Hub保持相同的导入RT-VPN。
In addition, each of a given VPN's V-hubs is provisioned with its own export RT, called RT-VH. This RT-VH MUST be different from the export RT (RT-VPN) provisioned on that V-hub. Furthermore, for a given VPN service provider, no two VPNs can use the same RT-VH.
此外，每个给定VPN的V-Hub都配置了自己的导出RT，称为RT-VH。此RT-VH必须不同于在该V-hub上配置的导出RT（RT-VPN）。此外，对于给定的VPN服务提供商，没有两个VPN可以使用相同的RT-VH。
A given V-spoke becomes associated with a given V-hub by virtue of provisioning the V-spoke to import only the VPN-IP route(s) that carry RT-VH provisioned on the V-hub (thus, associating a new V-spoke with a given V-hub requires provisioning only on that V-spoke -- no provisioning changes are required on the V-hub).
通过设置V-spoke以仅导入承载在V-hub上设置的RT-VH的VPN-IP路由，给定的V-spoke与给定的V-hub关联（因此，将新的V-spoke与给定的V-hub关联只需要在该V-spoke上设置—在V-hub上不需要设置更改）。
To avoid the situation where within a given VPN all the V-spokes would be associated with every V-hub (in other words, to partition V-spokes among V-hubs), different V-hubs within that VPN MAY use different RT-VHs. At one extreme, every V-hub may use a distinct RT-VH. The use of IP-address-specific RTs may be an attractive option for this scenario. However, it is also possible for several V-hubs to use the same RT-VH, in which case all of these V-hubs would be associated with the same set of V-spokes.
为了避免在给定VPN内所有V形辐条都与每个V形集线器关联的情况（换句话说，在V形集线器之间划分V形辐条），该VPN内的不同V形集线器可以使用不同的RT VHs。在一个极端情况下，每个V-hub可以使用不同的RT-VH。在这种情况下，使用IP地址特定的RTs可能是一个有吸引力的选择。然而，多个V型毂也可能使用相同的RT-VH，在这种情况下，所有这些V型毂都将与同一组V型辐条相关联。
When a V-hub originates a (non-Internet) VPN-IP default route, the V-hub MUST attach RT-VH to that route (the case where a V-hub originates the Internet VPN-IP default route is covered in Section 5). Thus, this route is imported by all V-spokes associated with the V-hub.
当V-hub发起（非互联网）VPN-IP默认路由时，V-hub必须将RT-VH连接到该路由（第5节介绍了V-hub发起互联网VPN-IP默认路由的情况）。因此，该路线由与V-hub关联的所有V形辐条导入。
A V-spoke MAY be provisioned to export VPN-IP routes not just to the V-hubs but also to the V-spokes that import the same VPN-IP default route(s) as the V-spoke itself. The V-spoke accomplishes this by adding its import RT-VH(s) to the VPN-IP routes exported by the V-spoke.
可以设置V-spoke，以便不仅将VPN-IP路由导出到V-hub，还导出到导入与V-spoke本身相同的VPN-IP默认路由的V-spoke。V-spoke通过将其导入RT-VH添加到V-spoke导出的VPN-IP路由来实现这一点。
This section describes changes/modifications to the forwarding procedures specified in [RFC4364].
本节描述了[RFC4364]中规定的转发程序的更改/修改。
For a given VPN, the MPLS label that a V-hub of that VPN advertises with a VPN-IP default route MUST be the label that is mapped to a Next Hop Label Forwarding Entry (NHLFE) that identifies the VRF of the V-hub. As a result, when the V-hub receives a packet that carries such a label, the V-hub pops the label and determines further disposition of the packet based on the lookup in the VRF.
对于给定的VPN，该VPN的V-hub使用VPN-IP默认路由播发的MPLS标签必须是映射到标识V-hub的VRF的下一跳标签转发条目（NHLFE）的标签。结果，当V-hub接收到携带这样的标签的分组时，V-hub弹出标签并基于VRF中的查找确定分组的进一步处置。
Note that this document does not require the advertisement of labels mapped to an NHLFE that identifies a VRF for routes other than the VPN-IP default route.
请注意，本文件不要求公布映射到NHLFE的标签，NHLFE标识除VPN-IP默认路由以外的路由的VRF。
When a V-hub of a given VPN originates a VPN-IP default route for that VPN, the V-hub MUST NOT install in its VRF of that VPN a default route, unless that route has been originated as a result of
当给定VPN的V-hub为该VPN发起VPN-IP默认路由时，V-hub不得在该VPN的VRF中安装默认路由，除非该路由是由于以下原因而发起的：
a) the V-hub receiving an IP default route from one of the VPN Customer Edge (CE) routers connected to it, or
a) V-hub从与其连接的VPN客户边缘（CE）路由器之一接收IP默认路由，或
b) the V-hub receiving (and importing) the Internet VPN-IP default route (Section 5) from some other PE, or
b) V-hub从其他PE接收（并导入）Internet VPN-IP默认路由（第5节），或
c) the VRF being provisioned with a default route pointing to the routing table that maintains the Internet routes.
c) 为VRF提供指向维护Internet路由的路由表的默认路由。
When a multihomed site is connected to a V-hub and a V-spoke, then the V-hub uses the following OPTIONAL procedures to support Internal BGP (IBGP) / External BGP (EBGP) load balancing for the site's inbound traffic that has been originated by some other V-spoke associated with the V-hub. When the V-hub receives from some other PE a packet that carries an MPLS label that the V-hub advertised in the VPN-IP default route, then the V-hub uses the label to identify the VRF that should be used for further disposition of the packet. If (using the information present in the VRF) the V-hub determines that the packet has to be forwarded using a non-default route present in the VRF, and this route indicates that the packet's destination is reachable either over one of the VRF attachment circuits (for the definition of "VRF attachment circuits", see [RFC4364]) or via some
当多宿站点连接到V-hub和V-spoke时，V-hub使用以下可选过程来支持站点的入站流量的内部BGP（IBGP）/外部BGP（EBGP）负载平衡，该流量由与V-hub关联的其他V-spoke发起。当V-hub从某个其他PE接收到一个数据包，该数据包带有V-hub在VPN-IP默认路由中公布的MPLS标签，则V-hub使用该标签来标识应用于进一步处置该数据包的VRF。如果（使用VRF中存在的信息）V-hub确定必须使用VRF中存在的非默认路由转发数据包，并且该路由指示数据包的目的地可以通过其中一个VRF连接电路（有关“VRF连接电路”的定义，请参阅[RFC4364]）或通过一些
other (V-spoke) PE, the V-hub forwards the packet either over this attachment circuit or via that other PE. The choice between the two is a local matter to the V-hub.
其他（V辐）PE，V-hub通过该连接电路或通过该其他PE转发数据包。两者之间的选择是V-hub的本地事务。
To illustrate this, consider the following example:
为了说明这一点，考虑下面的例子：
<- RD:0/0 RD:0/0->
<- RD:0/0 RD:0/0->
<- RD:192.0.2 <-192.0.2/24
CE1----PE-S-------------PE-H----------------PE-S1-------------CE2
/
| |
| | 192.0.2/24
| |
CE4 CE3
<- RD:192.0.2 <-192.0.2/24
CE1----PE-S-------------PE-H----------------PE-S1-------------CE2
/
| |
| | 192.0.2/24
| |
CE4 CE3
A multihomed site (not shown in the above figure) is connected via CE2 and CE3. Thus, both CE2 and CE3 advertise a route to 192.0.2/24. CE2 advertises this route (route to 192.0.2/24) to PE-S1, which in turn originates a VPN-IP route RD:192.0.2. CE3 advertises this route to PE-H.
多宿站点（上图中未显示）通过CE2和CE3连接。因此，CE2和CE3都宣传到192.0.2/24的路由。CE2向PE-S1播发该路由（到192.0.2/24的路由），PE-S1进而发起VPN-IP路由RD:192.0.2。CE3向PE-H宣传这条路线。
PE-H is a V-hub, while PE-S and PE-S1 are V-spokes associated with that V-hub. Thus, PE-H originates a VPN-IP default route (RD:0/0), and both PE-S and PE-S1 import that route.
PE-H是V形轮毂，而PE-S和PE-S1是与该V形轮毂关联的V形辐条。因此，PE-H发起一个VPN-IP默认路由（RD:0/0），并且PE-S和PE-S1都导入该路由。
PE-H receives from PE-S1 a VPN-IP route to RD:192.0.2 and from CE3 a plain IP route to 192.0.2. Thus, the VRF entry on PE-H has two possible next hops for 192.0.2: CE3 and PE-S1 (the latter is a next hop that is not directly connected to PE-H).
PE-H从PE-S1接收到通向RD:192.0.2的VPN-IP路由，从CE3接收到通向192.0.2的普通IP路由。因此，PE-H上的VRF条目对于192.0.2有两个可能的下一跳：CE3和PE-S1（后者是不直接连接到PE-H的下一跳）。
Now consider what happens when CE1 originates a packet destined to 192.0.2.1. When PE-S receives this packet, PE-S (following the VPN-IP default route) forwards the packet to PE-H. The MPLS label in the packet is the label that PE-H advertised to PE-S in the VPN-IP default route. Thus, following the rule specified above, PE-H may forward the packet either via CE3 or via PE-S1 (with PE-S1 subsequently forwarding the packet to CE2), resulting in IBGP/EBGP load balancing.
现在考虑当CE1起源于192.0.2.1的分组时会发生什么。当PE-S收到此数据包时，PE-S（遵循VPN-IP默认路由）将数据包转发给PE-H。数据包中的MPLS标签是PE-H在VPN-IP默认路由中向PE-S播发的标签。因此，遵循上面指定的规则，PE-H可以经由CE3或PE-S1转发分组（PE-S1随后将分组转发到CE2），从而实现IBGP/EBGP负载平衡。
Likewise, if CE4 originates a packet destined to 192.0.2.1, PE-H may forward the packet either via CE3 or via PE-S1 (with PE-S1 subsequently forwarding the traffic to CE2), resulting in IBGP/EBGP load balancing.
同样，如果CE4发起一个目的地为192.0.2.1的数据包，则PE-H可以通过CE3或PE-S1转发该数据包（PE-S1随后将流量转发给CE2），从而实现IBGP/EBGP负载平衡。
Note, however, that if there is some other CE, CE5, connected to PE-S1, and CE5 sends a packet to 192.0.2.1, then (due to the IP longest match rule) PE-S1 will always forward this packet to CE2.
然而，请注意，如果有一些其他CE CE5连接到PE-S1，并且CE5将数据包发送到192.0.2.1，那么（由于IP最长匹配规则），PE-S1将始终将该数据包转发到CE2。
Thus, for a multihomed site connected to a V-hub and a V-spoke, IBGP/EBGP load balancing will be available for some but not all the traffic destined to that site. Specifically, IBGP/EBGP load balancing will not be available for the traffic destined to that site if this traffic has been originated within some other site that is connected to the same V-spoke.
因此，对于连接到V-hub和V-spoke的多宿站点，IBGP/EBGP负载平衡将可用于某些但不是所有发送到该站点的流量。具体来说，如果该流量是在连接到同一V形分支的其他站点内产生的，则IBGP/EBGP负载平衡将不适用于发送到该站点的流量。
Moreover, if CE3 advertises 192.0.2.0/25 and 192.0.2/24, while CE2 advertises 192.0.2.128/25 and 192.0.2/24 (which is yet another form of load balancing for a multihomed site), when CE5 sends a packet to 192.0.2.1, then (due to the IP longest match rule) PE-S1 will always forward this packet to CE2, even though the VPN customer would expect this traffic to flow via CE3.
此外，如果CE3播发192.0.2.0/25和192.0.2/24，而CE2播发192.0.2.128/25和192.0.2/24（这是多宿站点的另一种负载平衡形式），那么当CE5将数据包发送到192.0.2.1时（由于IP最长匹配规则），PE-S1将始终将该数据包转发给CE2，即使VPN客户希望该流量通过CE3。
This document proposes two options to address the issues raised in the previous two paragraphs. The first option is to disallow a given VPN to provision PEs that have multihomed sites of that VPN connected to them as V-spokes (such PEs could be provisioned as either V-hubs or plain "vanilla" PEs). The second option is for the V-spoke, when it receives an IP route from a CE, to not install this route in its forwarding table but just re-advertise this route as a VPN-IP route, together with an MPLS label. The NHLFE [RFC3031] associated with that label MUST specify the CE that advertises the IP route as the next hop. As a result, when the PE receives data that carries that label, the PE just forwards the data to the CE without performing an IP lookup on the data. Note that doing this would result in forcing the traffic between a pair of sites connected to the same V-spoke to go through the V-hub of that V-spoke.
本文件提出了两个备选方案，以解决前两段中提出的问题。第一种选择是，不允许给定的VPN提供将该VPN的多宿站点作为V形辐条连接到它们的PE（此类PE可以提供为V形集线器或普通的“普通”PE）。第二个选项是，当V-spoke从CE接收到IP路由时，不在其转发表中安装此路由，而只是将此路由与MPLS标签一起重新公布为VPN-IP路由。与该标签关联的NHLFE[RFC3031]必须指定作为下一跳播发IP路由的CE。因此，当PE接收到带有该标签的数据时，PE只将数据转发给CE，而不对数据执行IP查找。请注意，这样做将导致连接到同一个V形分支的一对站点之间的流量通过该V形分支的V形中心。
An implementation that supports IBGP/EBGP load balancing, as specified above, SHOULD support the second option. If the implementation does not support the second option, then deploying this implementation to support IBGP/EBGP load balancing, as specified above, would either (a) restrict the set of PEs that could be provisioned as V-spokes (any PE that has a multihomed site connected to it cannot be provisioned as a V-spoke) or (b) result in IBGP/EBGP load balancing not being available for certain scenarios (the scenarios that the second option is intended to cover).
如上所述，支持IBGP/EBGP负载平衡的实现应该支持第二个选项。如果该实现不支持第二个选项，那么部署此实现以支持IBGP/EBGP负载平衡（如上所述）将（a）限制可以设置为V形分支的PE集（任何连接有多宿站点的PE都不能设置为V形分支）或（b）导致IBGP/EBGP负载平衡不适用于某些场景（第二个选项打算涵盖的场景）。
This document specifies two possible alternatives for providing Internet connectivity for a given VPN.
本文档指定了为给定VPN提供Internet连接的两种可能的备选方案。
The first alternative is when a PE that maintains Internet routes also maintains a VRF of a given VPN. In this case, the Internet connectivity for that VPN MAY be provided by provisioning a default route in the VPN's VRF on that PE pointing to the routing table on
第一种选择是，维护Internet路由的PE也维护给定VPN的VRF。在这种情况下，可以通过在该PE上的VPN的VRF中提供指向该PE上的路由表的默认路由来提供该VPN的Internet连接
that PE that maintains the Internet routes. This PE MUST NOT be provisioned as a V-spoke for that VPN (this PE may be provisioned as either a V-hub or a "vanilla" PE). If this PE is provisioned as a V-hub, then this PE MUST originate a VPN-IP default route. The route MUST carry both RT-VPN and RT-VH of the V-hub (see Section 3 for the definitions of "RT-VPN" and "RT-VH"). Thus, this route will be imported by all the V-spokes associated with the V-hub, as well as by other V-hubs and "vanilla" PEs. An implementation MUST support the first alternative.
维护互联网路由的PE。不得将此PE设置为该VPN的V-spoke（此PE可以设置为V-hub或“普通”PE）。如果此PE设置为V-hub，则此PE必须发起VPN-IP默认路由。路线必须承载V-hub的RT-VPN和RT-VH（有关“RT-VPN”和“RT-VH”的定义，请参见第3节）。因此，该路线将由与V-hub相关的所有V型辐条以及其他V型hub和“普通”PEs导入。实现必须支持第一个备选方案。
The second alternative is when a site of a given VPN has connection to the Internet, and a CE of that site advertises an IP default route to the PE connected to that CE. This alternative has two subcases: (a) the PE is provisioned as a V-hub, and (b) the PE is provisioned as a V-spoke. An implementation MUST support subcase (a). An implementation MAY support subcase (b).
第二种选择是当给定VPN的站点连接到Internet，并且该站点的CE向连接到该CE的PE播发IP默认路由时。此备选方案有两个子类别：（a）PE设置为V-hub，以及（b）PE设置为V-spoke。实现必须支持子类（a）。一个实现可以支持子类（b）。
If a PE is provisioned as a V-hub, then the PE re-advertises this IP default route as a VPN-IP default route and installs in its VRF an IP default route with the next hop specifying the CE(s) that advertise the IP default route to the PE. Note that when re-advertising the VPN-IP default route, the route MUST carry both RT-VPN and RT-VH of the V-hub (see Section 3 for the definitions of "RT-VPN" and "RT-VH"). Thus, this route will be imported by all the V-spokes associated with the V-hub, as well as by other V-hubs and "vanilla" PEs.
如果PE配置为V-hub，则PE将此IP默认路由作为VPN-IP默认路由重新播发，并在其VRF中安装IP默认路由，下一跳指定向PE播发IP默认路由的CE。请注意，当重新公布VPN-IP默认路由时，该路由必须同时承载V-hub的RT-VPN和RT-VH（有关“RT-VPN”和“RT-VH”的定义，请参见第3节）。因此，该路线将由与V-hub相关的所有V型辐条以及其他V型hub和“普通”PEs导入。
If a PE is provisioned as a V-spoke, then receiving a default route from a CE MUST NOT cause the V-spoke to install an IP default route in its VRF. The V-spoke MUST originate a VPN-IP default route with a (non-null) MPLS label. The route MUST carry only RT-VPN (as a result, this route is not imported by any of the V-spokes but is imported by V-hubs). The packet's next hop of the NHLFE [RFC3031] associated with that label MUST specify the CE that advertises the IP default route. As a result, when the V-spoke receives data that carries that label, it just forwards the data to the CE without performing an IP lookup on the data. Note that in this case, the VRF on the V-spoke will have an IP default route, but this route would be created as a result of receiving a VPN-IP default route from one of the V-hubs associated with that V-spoke (and not as a result of receiving the IP default route from the CE). Note also that if this V-spoke has other sites of that VPN connected to it, then traffic from these sites to the Internet would go to that V-spoke, then to the V-hub selected by the V-spoke, then from that V-hub back to the V-spoke, and then to the CE that advertises an IP default route to the V-spoke.
如果PE设置为V-spoke，则从CE接收默认路由不得导致V-spoke在其VRF中安装IP默认路由。V-spoke必须使用（非空）MPLS标签发起VPN-IP默认路由。该路由必须仅承载RT-VPN（因此，该路由不是由任何V形辐条导入的，而是由V形集线器导入的）。与该标签关联的NHLFE[RFC3031]数据包的下一跳必须指定播发IP默认路由的CE。因此，当V-spoke接收到带有该标签的数据时，它只将数据转发给CE，而不对数据执行IP查找。请注意，在这种情况下，V-spoke上的VRF将具有IP默认路由，但该路由将作为从与该V-spoke关联的其中一个V-hub接收VPN-IP默认路由的结果而创建（而不是作为从CE接收IP默认路由的结果）。还请注意，如果此V-spoke有该VPN的其他站点连接到它，则从这些站点到Internet的流量将转到该V-spoke，然后转到由该V-spoke选择的V-hub，然后从该V-hub返回到该V-spoke，然后转到向该V-spoke播发IP默认路由的CE。
If a PE is provisioned as a V-spoke of a given VPN, and if a CE of that VPN advertises an IP default route to the PE (as the CE belongs to the site that provides the Internet connectivity for the VPN), then the PE MUST NOT advertise an IP default route back to that CE. Yet, the CE has to specify that PE as the next hop for all the traffic to other sites of that VPN. A way to accomplish this is to require the V-spoke to implement procedures specified in Section 9.
如果PE被设置为给定VPN的V形分支，并且如果该VPN的CE向PE播发IP默认路由（因为CE属于为VPN提供Internet连接的站点），则PE不得向该CE播发IP默认路由。然而，CE必须将PE指定为该VPN其他站点的所有流量的下一跳。实现这一点的一种方法是要求V形辐条执行第9节中规定的程序。
In all the scenarios described above in this section, we refer to the originated VPN-IP default route as the "Internet VPN-IP default route". Specifically, the Internet VPN-IP default route is a VPN-IP default route originated by a PE (this PE could be either a V-hub or a V-spoke) as a result of (a) receiving an IP default route from a CE or (b) the PE maintaining Internet routes and also provisioning in the VRF of its VPN a default route pointing to its (the PE's) routing table that contains Internet routes.
在本节上述所有场景中，我们将原始VPN-IP默认路由称为“Internet VPN-IP默认路由”。具体而言，Internet VPN-IP默认路由是由PE发起的VPN-IP默认路由（此PE可以是V-hub或V-spoke），其结果是（a）从CE接收IP默认路由，或（b）PE维护Internet路由，并在其VPN的VRF中提供指向其（PE）的默认路由包含Internet路由的路由表。
The difference between the Internet VPN-IP default route and a non-Internet VPN-IP default route originated by a V-hub is in the RTs carried by the route -- for a given VPN and a given V-hub of that VPN, the Internet VPN-IP default route carries both RT-VPN and RT-VH of that V-hub, while the non-Internet VPN-IP default route carries just RT-VH of that V-hub.
Internet VPN-IP默认路由和由V-hub发起的非Internet VPN-IP默认路由之间的区别在于路由承载的RTs——对于该VPN的给定VPN和给定V-hub，Internet VPN-IP默认路由承载该V-hub的RT-VPN和RT-VH，而非Internet VPN-IP默认路由仅承载该V-hub的RT-VH。
When a V-hub originates the Internet VPN-IP default route, the V-hub MUST withdraw the non-Internet VPN-IP default route that has been originated by the V-hub. When a V-hub withdraws the Internet VPN-IP default route that has been originated by the V-hub, the V-hub MUST originate a non-Internet VPN-IP default route. That is, at any given point in time, a given V-hub originates either the Internet VPN-IP default route or a non-Internet VPN-IP default route.
当V-hub发起Internet VPN-IP默认路由时，V-hub必须撤回由V-hub发起的非Internet VPN-IP默认路由。当V-hub撤回由V-hub发起的Internet VPN-IP默认路由时，V-hub必须发起非Internet VPN-IP默认路由。也就是说，在任何给定的时间点，给定的V-hub发起Internet VPN-IP默认路由或非Internet VPN-IP默认路由。
As a result of the rules specified above, if a V-hub originates the Internet VPN-IP default route, then all the V-spokes associated with that V-hub MUST import that route. In addition (and in contrast with a non-Internet VPN-IP default route), other V-hubs MAY import that route. A V-hub MAY also import the Internet VPN-IP default routes originated by V-spoke(s). A V-spoke MUST NOT import the Internet VPN-IP default route originated by any other V-spoke. Such a route MAY be imported only by V-hubs.
根据上述规则，如果V-hub发起Internet VPN-IP默认路由，则与该V-hub关联的所有V形辐条都必须导入该路由。此外（与非Internet VPN-IP默认路由相反），其他V-Hub可以导入该路由。V-hub还可以导入由V-spoke发起的Internet VPN-IP默认路由。V-spoke不得导入由任何其他V-spoke发起的Internet VPN-IP默认路由。此类路线只能由V型枢纽导入。
If the Internet VPN-IP default route originated by a V-hub has the same preference as the (non-Internet) VPN-IP default route originated by some other V-hub, then a V-spoke that imports VPN-IP default routes originated by both of these V-hubs would load share the outgoing Internet traffic between these two V-hubs (and thus some of the outgoing Internet traffic from that V-spoke will first be routed
如果由V-hub发起的Internet VPN-IP默认路由与由其他V-hub发起的（非Internet）VPN-IP默认路由具有相同的首选项，则导入由这两个V-hub发起的VPN-IP默认路由的V-spoke将在这两个V-hub之间负载共享传出Internet流量（因此，来自该V型分支的一些传出互联网流量将首先被路由
to the V-hub that does not originate the Internet VPN-IP default route, then from that V-hub to the V-hub that does originate the Internet VPN-IP default route).
到不发起Internet VPN-IP默认路由的V-hub，然后从该V-hub到发起Internet VPN-IP默认路由的V-hub）。
If taking an extra-hub hop for the Internet traffic is viewed as undesirable, then it is RECOMMENDED that the Internet VPN-IP default route be of higher preference than a (non-Internet) VPN-IP default route originated by some other V-hub. However, in this case the traffic from the V-spokes to other sites of that VPN will not be load shared between these two V-hubs.
如果认为不需要为Internet流量进行额外的集线器跳跃，则建议Internet VPN-IP默认路由优先于由其他V-hub发起的（非Internet）VPN-IP默认路由。但是，在这种情况下，从V形辐条到该VPN的其他站点的流量将不会在这两个V形集线器之间进行负载共享。
For a given VPN, a V-hub and a set of V-spokes associated with that V-hub should be chosen in a way that minimizes the additional network distance/latency penalty, given that VPN geographic footprint.
对于给定的VPN，应选择一个V-hub和一组与该V-hub相关联的V-Spoke，以使附加的网络距离/延迟损失最小化，同时考虑到VPN的地理位置。
For a given VPN, some or all of its V-spokes could be grouped into geographically based clusters (e.g., V-spokes within a given cluster could be in close geographical proximity to each other) with any-to-any connectivity within each cluster. Note that the V-spokes within a given cluster need not be associated with the same V-hub(s). Likewise, not all V-spokes associated with a given V-hub need to be in the same cluster. A use case for this would be a VPN for a large retail chain in which data traffic is hub/spoke between each store and centralized datacenters, but there is a need for direct Voice over IP (VoIP) traffic between stores within the same geographical area.
对于给定的VPN，其部分或全部V形辐条可以分组到基于地理的集群中（例如，给定集群中的V形辐条可以在地理上彼此非常接近），每个集群中具有任意对任意连接。请注意，给定簇内的V形辐条不必与相同的V形轮毂关联。同样，并非所有与给定V形轮毂关联的V形辐条都需要位于同一簇中。这方面的一个使用案例是大型零售链的VPN，其中数据流量是每个商店和集中数据中心之间的中心/分支，但在同一地理区域内的商店之间需要直接IP语音（VoIP）流量。
The use of constrained route distribution for BGP/MPLS IP VPNs ("RT constrains") [RFC4684] may further facilitate/optimize routing exchange in support of V-hubs and V-spokes.
对BGP/MPLS IP VPN（“RT约束”）[RFC4684]使用受约束的路由分布可以进一步促进/优化路由交换，以支持V形集线器和V形辐条。
Introducing a V-spoke PE in a VPN may introduce the following changes for the customer of that VPN:
在VPN中引入V形辐射PE可能会为该VPN的客户带来以下更改：
+ Traceroute from a CE connected to a V-spoke may report an additional hop: the V-hub PE.
+ 来自连接到V形分支的CE的跟踪路由可能会报告额外的跃点：V形中心PE。
+ Latency for traffic sent from a CE connected to a V-spoke may increase, depending on the location of the V-hub in the layer 3 and layer 1 network topology of the SP.
+ 从连接到V-spoke的CE发送的流量的延迟可能会增加，具体取决于V-hub在SP的第3层和第1层网络拓扑中的位置。
This section describes procedures for supporting Multicast VPN (MVPN) in the presence of Virtual Hub-and-Spoke. The procedures rely on MVPN specifications as defined in [RFC6513], [RFC6514], and [RFC6625].
本节介绍在存在虚拟中心辐射的情况下支持多播VPN（MVPN）的过程。这些程序依赖于[RFC6513]、[RFC6514]和[RFC6625]中定义的MVPN规范。
The procedures assume that for the purpose of ensuring non-duplication, both V-hubs and V-spokes can discard packets from a "wrong" PE, as specified in Section 9.1.1 of [RFC6513]. The existing procedures for Selective Provider Multicast Service Interface (S-PMSI) auto-discovery (A-D) routes [RFC6513] [RFC6514] [RFC6625] are sufficient to discard packets coming from a "wrong" PE for all types of provider tunnels (P-tunnels) specified in [RFC6514] (including Ingress Replication). The existing procedures for Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes [RFC6513] [RFC6514] are sufficient to discard packets coming from a "wrong" PE for all types of P-tunnels specified in [RFC6514], except for Ingress Replication. Section 7.9 of this document specifies changes to the procedures in [RFC6514], to enable the discarding of packets from a "wrong" PE when Ingress Replication is used for I-PMSI P-tunnels.
程序假设，为了确保不重复，V型集线器和V型辐条都可以丢弃来自“错误”PE的数据包，如[RFC6513]第9.1.1节所述。选择性提供商多播服务接口（S-PMSI）自动发现（A-D）路由[RFC6513][RFC6514][RFC6625]的现有过程足以丢弃来自[RFC6514]中指定的所有类型的提供商隧道（P隧道）（包括入口复制）的“错误”PE的数据包。包含式提供商多播服务接口（I-PMSI）A-D路由[RFC6513][RFC6514]的现有过程足以丢弃来自[RFC6514]中指定的所有类型的P隧道的“错误”PE的数据包，入口复制除外。本文件第7.9节规定了[RFC6514]中程序的变更，以便在I-PMSI P隧道使用入口复制时，能够丢弃来自“错误”PE的数据包。
The V-hub/V-spoke architecture, as specified in this document, affects certain multicast scenarios. In particular, it affects multicast scenarios where the source of a multicast flow is at a site attached to a V-hub and a receiver of that flow is at a site attached to a V-spoke that is not associated with that same V-hub. It also affects multicast scenarios where the source of a multicast flow is at a site attached to a V-spoke, a receiver of that flow is at a site attached to a different V-spoke, and the set intersection between the V-hub(s) associated with the first V-spoke and the V-hub(s) associated with the second V-spoke is empty. It may also affect multicast scenarios where the source of a multicast flow is at a site connected to a V-spoke, a receiver of that flow is at a site attached to a different V-spoke, and the set intersection between the V-hub(s) associated with the first V-spoke and the V-hub(s) associated with the second V-spoke is non-empty (the multicast scenarios are affected if the I-PMSI/S-PMSI A-D routes originated by the first V-spoke are not imported by the second V-spoke).
本文档中指定的V-hub/V-spoke体系结构会影响某些多播场景。特别是，它影响多播场景，其中多播流的源位于连接到V-hub的站点，而该流的接收器位于连接到与该V-hub不关联的V-spoke的站点。它还影响多播场景，其中多播流的源位于连接到V形辐条的站点，该流的接收器位于连接到不同V形辐条的站点，并且与第一个V形辐条关联的V形集线器和与第二个V形辐条关联的V形集线器之间的集合交点为空。它还可能影响多播场景，其中多播流的源位于连接到V辐的站点，该流的接收器位于连接到不同V辐的站点，并且与第一个V辐相关联的V-hub和与第二个V辐相关联的V-hub之间的集合交点为非空（如果由第一个V辐发出的I-PMSI/S-PMSI A-D路由未由第二个V辐导入，则多播场景会受到影响）。
The use of Virtual Hub-and-Spoke in conjunction with seamless MPLS multicast [MPLS-MCAST] is outside the scope of this document.
虚拟中心辐射与无缝MPLS多播[MPLS-MCAST]的结合使用超出了本文档的范围。
We will speak of a P-tunnel being "bound" to a particular I-PMSI/S-PMSI A-D route if the P-tunnel is specified in that route's PMSI Tunnel attribute.
如果P隧道在特定I-PMSI/S-PMSI a-D路由的PMSI隧道属性中指定，我们将谈论P隧道“绑定”到该路由。
When Ingress Replication is used, the P-tunnel bound to a particular I-PMSI/S-PMSI A-D route is actually a set of unicast tunnels (procedures differ from [RFC6514] for the case of I-PMSI and are specified in Section 7.9 of this document). The PE originating the I-PMSI/S-PMSI A-D route uses these unicast tunnels to carry traffic to the PEs that import the route. The PEs that import the route advertise labels for the unicast tunnels in Leaf A-D routes originated in response to the I-PMSI/S-PMSI A-D route. When we say that traffic has been received by a PE on a P-tunnel "bound" to a particular I-PMSI/S-PMSI A-D route imported by that PE, we refer to the unicast tunnel for which the label was advertised in a Leaf A-D route by the PE that imported the I-PMSI/S-PMSI route; the PE that originated that route uses this tunnel to send traffic to the PE that imported the I-PMSI/S-PMSI route.
当使用入口复制时，绑定到特定I-PMSI/S-PMSI a-D路由的P隧道实际上是一组单播隧道（对于I-PMSI，程序不同于[RFC6514]，并在本文件第7.9节中规定）。发起I-PMSI/S-PMSI A-D路由的PE使用这些单播隧道将流量传输到导入路由的PE。为叶A-D路由中的单播隧道导入路由广告标签的PE起源于对I-PMSI/S-PMSI A-D路由的响应。当我们说PE在P隧道“绑定”到该PE导入的特定I-PMSI/S-PMSI a-D路由上接收到通信量时，我们指的是单播隧道，导入I-PMSI/S-PMSI路由的PE在叶a-D路由中为其播发标签；发起该路由的PE使用此隧道向导入I-PMSI/S-PMSI路由的PE发送流量。
On a V-spoke, the set of Eligible UMH routes consists of all the unicast VPN-IP routes received by the V-spoke, including the default VPN-IP routes received from its V-hub(s). Note that such routes MAY include routes received from other V-spokes. The routes received from other V-spokes could be either "vanilla" VPN-IP routes (routes using the IPv4 or IPv6 Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) set to 128 "MPLS-labeled VPN address" [IANA-SAFI]) or routes using the IPv4 or IPv6 AFI (as appropriate) but with the SAFI set to SAFI 129 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA-SAFI].
在V-spoke上，合格的UMH路由集由V-spoke接收的所有单播VPN-IP路由组成，包括从其V-hub接收的默认VPN-IP路由。请注意，此类路线可能包括从其他V形辐条接收的路线。从其他V形辐条接收的路由可以是“普通”VPN-IP路由（使用IPv4或IPv6地址族标识符（AFI）和后续地址族标识符（SAFI）设置为128“MPLS标记VPN地址”[IANA-SAFI]的路由），也可以是使用IPv4或IPv6 AFI（视情况而定）但SAFI设置为SAFI 129的路由“BGP/MPLS IP虚拟专用网络（VPN）的多播”[IANA-SAFI]。
The default VPN-IP routes received from the V-hub(s) may be either Internet default VPN-IP routes or non-Internet default VPN-IP routes.
从V-hub接收的默认VPN-IP路由可以是Internet默认VPN-IP路由或非Internet默认VPN-IP路由。
When originating a VPN-IP default route, a V-hub, in addition to following the procedures specified in Section 3, also follows the procedures specified in Sections 6 and 7 of [RFC6514] (see also Section 5.1 of [RFC6513]). Specifically, the V-hub MUST add the VRF Route Import Extended Community that embeds the V-hub's IP address. The route also MUST include the Source AS extended community.
当发起VPN-IP默认路由时，V-hub除了遵循第3节规定的程序外，还遵循[RFC6514]第6节和第7节规定的程序（另请参见[RFC6513]第5.1节）。具体而言，V-hub必须添加嵌入V-hub IP地址的VRF路由导入扩展社区。路由还必须包括源作为扩展社区。
In the following, the term "C-multicast routes" refers to BGP routes that carry customer multicast routing information [RFC6514].
在下文中，术语“C-多播路由”是指承载客户多播路由信息的BGP路由[RFC6514]。
Origination of C-multicast routes follows the procedures specified in [RFC6514] (irrespective of whether these routes are originated by a V-hub or a V-spoke).
C-多播路由的发起遵循[RFC6514]中规定的程序（无论这些路由是由V-hub还是V-spoke发起）。
When a V-spoke receives a C-multicast route, the V-spoke follows the procedures described in [RFC6514].
当V型分支接收到C型多播路由时，V型分支遵循[RFC6514]中描述的过程。
When a V-hub receives a C-multicast route, the V-hub determines whether the customer Rendezvous Point (C-RP) or the customer source (C-S) of the route is reachable via one of its VRF interfaces; if yes, then the V-hub follows the procedures described in [RFC6514].
当V-hub接收到C-多播路由时，V-hub确定该路由的客户集合点（C-RP）或客户源（C-S）是否可通过其VRF接口之一到达；如果是，则V型轮毂遵循[RFC6514]中所述的步骤。
Otherwise, the C-RP/C-S of the route is reachable via some other PE (this is the case where the received route was originated by a V-spoke that sees the V-hub as the "upstream PE" for a given source, but the V-hub sees some other PE -- either V-hub or V-spoke -- as the "upstream PE" for that source). In this case, the V-hub uses the type (Source Tree Join vs Shared Tree Join), the Multicast Source, and Multicast Group from the received C-multicast route to construct a new route of the same type, with the same Multicast Source and Multicast Group. The hub constructs the rest of the new route following procedures specified in Section 11.1.3 of [RFC6514]. The hub also creates the appropriate (C-*, C-G) or (C-S, C-G) state in its MVPN Tree Information Base (MVPN-TIB).
否则，该路由的C-RP/C-S可通过某个其他PE到达（这种情况下，接收的路由是由一个V形辐条发起的，该V形辐条将该V形集线器视为给定源的“上游PE”，但该V形辐条将某个其他PE（V形辐条或V形辐条）视为该源的“上游PE”）。在这种情况下，V-hub使用接收到的C-多播路由中的类型（源树连接vs共享树连接）、多播源和多播组来构造具有相同多播源和多播组的相同类型的新路由。枢纽按照[RFC6514]第11.1.3节规定的程序建造新路线的其余部分。中心还在其MVPN树信息库（MVPN-TIB）中创建适当的（C-*，C-G）或（C-S，C-G）状态。
When a V-spoke originates an I-PMSI, an S-PMSI, or Source Active (SA) A-D route, the V-spoke follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]), including the procedures for constructing RT(s) carried by the route. Note that as a result, such a route will be imported by the V-hubs. In the case of an I-PMSI/S-PMSI A-D route, the P-tunnel bound to this route is used to carry to these V-hubs traffic originated by the sites connected to the V-spoke.
当V形辐条发起I-PMSI、S-PMSI或源激活（SA）a-D路由时，V形辐条遵循[RFC6514]中指定的过程（或在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中指定的过程），包括路由所承载的RT（S）构造过程。请注意，这样的路线将由V-HUB导入。在I-PMSI/S-PMSI A-D路线的情况下，与该路线相连的P-隧道用于将连接到V-spoke的站点发起的流量传输到这些V-Hub。
If the V-spoke exports its (unicast) VPN-IP routes not just to the V-hubs but also to some other V-spokes (as described in Section 3), then (as a result of following the procedures specified in [RFC6514] or, in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]) the I-PMSI/S-PMSI/SA A-D route originated by the V-spoke will be imported not just by the V-hubs but also by the other V-spokes. This is because in this scenario, the route will
如果V-spoke将其（单播）VPN-IP路由不仅导出到V-Hub，还导出到其他一些V-spoke（如第3节所述），则（由于遵循[RFC6514]中规定的程序，或者在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中规定的程序）V型辐条产生的I-PMSI/S-PMSI/SA A-D路线将不仅由V型轮毂导入，还将由其他V型辐条导入。这是因为在这种情况下，路线将
carry more than one RT; one of these RTs, RT-VPN, will result in importing the route by the V-hubs, while other RT(s) will result in importing the route by the V-spokes (the other RT(s) are the RT(s) that the V-spoke uses for importing the VPN-IP default route). In this case, the P-tunnel bound to this I-PMSI/S-PMSI A-D route is also used to carry traffic originated by the sites connected to the V-spoke that originates the route to these other V-spokes.
携带多个RT；其中一个RTs，RT-VPN，将导致通过V-Hub导入路由，而其他RT将导致通过V-spoke导入路由（其他RT是V-spoke用于导入VPN-IP默认路由的RT）。在这种情况下，绑定到此I-PMSI/S-PMSI A-D路由的P隧道也用于将由连接到发起该路由的V辐条的站点发起的流量传输到这些其他V辐条。
When a V-hub originates an I-PMSI/S-PMSI/SA A-D route, the V-hub follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]), except that in addition to the RT(s) constructed following these procedures, the route MUST also carry the RT of the VPN-IP default route advertised by the V-hub (RT-VH). Note that as a result, such a route will be imported by other V-hubs and also by the V-spokes, but only by the V-spokes that are associated with the V-hub (the V-spokes that import the VPN-IP default route originated by the V-hub). In the case of an I-PMSI/S-PMSI A-D route, the P-tunnel bound to this route is used to carry to these other V-hubs and V-spokes the traffic originated by the sites connected to the V-hub that originates the route.
当V-hub发起I-PMSI/S-PMSI/SA a-D路由时，V-hub遵循[RFC6514]中规定的程序（或在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中规定的程序），除了按照这些程序构造的RT之外，该路由还必须携带V-hub（RT-VH）公布的VPN-IP默认路由的RT。请注意，这样的路由将由其他V-hub和V-Spoke导入，但仅由与V-hub关联的V-Spoke导入（导入由V-hub发起的VPN-IP默认路由的V-Spoke）。在I-PMSI/S-PMSI A-D路线的情况下，与该路线相连的P-隧道用于将与发起该路线的V-枢纽相连的站点产生的交通量输送至这些其他V-枢纽和V-辐条。
In addition, if a V-hub originates an I-PMSI A-D route following the procedures specified in [RFC6514], the V-hub MUST originate another I-PMSI A-D route -- we'll refer to this route as an "Associated-V-spoke-only I-PMSI A-D route". The RT carried by this route MUST be the RT that is carried in the VPN-IP default route advertised by the V-hub (RT-VH). Therefore, this route will be imported only by the V-spokes associated with the V-hub (the V-spokes that import the VPN-IP default route advertised by this V-hub). The P-tunnel bound to this route is used to carry to these V-spokes traffic originated by the sites connected to either (a) other V-hubs, (b) other V-spokes, including the V-spokes that import the VPN-IP default route from the V-hub, or (c) "vanilla" PEs.
此外，如果V-hub按照[RFC6514]中规定的程序发起I-PMSI a-D路由，则V-hub必须发起另一条I-PMSI a-D路由——我们将此路由称为“仅关联V-spoke的I-PMSI a-D路由”。此路由携带的RT必须是V-hub（RT-VH）公布的VPN-IP默认路由中携带的RT。因此，此路由将仅由与V-hub关联的V-Spoke导入（导入此V-hub播发的VPN-IP默认路由的V-Spoke）。绑定到此路由的P-tunnel用于将连接到（a）其他V-hub、（b）其他V-spoke（包括从V-hub导入VPN-IP默认路由的V-spoke）或（c）“香草”PEs的站点发起的流量传输到这些V-spoke。
More details on the use of this P-tunnel are described in Section 7.8.
第7.8节介绍了该P型隧道使用的更多详情。
As a result, a V-hub originates not one, but two I-PMSI A-D routes -- one is a "vanilla" I-PMSI A-D route and another is an Associated-V-spoke-only I-PMSI A-D route. Each of these routes MUST have a distinct RD.
因此，V-hub不是一条而是两条I-PMSI a-D路由——一条是“普通”I-PMSI a-D路由，另一条是关联的V-spoke-only I-PMSI a-D路由。这些路线中的每一条都必须有不同的RD。
When a V-hub receives traffic from one of the sites connected to the V-hub, and the V-hub determines (using some local policies) that this traffic should be transmitted using an I-PMSI, the V-hub forwards this traffic on the P-tunnel bound to the "vanilla" I-PMSI A-D route but MUST NOT forward it on the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route.
当V-hub从连接到V-hub的其中一个站点接收流量，并且V-hub确定（使用一些本地策略）该流量应使用I-PMSI传输时，V-hub在绑定到“香草”的P隧道上转发该流量I-PMSI A-D路由，但不得在绑定到相关V辐式I-PMSI A-D路由的P隧道上转发。
When a V-spoke receives an I-PMSI/S-PMSI/SA A-D route, the V-spoke follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]). As a result, a V-spoke that is associated with a given V-hub (the V-spoke that imports the VPN-IP default route originated by that V-hub) will also import I-PMSI/S-PMSI/SA A-D routes originated by that V-hub. Specifically, the V-spoke will import both the "vanilla" I-PMSI A-D route and the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub.
当V形辐条接收到I-PMSI/S-PMSI/SA a-D路由时，V形辐条遵循[RFC6514]中规定的程序（或在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中规定的程序）。因此，与给定V-hub关联的V-spoke（导入由该V-hub发起的VPN-IP默认路由的V-spoke）也将导入由该V-hub发起的I-PMSI/S-PMSI/SA a-D路由。具体而言，V-spoke将导入“普通”I-PMSI A-D路由和V-hub发起的关联的仅V-spoke I-PMSI A-D路由。
In addition, if a V-spoke imports the (unicast) VPN-IP routes originated by some other V-spokes (as described in Section 3), then the V-spoke will also import I-PMSI/S-PMSI/SA A-D routes originated by these other V-spokes.
此外，如果V辐条导入由其他V辐条发起的（单播）VPN-IP路由（如第3节所述），则V辐条还将导入由这些其他V辐条发起的I-PMSI/S-PMSI/SA a-D路由。
The following describes procedures that a V-hub MUST follow when it receives an I-PMSI/S-PMSI/SA A-D route.
以下描述了V-hub在接收I-PMSI/S-PMSI/SA a-D路由时必须遵循的步骤。
This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D route, and one of the RT(s) carried in the route is the RT that the V-hub uses for advertising its VPN-IP default route (RT-VH).
这种情况下，V-hub接收I-PMSI/S-PMSI/SA a-D路由，并且路由中携带的RT之一是V-hub用于宣传其VPN-IP默认路由（RT-VH）的RT。
In this case, the receiving route was originated either
在这种情况下，接收路由是由
+ by a V-spoke associated with the V-hub (the V-spoke that imports the VPN-IP default route originated by the V-hub), or
+ 通过与V-hub关联的V-spoke（导入由V-hub发起的VPN-IP默认路由的V-spoke），或
+ by some other V-hub that uses the same RT as the receiving V-hub for advertising the VPN-IP default route.
+ 其他V-hub使用与接收V-hub相同的RT来公布VPN-IP默认路由。
In this case, the received I-PMSI/S-PMSI/SA A-D route carries more than one RT. One of these RTs results in importing this route by the V-hubs. Another of these RTs is the RT that the V-hub uses when advertising its VPN-IP default route (RT-VH). This RT results in
在这种情况下，接收到的I-PMSI/S-PMSI/SA A-D路由承载多个RT。其中一个RT导致V-HUB导入该路由。另一种RTs是V-hub在公布其VPN-IP默认路由（RT-VH）时使用的RT。这种RT导致
importing the received I-PMSI/S-PMSI/SA A-D route by all the V-spokes associated with the V-hub (the V-spokes that import the VPN-IP default route originated by the V-hub).
通过与V-hub关联的所有V形辐条导入接收到的I-PMSI/S-PMSI/SA A-D路由（导入由V-hub发起的VPN-IP默认路由的V形辐条）。
In handling such an I-PMSI/S-PMSI/SA A-D route, the V-hub simply follows the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]).
在处理此类I-PMSI/S-PMSI/SA A-D路由时，V-hub只需遵循[RFC6514]中规定的程序（或在通配符S-PMSI A-D路由的情况下，遵循[RFC6625]中规定的程序）。
Specifically, the V-hub MUST NOT reoriginate this route as done in Case 2 below.
具体而言，V-hub不得像下面的情况2那样重新确定该路线的位置。
The following specifies the rules that the V-hub MUST follow when handling traffic that the V-hub receives on a P-tunnel bound to this I-PMSI/S-PMSI A-D route. The V-hub may forward this traffic to only the sites connected to that V-hub (forwarding this traffic to these sites follows the procedures specified in [RFC6514] or, in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]). The V-hub MUST NOT forward the traffic received on this P-tunnel to any other V-hubs or V-spokes, including the V-spokes that import the VPN-IP default route originated by the V-hub (V-spokes associated with the V-hub). Specifically, the V-hub MUST NOT forward the traffic received on the P-tunnel advertised in the received I-PMSI A-D route over the P-tunnel that the V-hub binds to its Associated-V-spoke-only I-PMSI A-D route.
以下规定了V-hub在处理V-hub在绑定到此I-PMSI/S-PMSI a-D路由的P隧道上接收的流量时必须遵循的规则。V-hub可以仅将该流量转发到连接到该V-hub的站点（将该流量转发到这些站点遵循[RFC6514]中规定的程序，或者，在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中规定的程序）。V-hub不得将在此P-tunnel上接收的流量转发到任何其他V-hub或V-Spoke，包括导入由V-hub发起的VPN-IP默认路由的V-Spoke（与V-hub关联的V-Spoke）。具体而言，V-hub不得在V-hub绑定到其关联的V-spoke-only I-PMSI A-D路由的P-tunnel上转发在接收到的I-PMSI A-D路由中公布的P-tunnel上接收的流量。
This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D route, and the route does not carry the RT that the receiving V-hub uses when advertising its VPN-IP default route (RT-VH).
这种情况下，V-hub接收I-PMSI/S-PMSI/SA a-D路由，并且该路由不携带接收V-hub在公布其VPN-IP默认路由（RT-VH）时使用的RT。
In this case, the receiving I-PMSI/S-PMSI/SA A-D route was originated by either some other V-hub or a V-spoke. The I-PMSI/S-PMSI/SA A-D route is imported by the V-hub (as well as by other V-hubs) but not by any of the V-spokes associated with the V-hub (V-spokes that import the VPN-IP default route originated by the V-hub).
在这种情况下，接收I-PMSI/S-PMSI/SA A-D路由由某个其他V-hub或V-spoke发起。I-PMSI/S-PMSI/SA A-D路由由V-hub（以及其他V-hub）导入，但不由与V-hub关联的任何V-Spoke导入（导入由V-hub发起的VPN-IP默认路由的V-Spoke）。
In this case, the V-hubs follow the procedures specified in [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]), with the following additions.
在这种情况下，V型集线器遵循[RFC6514]中规定的程序（或在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中规定的程序），并添加以下内容。
Once a V-hub accepts an I-PMSI A-D route, when the V-hub receives data on the P-tunnel bound to that I-PMSI A-D route, the V-hub follows the procedures specified in [RFC6513] and [RFC6514] to determine whether to accept the data. If the data is accepted, then the V-hub further forwards the data over the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub. Note that in deciding whether to forward the data over the P-tunnel
一旦V-hub接受I-PMSI a-D路由，当V-hub接收到绑定到该I-PMSI a-D路由的P隧道上的数据时，V-hub将遵循[RFC6513]和[RFC6514]中指定的程序来确定是否接受该数据。如果数据被接受，那么V-hub将通过绑定到V-hub发起的关联的仅V-spoke I I-PMSI A-D路由的P隧道进一步转发数据。请注意，在决定是否通过P通道转发数据时
bound to the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub, the V-hub SHOULD take into account the (multicast) state present in its MVPN-TIB that has been created as a result of receiving C-multicast routes from the V-spokes associated with the V-hub. If (using the information present in the MVPN-TIB) the V-hub determines that none of these V-spokes have receivers for the data, the V-hub SHOULD NOT forward the data over the P-tunnel bound to the Associated-V-spoke-only I-PMSI A-D route originated by the V-hub.
绑定到V-hub发起的关联的仅V-spoke I-PMSI A-D路由，V-hub应考虑其MVPN-TIB中存在的（多播）状态，该状态是从与V-hub关联的V-spoke接收C-multicast路由时创建的。如果（使用MVPN-TIB中存在的信息）V-hub确定这些V-spoke中没有数据接收器，则V-hub不应通过绑定到V-hub发起的关联的仅V-spoke I-PMSI A-D路由的P-tunnel转发数据。
Whenever a V-hub imports an S-PMSI A-D route (respectively, SA A-D route) in a VRF, the V-hub, in contrast to Case 1 above, MUST originate an S-PMSI A-D route (respectively, SA A-D route) targeted to its V-spokes. To accomplish this, the V-hub replaces the RT(s) carried in the route with the RT that the V-hub uses when originating its VPN-IP default route (RT-VH), changes the RD of the route to the RD that the V-hub uses when originating its Associated-V-spoke-only I-PMSI A-D route, and sets Next Hop to the IP address that the V-hub places in the Global Administrator field of the VRF Route Import Extended Community of the VPN-IP routes advertised by the V-hub. For S-PMSI A-D routes, the V-hub also changes the Originating Router's IP address in the MCAST-VPN NLRI (Network Layer Reachability Information) of the route to the same address as the one in the Next Hop. Moreover, before advertising the new S-PMSI A-D route, the V-hub modifies its PMSI Tunnel attribute as appropriate (e.g., by replacing the P-tunnel rooted at the originator of this route with a P-tunnel rooted at the V-hub).
每当V-hub在VRF中导入S-PMSI a-D路由（分别为SA a-D路由）时，与上述情况1不同，V-hub必须针对其V形辐条发起S-PMSI a-D路由（分别为SA a-D路由）。为此，V-hub将路由中携带的RT替换为V-hub在发起其VPN-IP默认路由（RT-VH）时使用的RT，将路由的RD更改为V-hub在发起其关联的V-spoke-only I-PMSI A-D路由时使用的RD，并将下一跳设置为V-hub在V-hub公布的VPN-IP路由的VRF路由导入扩展社区的全局管理员字段中放置的IP地址。对于S-PMSI A-D路由，V-hub还将路由的MCAST-VPN NLRI（网络层可达性信息）中的原始路由器IP地址更改为与下一跳中的地址相同的地址。此外，在公布新的S-PMSI A-D路由之前，V-hub会根据需要修改其PMSI隧道属性（例如，通过将以该路由发起者为根的P隧道替换为以V-hub为根的P隧道）。
Note that a V-hub of a given MVPN may receive and accept multiple (C-*, C-*) wildcard S-PMSI A-D routes [RFC6625], each originated by its own PE. Yet, even if the V-hub receives and accepts such multiple (C-*, C-*) S-PMSI A-D routes, the V-hub re-advertises just one (C-*, C-*) S-PMSI A-D route, thus aggregating the received (C-*, C-*) S-PMSI A-D routes. The same applies for (C-*, C-G) S-PMSI A-D routes.
请注意，给定MVPN的V-hub可以接收和接受多个（C-*，C-*）通配符S-PMSI a-D路由[RFC6625]，每个路由由其自己的PE发起。然而，即使V-hub接收并接受这样多个（C-*，C-*）S-PMSI A-D路由，V-hub也只重新广播一个（C-*，C-*）S-PMSI A-D路由，从而聚合接收到的（C-*，C-*）S-PMSI A-D路由。这同样适用于（C-*，C-G）S-PMSI A-D路线。
Whenever a V-hub receives data on the P-tunnel bound to a received S-PMSI A-D route, the V-hub follows the procedures specified in [RFC6513] and [RFC6514] (or in the case of a wildcard S-PMSI A-D route, the procedures specified in [RFC6625]) to determine whether to accept the data. If the data is accepted, then the V-hub further forwards it over the P-tunnel bound to the S-PMSI A-D route that has been re-advertised by the V-hub.
每当V-hub接收到绑定到接收到的S-PMSI a-D路由的P隧道上的数据时，V-hub遵循[RFC6513]和[RFC6514]中规定的程序（或者在通配符S-PMSI a-D路由的情况下，遵循[RFC6625]中规定的程序）来确定是否接受数据。如果数据被接受，那么V-hub将通过绑定到S-PMSI A-D路由的P隧道进一步转发数据，该路由已由V-hub重新发布。
If multiple S-PMSIs received by a V-hub have been aggregated into the same P-tunnel, then the V-hub, prior to forwarding to the V-spokes associated with that V-hub the data received on this P-tunnel, MAY de-aggregate and then reaggregate (in a different way) this data using the state present in its MVPN-TIB that has been created as a
如果V-hub接收到的多个S-PMSI已聚合到同一个P-tunnel中，则V-hub在将该P-tunnel上接收到的数据转发到与该V-hub相关联的V-Spoke之前，可使用其MVPN-TIB中已创建为a的状态对该数据进行反聚合，然后（以不同的方式）重新聚合该数据
result of receiving C-multicast routes from the V-spokes. Even if S-PMSIs received by the V-hub each have their own P-tunnel, the V-hub, prior to forwarding to the V-spokes the data received on these P-tunnels, MAY aggregate these S-PMSIs using the state present in its MVPN-TIB that has been created as a result of receiving C-multicast routes from the V-spokes.
从V形辐条接收C-多播路由的结果。即使V-hub接收到的S-PMSI各有其自己的P-tunnel，V-hub在将在这些P-tunnel上接收到的数据转发给V-spokes之前，可以使用其MVPN-TIB中存在的状态来聚合这些S-PMSI，该状态是由于从V-spokes接收C-multicast路由而创建的。
The following modifications to the procedures specified in [RFC6514] for originating/receiving I-PMSI A-D routes enable the discarding of packets coming from a "wrong" PE when Ingress Replication is used for I-PMSI P-tunnels (for other types of P-tunnels, the procedures specified in [RFC6513] and [RFC6514] are sufficient).
当入口复制用于I-PMSI P隧道时，（对于其他类型的P隧道，[RFC6513]和[RFC6514]中规定的程序已足够），对[RFC6514]中规定的用于始发/接收I-PMSI A-D路由的程序所作的以下修改可使来自“错误”PE的数据包得以丢弃。
The modifications to the procedures are required to be implemented (by all the PEs of a given MVPN) only under the following conditions:
只有在以下条件下，才需要（由给定MVPN的所有PE）实施对程序的修改：
+ At least one of those PEs is a V-hub or V-spoke PE for the given MVPN.
+ 对于给定的MVPN，这些PE中至少有一个是V形集线器或V形辐条PE。
+ The given MVPN is configured to use the optional procedure of using Ingress Replication to instantiate an I-PMSI.
+ 给定的MVPN配置为使用入口复制的可选过程来实例化I-PMSI。
If Ingress Replication is used with I-PMSI A-D routes, when a PE advertises such routes, the Tunnel Type in the PMSI Tunnel attribute MUST be set to Ingress Replication; the Leaf Information Required flag MUST be set to 1; the attribute MUST carry no MPLS labels.
如果入口复制与I-PMSI A-D路由一起使用，则当PE播发此类路由时，PMSI隧道属性中的隧道类型必须设置为入口复制；叶信息要求标志必须设置为1；该属性不能带有MPLS标签。
A PE that receives such an I-PMSI A-D route MUST respond with a Leaf A-D route. The PMSI Tunnel attribute of that Leaf A-D route is constructed as follows:
接收到这样的I-PMSI A-D路由的PE必须使用叶子A-D路由进行响应。该叶A-D路线的PMSI隧道属性构造如下：
o The Tunnel Type is set to Ingress Replication.
o 隧道类型设置为入口复制。
o The Tunnel Identifier MUST carry a routable address of the PE that originates the Leaf A-D route.
o 隧道标识符必须携带发起叶a-D路由的PE的可路由地址。
o The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label that is used to demultiplex the traffic received over a unicast tunnel by the PE.
o PMSI隧道属性必须携带下游分配的MPLS标签，该标签用于解复用PE通过单播隧道接收的流量。
o The receiving PE MUST assign the label in such a way as to enable the receiving PE to identify (a) the VRF on that PE that should be used to process the traffic received with this label and (b) the PE that sends the traffic with this label.
o 接收PE必须分配标签，以使接收PE能够识别（a）该PE上的VRF，该VRF应用于处理使用此标签接收的流量，以及（b）使用此标签发送流量的PE。
This document assumes that for a given MVPN, all the PEs that have sites of that MVPN connected to them implement the procedures specified in this section.
本文件假设，对于给定的MVPN，所有连接了该MVPN站点的PE均执行本节规定的程序。
Consider a VPN A that consists of 9 sites -- site-1 through site-9. Each site is connected to its own PE -- PE-1 through PE-9.
考虑一个VPN A，由9个站点-SITE-1到站点-9。每个站点都连接到自己的PE-1到PE-9。
We designate PE-3, PE-6, and PE-9 as V-hubs.
我们将PE-3、PE-6和PE-9指定为V型集线器。
To simplify the presentation, the following example assumes that each V-spoke is associated with just one V-hub. However, as mentioned earlier, in practice each V-spoke should be associated with two or more V-hubs.
为了简化演示，下面的示例假设每个V形轮辐仅与一个V形轮毂关联。但是，如前所述，在实践中，每个V形轮辐应与两个或多个V形轮毂相关联。
PE-1 and PE-2 are V-spokes associated with PE-3. PE-4 and PE-5 are V-spokes associated with PE-6. PE-7 and PE-8 are V-spokes associated with PE-9.
PE-1和PE-2是与PE-3相关的V形辐条。PE-4和PE-5是与PE-6相关的V形辐条。PE-7和PE-8是与PE-9相关的V形辐条。
All the PEs (both V-hubs and V-spokes) are provisioned to export routes using RT-A (just as with "vanilla" any-to-any VPN).
所有PE（V-Hub和V-Spoke）都配置为使用RT-A导出路由（就像“香草”任意到任意VPN一样）。
All the V-hubs (PE-3, PE-6, and PE-9) are provisioned to import routes with RT-A (just as with "vanilla" any-to-any VPN).
所有V-Hub（PE-3、PE-6和PE-9）都配置为使用RT-A导入路由（就像“香草”任意到任意VPN一样）。
In addition, PE-3 is provisioned to originate a VPN-IP default route with RT-A-VH-1 (but not with RT-A), while PE-1 and PE-2 are provisioned to import routes with RT-A-VH-1.
此外，PE-3配置为使用RT-a-VH-1（但不使用RT-a）发起VPN-IP默认路由，而PE-1和PE-2配置为使用RT-a-VH-1导入路由。
Likewise, PE-6 is provisioned to originate a VPN-IP default route with RT-A-VH-2 (but not with RT-A), while PE-4 and PE-5 are provisioned to import routes with RT-A-VH-2.
同样，PE-6被配置为使用RT-a-VH-2（但不使用RT-a）发起VPN-IP默认路由，而PE-4和PE-5被配置为使用RT-a-VH-2导入路由。
Finally, PE-9 is provisioned to originate a VPN-IP default route with RT-A-VH-3 (but not with RT-A), while PE-7 and PE-8 are provisioned to import routes with RT-A-VH-3.
最后，PE-9配置为使用RT-a-VH-3（但不使用RT-a）发起VPN-IP默认路由，而PE-7和PE-8配置为使用RT-a-VH-3导入路由。
Now let's modify the example above a bit by assuming that site-3 has Internet connectivity. Thus, site-3 advertises an IP default route to PE-3. PE-3 in turn originates a VPN-IP default route. In this case, the VPN-IP default route carries RT-A and RT-A-VH-1 (rather than just RT-A-VH-1, as before), which results in importing this route to PE-6 and PE-9, as well as to PE-1 and PE-2.
现在，我们假设site-3具有Internet连接，从而稍微修改一下上面的示例。因此，站点3向PE-3播发IP默认路由。PE-3依次发起VPN-IP默认路由。在这种情况下，VPN-IP默认路由携带RT-A和RT-A-VH-1（而不是像以前那样仅携带RT-A-VH-1），这导致将此路由导入PE-6和PE-9以及PE-1和PE-2。
If PE-7 and PE-8, in addition to importing a VPN-IP default route from PE-9, also want to import each other's VPN-IP routes, then PE-7 and PE-8 export their VPN-IP routes with two RTs: RT-A and RT-A-VH-3.
如果PE-7和PE-8除了从PE-9导入VPN-IP默认路由外，还希望导入彼此的VPN-IP路由，则PE-7和PE-8使用两个RTs导出其VPN-IP路由：RT-a和RT-a-VH-3。
All the PEs designated as V-spokes (PE-1, PE-2, PE-4, PE-5, PE-7, and PE-8) are provisioned to export their I-PMSI/S-PMSI/SA A-D routes using RT-A (just as with "vanilla" any-to-any MVPN). Thus, these routes could be imported by all the V-hubs (PE-3, PE-6, and PE-9).
所有指定为V形辐条的PE（PE-1、PE-2、PE-4、PE-5、PE-7和PE-8）都配置为使用RT-A导出其I-PMSI/S-PMSI/SA A-D路由（就像“香草”any到任何MVPN一样）。因此，所有V型枢纽（PE-3、PE-6和PE-9）都可以导入这些路线。
The V-hub on PE-3 is provisioned to export its I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-1. Thus, these routes could be imported by all the other V-hubs (PE-6 and PE-9) and also by the V-spokes, but only by the V-spokes associated with the V-hub on PE-3 (PE-1 and PE-2). In addition, the V-hub on PE-3 originates the Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-1. This route could be imported only by the V-spokes associated with the V-hub on PE-3 (PE-1 and PE-2).
PE-3上的V-hub用于导出其I-PMSI/S-PMSI/SA A-D路由，其中包含两个RTs:RT-A和RT-A-VH-1。因此，所有其他V型枢纽（PE-6和PE-9）以及V型辐条均可导入这些路线，但只能通过与PE-3（PE-1和PE-2）上的V型枢纽相关的V型辐条导入。此外，PE-3上的V-hub通过RT-A-VH-1发起相关的V-spoke-only I-PMSI A-D路由。此路线只能由PE-3（PE-1和PE-2）上与V-hub相关联的V形辐条导入。
The V-hub on PE-6 is provisioned to export its I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-2. Thus, these routes could be imported by all the other V-hubs (PE-3 and PE-9) and also by the V-spokes, but only by the V-spokes associated with the V-hub on PE-6 (PE-4 and PE-5). In addition, the V-hub on PE-6 originates the Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-2. This route could be imported only by the V-spokes associated with the V-hub on PE-6 (PE-4 and PE-5).
PE-6上的V-hub用于导出其I-PMSI/S-PMSI/SA A-D路由，其中包含两个RTs:RT-A和RT-A-VH-2。因此，这些路线可以由所有其他V型枢纽（PE-3和PE-9）以及V型辐条导入，但只能由PE-6（PE-4和PE-5）上与V型枢纽相关的V型辐条导入。此外，PE-6上的V-hub通过RT-A-VH-2发起相关的V-spoke-only I-PMSI A-D路由。此路线只能由PE-6（PE-4和PE-5）上与V-hub相关的V形辐条导入。
The V-hub on PE-9 is provisioned to export its I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-3. Thus, these routes could be imported by all the other V-hubs (PE-3 and PE-6) and also by the V-spokes, but only by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8). In addition, the V-hub on PE-9 originates the Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-3. This route could be imported only by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8).
PE-9上的V-hub用于导出其I-PMSI/S-PMSI/SA A-D路由，其中包含两个RTs:RT-A和RT-A-VH-3。因此，所有其他V型枢纽（PE-3和PE-6）以及V型辐条均可导入这些路线，但只能通过与PE-9（PE-7和PE-8）上的V型枢纽相关的V型辐条导入。此外，PE-9上的V-hub通过RT-A-VH-3发起相关的V-spoke-only I-PMSI A-D路由。此路线只能由PE-9（PE-7和PE-8）上与V-hub相关的V形辐条导入。
If PE-7 and PE-8, in addition to importing a VPN-IP default route from PE-9, also want to import each other's VPN-IP routes, then PE-7 and PE-8 export their I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and RT-A-VH-3.
如果PE-7和PE-8除了从PE-9导入VPN-IP默认路由外，还希望导入彼此的VPN-IP路由，则PE-7和PE-8将其I-PMSI/s-PMSI/SA a-D路由导出为两个RTs:RT-a和RT-a-VH-3。
If the V-hub on PE-9 imports an S-PMSI A-D route or SA A-D route originated by either some other V-hub (PE-3 or PE-6) or a V-spoke that is not associated with this V-hub (PE-1, or PE-2, or PE-4, or PE-5), the V-hub originates an S-PMSI A-D route (respectively, SA A-D route). The V-hub constructs this route from the imported route
如果PE-9上的V-hub导入由其他V-hub（PE-3或PE-6）或与此V-hub（PE-1或PE-2或PE-4或PE-5）无关的V-spoke发起的S-PMSI A-D路由或SA A-D路由，则V-hub发起S-PMSI A-D路由（分别为SA A-D路由）。V-hub从导入的管线构造此管线
following the procedures specified in Section 7.8.2. Specifically, the V-hub replaces the RT(s) carried in the imported route with just one RT -- RT-A-VH-3. Thus, the originated route could be imported only by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8).
遵循第7.8.2节规定的程序。具体地说，V-hub用一个RT-A-VH-3替换导入路线中的RT。因此，只有与PE-9（PE-7和PE-8）上的V-hub相关联的V形辐条才能导入原始路线。
In some cases, a VPN customer may not want to rely solely on an (IP) default route being advertised from a V-spoke to a CE, but may want CEs to receive all the VPN routes (e.g., for the purpose of faster detection of VPN connectivity failures and activating some backup connectivity).
在某些情况下，VPN客户可能不希望仅依赖于从V-spoke到CE的（IP）默认路由，但可能希望CE接收所有VPN路由（例如，为了更快地检测VPN连接故障和激活某些备份连接）。
In this case, an OPTIONAL approach would be to install in the V-spoke's data plane only the VPN-IP default route advertised by the V-hub associated with the V-spoke, even if the V-spoke receives an IP default route from the CE, and to keep all the VPN-IP routes in the V-spoke's control plane (thus being able to advertise these routes as IP routes from the V-spoke to the CEs). Granted, this would not change control-plane resource consumption but would reduce forwarding state on the data plane.
在这种情况下，可选的方法是在V-spoke的数据平面中仅安装由V-hub发布的与V-spoke相关联的VPN-IP默认路由，即使V-spoke从CE接收到IP默认路由，并且将所有VPN-IP路由保留在V-spoke的控制平面中（因此能够将这些路由作为从V-spoke到CEs的IP路由进行公告）。当然，这不会改变控制平面资源消耗，但会减少数据平面上的转发状态。
This document introduces no new security considerations above and beyond those already specified in [RFC4364].
除[RFC4364]中已规定的安全注意事项外，本文件未引入任何新的安全注意事项。
We would like to acknowledge Han Nguyen (AT&T) for his contributions to this document. We would like to thank Eric Rosen (Cisco) for his review and comments. We would also like to thank Samir Saad (AT&T), Jeffrey (Zhaohui) Zhang (Juniper), and Thomas Morin (Orange) for their review and comments.
我们要感谢韩阮（AT&T）对本文件的贡献。我们要感谢Eric Rosen（Cisco）的审查和评论。我们还要感谢萨米尔·萨阿德（AT&T）、杰弗里·张昭辉（Juniper）和托马斯·莫林（Orange）的评论和评论。
[IANA-SAFI] IANA Subsequent Address Family Identifiers (SAFI) Parameters, <http://www.iana.org/assignments/safi-namespace/>.
[IANA-SAFI]IANA后续地址系列标识符（SAFI）参数<http://www.iana.org/assignments/safi-namespace/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684]Marques，P.，Bonica，R.，Fang，L.，Martini，L.，Raszuk，R.，Patel，K.，和J.Guichard，“边界网关协议/多协议标签交换（BGP/MPLS）互联网协议（IP）虚拟专用网络（VPN）的受限路由分布”，RFC 46842006年11月。
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC6513]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，2012年2月。
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, May 2012.
[RFC6625]Rosen，E.，Ed.，Rekhter，Y.，Ed.，Hendrickx，W.，和R.Qiu，“多播VPN自动发现路由中的通配符”，RFC 66252012年5月。
[MPLS-MCAST] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP Segmented LSPs", Work in Progress, May 2013.
[MPLS-MCAST]Y.雷克特、R.阿加瓦尔、T.莫林、I.格罗斯克劳德、N.莱曼和S.萨阿德，“区域间P2MP分段LSP”，正在进行的工作，2013年5月。
Authors' Addresses
作者地址
Huajin Jeng AT&T
郑华津AT&T
EMail: hj2387@att.com
EMail: hj2387@att.com
James Uttaro AT&T
詹姆斯·乌塔罗AT&T
EMail: ju1738@att.com
EMail: ju1738@att.com
Luay Jalil Verizon
威瑞森公司
EMail: luay.jalil@verizon.com
EMail: luay.jalil@verizon.com
Bruno Decraene Orange
布鲁诺橙
EMail: bruno.decraene@orange.com
EMail: bruno.decraene@orange.com
Yakov Rekhter Juniper Networks, Inc.
雅科夫·雷克特·朱尼珀网络公司。
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Rahul Aggarwal Arktan
拉胡尔·阿加瓦尔·阿尔坦
EMail: raggarwa_1@yahoo.com
EMail: raggarwa_1@yahoo.com