Internet Engineering Task Force (IETF) C. Cardona
Request for Comments: 7789 IMDEA Networks/UC3M
Category: Informational P. Francois
ISSN: 2070-1721 P. Lucente
Cisco Systems
April 2016
Internet Engineering Task Force (IETF) C. Cardona
Request for Comments: 7789 IMDEA Networks/UC3M
Category: Informational P. Francois
ISSN: 2070-1721 P. Lucente
Cisco Systems
April 2016
Impact of BGP Filtering on Inter-Domain Routing Policies
BGP过滤对域间路由策略的影响
Abstract
摘要
This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it.
本文档描述了由于其他自治系统过滤或限制更具体前缀的传播，如何在自治系统中出现意外流量。我们提供了一个技术的审查，以检测这个问题的发生，并防范它。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7789.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7789.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4
2.1. Local Filtering . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of
More-Specific Prefixes . . . . . . . . . . . . . . . 5
2.2. Remote Filtering . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered
Filtering of More-Specific Prefixes . . . . . . . . . 7
3. Techniques to Detect Unexpected Traffic Flows Caused by
Filtering of More-Specific Prefixes . . . . . . . . . . . . . 8
3.1. Existence of Unexpected Traffic Flows within an AS . . . 8
3.2. Contribution to the Existence of Unexpected Traffic Flows
in Another AS . . . . . . . . . . . . . . . . . . . . . . 9
4. Techniques to Traffic Engineer Unexpected Flows . . . . . . . 10
4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11
4.2. Proactive Measures . . . . . . . . . . . . . . . . . . . 12
4.2.1. Access Lists . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Neighbor-Specific Forwarding . . . . . . . . . . . . 13
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4
2.1. Local Filtering . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of
More-Specific Prefixes . . . . . . . . . . . . . . . 5
2.2. Remote Filtering . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered
Filtering of More-Specific Prefixes . . . . . . . . . 7
3. Techniques to Detect Unexpected Traffic Flows Caused by
Filtering of More-Specific Prefixes . . . . . . . . . . . . . 8
3.1. Existence of Unexpected Traffic Flows within an AS . . . 8
3.2. Contribution to the Existence of Unexpected Traffic Flows
in Another AS . . . . . . . . . . . . . . . . . . . . . . 9
4. Techniques to Traffic Engineer Unexpected Flows . . . . . . . 10
4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11
4.2. Proactive Measures . . . . . . . . . . . . . . . . . . . 12
4.2.1. Access Lists . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Neighbor-Specific Forwarding . . . . . . . . . . . . 13
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
It is common practice for network operators to propagate a more-specific prefix in the BGP routing system along with the less-specific prefix that they originate. It is also possible for some Autonomous Systems (ASes) to apply different policies to the more specific and the less-specific prefix.
网络运营商通常在BGP路由系统中传播一个更具体的前缀，同时传播他们发起的不太具体的前缀。一些自治系统（ASE）也可能对更具体和不太具体的前缀应用不同的策略。
Although BGP makes independent, policy-driven decisions for the selection of the best path to be used for a given IP prefix, routers must forward packets using the longest-prefix-match rule, which "precedes" any BGP policy [RFC1812]. The existence of a prefix p that is more specific than a prefix p' in the Forwarding Information Base (FIB) will let packets whose destination matches p be forwarded according to the next hop selected as best for p (the more-specific prefix). This process takes place by disregarding the policies applied in the control plane for the selection of the best next hop for p'. When an AS filters more-specific prefixes and forwards packets according to the less-specific prefix, the discrepancy among
虽然BGP为选择用于给定IP前缀的最佳路径做出独立的策略驱动决策，但路由器必须使用最长前缀匹配规则转发数据包，该规则“先于”任何BGP策略[RFC1812]。在转发信息库（FIB）中存在比前缀p’更具体的前缀p’将允许根据为p（更具体的前缀）选择的最佳下一跳转发其目的地与p匹配的分组。该过程通过忽略在控制平面中应用的策略来选择p'的最佳下一跳来实现。当AS过滤更具体的前缀并根据不太具体的前缀转发数据包时，这些前缀之间的差异
the routing policies applied to the less and the more-specific prefixes can create unexpected traffic flows. These may infringe on the policies of other ASes still holding a path towards the more-specific prefix.
应用于更少和更具体前缀的路由策略可能会产生意外的流量。这些可能会违反其他仍然持有通往更具体前缀路径的ASE的政策。
The objective of this document is to shed light on possible side effects associated with more-specific prefix filtering. Such actions can be explained by traffic engineering action, misconfiguration, or malicious intent. This document presents examples of such side effects and discusses approaches towards solutions to the problem.
本文档的目的是阐明与更具体的前缀过滤相关的可能副作用。这种行为可以用流量工程行为、错误配置或恶意意图来解释。本文件介绍了此类副作用的示例，并讨论了解决该问题的方法。
The rest of the document is organized as follows: in Section 2 we provide some scenarios in which the filtering of more-specific prefixes leads to the creation of unexpected traffic flows; Section 3 and Section 4 discuss some techniques that ASes can use for, respectively, detecting and reacting to unexpected traffic flows; and the document concludes in Section 5.
文档的其余部分组织如下：在第2节中，我们提供了一些场景，其中过滤更具体的前缀会导致意外流量的产生；第3节和第4节讨论了ASes可分别用于检测和响应意外交通流的一些技术；本文件在第5节结束。
More-specific prefix: A prefix in the routing table with an address range that is covered by a shorter prefix also present in the routing table.
更具体的前缀：路由表中的前缀，地址范围由路由表中也存在的较短前缀覆盖。
Less-specific prefix: A prefix in the routing table with an address range partially covered by other prefixes.
不太特定的前缀：路由表中的前缀，地址范围部分被其他前缀覆盖。
Customer-provider peering: A peering arrangement in which a transit network provides connectivity to a customer in exchange of a fee, as derived from RFC 4384 [RFC4384].
客户提供商对等：一种对等安排，其中公交网络向客户提供连接以交换费用，如RFC 4384[RFC4384]所述。
Settlement-free peering: A peering arrangement in which two networks agree on a settlement-free traffic exchange, typically covering only their customer traffic, as derived from RFC 4384 [RFC4384].
无结算对等：一种对等安排，其中两个网络在无结算流量交换上达成一致，通常只覆盖其客户流量，如RFC 4384[RFC4384]所述。
Selective advertisement: The behavior of only advertising a self originated BGP path for a prefix over a strict subset of the External BGP (eBGP) sessions of the AS.
选择性播发：仅在AS的外部BGP（eBGP）会话的严格子集上播发前缀的自源BGP路径的行为。
Selective propagation: The behavior of only propagating a BGP path for a prefix over a strict subset of the eBGP sessions of an AS.
选择性传播：仅在AS的eBGP会话的严格子集上传播前缀的BGP路径的行为。
Local filtering: The behavior of explicitly ignoring a BGP path received over an eBGP session.
本地筛选：显式忽略通过eBGP会话接收的BGP路径的行为。
Remote filtering: The behavior of triggering selective propagation of a BGP path at a distant AS. Note that this is typically achieved by tagging a self-originated path with BGP communities defined by the distant AS.
远程过滤：在远程AS触发BGP路径选择性传播的行为。请注意，这通常是通过使用远程AS定义的BGP社区标记自源路径来实现的。
Unexpected traffic flow: Traffic flowing between two neighboring ASes of an AS, although the transit policy of that AS is to not provide connectivity between these two neighbors. A traffic flow across an AS between two of its transit providers or between a transit provider and one of its settlement-free peers are classic examples of unexpected traffic flows.
意外流量：AS的两个相邻ASE之间的流量，尽管该AS的传输策略是不提供这两个相邻ASE之间的连接。在两个公交服务提供商之间或公交服务提供商与其一个无结算对等方之间，通过AS的交通流是意外交通流的典型示例。
In this section, we describe how more-specific prefix filtering can lead to unexpected traffic flows in other, remote, ASes. We differentiate cases in which the filtering is performed locally from those where the filtering is triggered remotely.
在本节中，我们将描述更具体的前缀过滤如何在其他远程ASE中导致意外流量。我们将本地执行过滤的情况与远程触发过滤的情况区分开来。
Different reasons motivate local filtering, for example:
不同的原因会激发本地筛选，例如：
Traffic engineering: An ISP can decide to filter more-specific prefixes when it wants to control their local outbound traffic distribution using only the policy applied to the less-specific prefix. Such a practice was notably documented in a presentation by Init7 [INIT7-RIPE63].
流量工程（Traffic engineering）：当ISP希望仅使用应用于不太特定前缀的策略来控制其本地出站流量分布时，可以决定过滤更特定的前缀。Init7[Init7-RIPE63]在一次演示中记录了这种做法。
Enforcing contract compliance: An ISP can decide to filter more-specific prefixes to enforce clauses of their peering agreements. For instance, a settlement-free peer of an ISP can use selective advertisement of more-specific prefixes to attract traffic to one link. If this practice is not allowed by their peering agreement, the ISP can filter the more-specific prefixes to prevent it.
强制遵守合同：ISP可以决定过滤更具体的前缀，以强制执行其对等协议的条款。例如，ISP的无结算对等方可以使用更特定前缀的选择性广告来吸引一条链路的流量。如果对等协议不允许这种做法，ISP可以过滤更具体的前缀以防止这种情况发生。
Memory preservation: An ISP can decide to filter more-specific prefixes in order to preserve FIB memory of their routers.
内存保留：ISP可以决定过滤更具体的前缀，以保留其路由器的FIB内存。
Figure 1 illustrates a scenario where one AS performs local filtering due to outbound traffic engineering. The figure depicts AS64504 and two of its neighboring ASes, AS64502 and AS64505. AS64504 has a settlement-free peering with AS64502 and is a customer of AS64505. AS64504 receives from AS64505 prefixes 2001:DB8::/32 and 2001:DB8::/34. AS64504 only receives the less-specific prefix 2001:DB8::/32 from AS64502.
图1说明了一个场景，其中AS由于出站流量工程而执行本地过滤。该图描述了AS64504及其两个相邻ASE，AS64502和AS64505。AS64504具有与AS64502的免结算对等功能，并且是AS64505的客户。AS64504从AS64505接收前缀2001:DB8:：/32和2001:DB8:：/34。AS64504仅从AS64502接收不太特定的前缀2001:DB8:：/32。
,-----.
/ \
( AS64505 )
\ /
`--+--'
2001:DB8::/32 | |
2001:DB8::/34 v |
|
,--+--. 2001:DB8::/32 ,-----.
/ \ <-- / \
( AS64504 )-------------( AS64502 )
\ / \ /
`-----' `-----'
,-----.
/ \
( AS64505 )
\ /
`--+--'
2001:DB8::/32 | |
2001:DB8::/34 v |
|
,--+--. 2001:DB8::/32 ,-----.
/ \ <-- / \
( AS64504 )-------------( AS64502 )
\ / \ /
`-----' `-----'
Figure 1: Local Filtering
图1：局部过滤
Due to economic reasons, AS64504 might prefer to send traffic to AS64502 instead of AS64505. However, even if paths received from AS64502 are given a large local preference, routers in AS64504 will still send traffic to prefix 2001:DB8::/34 via neighbor AS64505. This situation may push AS64504 to apply an inbound filter for the more-specific prefix, 2001:DB8::/34, on the session with AS64505. After applying the filter, AS64504 will send traffic for the more-specific prefix to AS64502.
由于经济原因，AS64504可能更愿意将流量发送到AS64502而不是AS64505。但是，即使从AS64502接收到的路径具有较大的本地首选项，AS64504中的路由器仍将通过邻居AS64505向前缀2001:DB8:：/34发送流量。这种情况可能会促使AS64504在与AS64505的会话上对更具体的前缀2001:DB8:：/34应用入站筛选器。应用过滤器后，AS64504将向AS64502发送更具体前缀的通信量。
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of More-Specific Prefixes
2.1.1. 由更特定前缀的本地筛选引起的意外流量
In this section, we show how the decision of AS64504 to perform local filtering creates unexpected traffic flows in AS64502. Figure 2 shows the whole picture of the scenario where AS64501 is a customer of AS64503 and AS64502. AS64503 is a settlement-free peer with AS64502. AS64503 and AS64502 are customers of AS64505. The AS originating the two prefixes, AS64501, performs selective advertisement with the more-specific prefix and only announces it to AS64503.
在本节中，我们将展示AS64504执行本地筛选的决定如何在AS64502中创建意外的流量。图2显示了AS64501是AS64503和AS64502客户的整个场景。AS64503是AS64502的免结算对等机。AS64503和AS64502是AS64505的客户。发出两个前缀AS64501的AS使用更具体的前缀执行选择性播发，并仅向AS64503宣布。
After AS64504 locally filters the more-specific prefix, traffic from AS64504 to prefix 2001:DB8::/34 is forwarded towards AS64502. Because AS64502 receives the more-specific prefix from AS64503, traffic from AS64504 to 2001:DB8::/34 follows the path AS64504-AS64502-AS64503-AS64501. AS64502's BGP policies are implemented to avoid transporting traffic between AS64504 and AS64503. However, due to the discrepancies of routes between the more and the less-specific prefixes, unexpected traffic flows between AS64504 and AS64503 exist in AS64502's network.
在AS64504本地筛选更具体的前缀后，从AS64504到前缀2001:DB8:：/34的流量将转发到AS64502。因为AS64502从AS64503接收更具体的前缀，所以从AS64504到2001:DB8:：/34的流量遵循路径AS64504-AS64502-AS64503-AS64501。AS64502的BGP策略用于避免在AS64504和AS64503之间传输流量。然而，由于更多和更少特定前缀之间的路由差异，AS64504和AS64503之间的意外流量存在于AS64502的网络中。
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| |________| |
| | /32 | |/32 /32| |
'. ,' . ,' /34 . ,'
`. ,' `. ,' +-> <-+ `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| |________| |
| | /32 | |/32 /32| |
'. ,' . ,' /34 . ,'
`. ,' `. ,' +-> <-+ `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
Figure 2: Unexpected Traffic Flows Due to Local Filtering
图2：本地过滤导致的意外流量
ISPs can tag the BGP paths that they propagate to neighboring ASes with communities in order to tweak the propagation behavior of the ASes that handle these paths; see a paper from 2008 by Donnet and Bonaventure [on_BGP_communities]. Some ISPs allow their customers to use such communities to let the receiving AS not export the path to some selected neighboring ASes. By combining communities, the prefix could be advertised only to a given peer of the AS providing this feature. A network operator can leverage remote filtering to, for instance, limit the scope of prefixes and hence perform more granular inbound traffic engineering.
ISP可以用社区标记它们传播到相邻ASE的BGP路径，以便调整处理这些路径的ASE的传播行为；见Donnet和Bonaventure在2008年发表的一篇论文[关于社区]。一些ISP允许其客户使用此类社区，让接收AS不将路径导出到某些选定的相邻ASE。通过组合社区，前缀只能向提供此功能的给定对等方发布。例如，网络运营商可以利用远程过滤来限制前缀的范围，从而执行更细粒度的入站流量工程。
Figure 3 illustrates a scenario in which an AS uses BGP communities to command its provider to selectively propagate a more-specific prefix. Let AS64501 be a customer of AS64502 and AS64503. AS64501 originates prefix 2001:DB8::/32, which it advertises to AS64502 and AS64503. AS64502 and AS64503 are settlement-free peers. Let AS64501 do selective advertisement and only propagate 2001:DB8::/34 over AS64503. AS64503 would normally propagate this prefix to its customers, providers, and peers, including AS64502.
图3说明了一个场景，其中AS使用BGP社区命令其提供者有选择地传播更具体的前缀。让AS64501成为AS64502和AS64503的客户。AS64501产生前缀2001:DB8:：/32，并向AS64502和AS64503播发。AS64502和AS64503是无结算对等方。让AS64501做选择性广告，只在AS64503上传播2001:DB8:：/34。AS64503通常会将此前缀传播给其客户、提供商和对等方，包括AS64502。
Let us consider that AS64501 decides to limit the scope of the more-specific prefix. AS64501 can make this decision based on its traffic engineering strategy. To achieve this, AS64501 can tag the more-specific prefix with a set of communities that leads AS64503 to only propagate the path to AS64502.
让我们考虑AS64 501决定限制更具体的前缀的范围。AS64501可以根据其流量工程策略做出此决定。为此，AS64501可以使用一组社区标记更具体的前缀，这将导致AS64503仅将路径传播到AS64502。
^ \ / ^ ^ \ / ^
| /32 \ / /32 | | /32 \ / /32 |
,-----. ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' -> /34 `. ,'
'-----; <- / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +-- / AS64501 \ --+
( )
\ /
`. ,'
'-----'
^ \ / ^ ^ \ / ^
| /32 \ / /32 | | /32 \ / /32 |
,-----. ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' -> /34 `. ,'
'-----; <- / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +-- / AS64501 \ --+
( )
\ /
`. ,'
'-----'
Figure 3: Remote-Triggered Filtering
图3：远程触发过滤
2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered Filtering of More-Specific Prefixes
2.2.1. 远程触发的更特定前缀过滤导致的意外流量
Figure 4 expands the scenario from Figure 3 and includes other ASes peering with AS64502 and AS64503. Due to the limitation on the scope performed on the more-specific prefix, ASes that are not customers of AS64502 will not receive a path for 2001:DB8::/34. These ASes will forward packets destined to 2001:DB8::/34 according to their routing state for 2001:DB8::/32. Let us assume that AS64505 is such an AS and that its best path towards 2001:DB8::/32 is through AS64502.
图4扩展了图3中的场景，包括使用AS64502和AS64503的其他ASE对等。由于对更具体前缀执行的范围的限制，非AS64502客户的ASE将不会收到2001:DB8:：/34的路径。这些ASE将根据其2001:DB8:：/32的路由状态转发目的地为2001:DB8:：/34的数据包。让我们假设AS64505就是这样一个AS，它通向2001:DB8:：/32的最佳路径是通过AS64502。
Packets sent towards 2001:DB8::1 by AS64505 will reach AS64502. However, in the data plane of the nodes of AS64502, the longest prefix match for 2001:DB8::1 is 2001:DB8::/34, which is reached through AS64503, a settlement-free peer of AS64502. Since AS64505 is not in the customer branch of AS64502, traffic flows between two noncustomer ASes in AS64502.
AS64505向2001:DB8:：1发送的数据包将到达AS64502。但是，在AS64502节点的数据平面中，2001:DB8:：1的最长前缀匹配是2001:DB8:：/34，这是通过AS64502的无结算对等方AS64503实现的。由于AS64505不在AS64502的客户分支中，因此AS64502中的两个非客户ASE之间的通信流。
,-----.
,' `.
/ AS64505 \
( )
\ /
,`. ,' \
/ '-----' \
/ ^ ^ \
/32 | | /32 '
,-----.' + + ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' +-> /34 `. ,'
'-----; <-+ / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +--+ / AS64501 \ +--+
( )
\ /
`. ,'
'-----'
,-----.
,' `.
/ AS64505 \
( )
\ /
,`. ,' \
/ '-----' \
/ ^ ^ \
/32 | | /32 '
,-----.' + + ,-----.
,' `. ,' `.
/ AS64502 \ / AS64503 \
( )-------------( )
\ / /32 /32 \ /
`. ,' +-> /34 `. ,'
'-----; <-+ / '-----'
\ /
^ \ / ^
| \ / |
| \ / |
| \ ,-----.' | 2001:DB8::/32
| ,' `. | 2001:DB8::/34
2001:DB8::/32 +--+ / AS64501 \ +--+
( )
\ /
`. ,'
'-----'
Figure 4: Unexpected Traffic Flows Due to Remote-Triggered Filtering
图4：远程触发过滤导致的意外流量
3. Techniques to Detect Unexpected Traffic Flows Caused by Filtering of More-Specific Prefixes
3. 检测由过滤更具体前缀引起的意外流量的技术
To detect if unexpected traffic flows are taking place in its network, an ISP can monitor its traffic data to check if it is providing transit between two of its peers, although its policy is configured to not provide such transit. IPFIX [RFC7011] is an example of a technology that can be used to export information regarding traffic flows across the network. Traffic information must
为了检测其网络中是否发生意外流量，ISP可以监控其流量数据，以检查其是否在两个对等方之间提供传输，尽管其策略配置为不提供此类传输。IPFIX[RFC7011]是一种可用于导出网络流量信息的技术示例。必须提供交通信息
be analyzed under the perspective of the business relationships with neighboring ASes to detect the flows not fitting the policy. Operators can use collection systems that combine traffic statistics with policy information for this end. See the pmacct project [PMACCT] for an open-source application meeting these requirements.
从与相邻ASE的业务关系的角度进行分析，以检测不符合策略的流。为此，运营商可以使用将交通统计数据与政策信息相结合的收集系统。请参阅pmacct项目[pmacct]，了解满足这些要求的开源应用程序。
Note that the AS detecting the unexpected traffic flow may simply realize that its policy configuration is broken. The first recommended action upon detection of an unexpected traffic flow is to verify the correctness of the BGP configuration.
注意，AS检测到意外流量可能只是意识到其策略配置被破坏。在检测到意外流量时，第一个建议的操作是验证BGP配置的正确性。
Once the local configuration is confirmed correct, the operator should check if the unexpected flow arose due to filtering of BGP paths for more-specific prefixes by neighboring ASes. This can be performed in two steps. First, the operator should check whether the neighboring AS originating the unexpected flow is forwarding traffic using a less-specific prefix that is announced to it by the affected network. The second step is to try to infer the reason why the neighboring AS does not use the more-specific path for forwarding, i.e., finding why the more-specific prefix was filtered. Due to the distributed nature and restricted visibility of the steering of BGP policies, this second step does not identify the origin of the problem with guaranteed accuracy.
一旦确认本地配置正确，操作员应检查是否由于相邻ASE过滤BGP路径以获得更具体的前缀而产生意外流量。这可以分两步执行。首先，运营商应检查发起意外流的相邻AS是否使用受影响网络向其宣布的不太特定的前缀转发流量。第二步是尝试推断相邻AS不使用更具体路径进行转发的原因，即查找过滤更具体前缀的原因。由于BGP策略指导的分布式性质和有限可见性，第二步无法以保证的准确性确定问题的根源。
For the first step, the operator should check if the destination address of the unexpected traffic flow is locally routed as per a more-specific prefix only received from noncustomer peers. The operator should also check if there are paths to a less-specific prefix received from a customer and hence propagated to peers. If these two situations happen at the same time, the neighboring AS at the entry point of the unexpected flow is routing the traffic based on the less-specific prefix, although the ISP is actually forwarding the traffic via noncustomer links.
对于第一步，操作员应检查意外流量的目的地地址是否按照仅从非客户对等方接收的更具体前缀在本地路由。操作员还应检查是否存在从客户处接收到的不太特定前缀的路径，从而传播到对等方。如果这两种情况同时发生，则在意外流入口点的相邻AS将基于不太特定的前缀路由流量，尽管ISP实际上是通过非客户链路转发流量。
For the second step, one can rely on human interaction or looking glasses to find out whether local filtering, remote filtering, or selective propagation was performed on the more-specific prefix. No openly available tools that can automatically perform this operation have been identified.
对于第二步，可以依靠人机交互或观察眼镜来确定是否对更具体的前缀执行了本地过滤、远程过滤或选择性传播。尚未确定可自动执行此操作的公开可用工具。
3.2. Contribution to the Existence of Unexpected Traffic Flows in Another AS
3.2. 对另一个AS中存在意外交通流的贡献
It can be considered problematic to trigger unexpected traffic flows in another AS. It is thus advisable for an AS to assess the risks of filtering more-specific prefixes before implementing them by obtaining as much information as possible about its surrounding routing environment.
在另一个AS中触发意外流量可能会被认为是有问题的。因此，建议AS在实现更具体的前缀之前，通过获取有关其周围路由环境的尽可能多的信息来评估过滤这些前缀的风险。
There may be justifiable reasons for one ISP to perform filtering: either to enforce established policies or to provide prefix-advertisement scoping features to its customers. These can vary from troubleshooting purposes to business-relationship implementations. Restricting the use of these features for the sake of avoiding the creation of unexpected traffic flows is not a practical option.
一个ISP执行过滤可能有合理的理由：要么强制执行既定的策略，要么向其客户提供前缀广告范围功能。从故障排除的目的到业务关系的实现，这些都可能有所不同。为了避免产生意外的交通流而限制这些功能的使用不是一个切实可行的选择。
In order to assess the risk of filtering more-specific prefixes, the AS would need information on the routing policies and the relationships among external ASes to detect if its actions could trigger the appearance of unexpected traffic flows. With this information, the operator could detect other ASes receiving the more-specific prefix from noncustomer ASes while announcing the less-specific prefix to other noncustomer ASes. If the filtering of the more-specific prefix leads other ASes to send traffic for the more-specific prefix to these ASes, an unexpected traffic flow can arise. However, the information required for this operation is difficult to obtain since it is frequently considered confidential.
为了评估过滤更具体前缀的风险，AS需要有关路由策略和外部ASE之间关系的信息，以检测其操作是否会触发意外流量的出现。利用此信息，操作员可以检测到从非客户ASE接收到更具体前缀的其他ASE，同时向其他非客户ASE宣布不太具体的前缀。如果过滤更具体的前缀导致其他ASE向这些ASE发送更具体前缀的流量，则可能会出现意外的流量。然而，这项行动所需的信息很难获得，因为它经常被视为机密信息。
Network operators can adopt different approaches with respect to unexpected traffic flows. Note that due to the complexity of inter-domain routing policies, there is not a single solution that can be applied to all situations. This section provides potential solutions that ISPs must evaluate against each particular case. We classify these actions according to whether they are proactive or reactive.
网络运营商可以针对意外流量采取不同的方法。请注意，由于域间路由策略的复杂性，没有一种解决方案可以应用于所有情况。本节提供了ISP必须针对每个特定情况评估的潜在解决方案。我们根据这些行动是主动的还是被动的进行分类。
Reactive approaches are those in which the operator tries to detect the situations via monitoring and solve unexpected traffic flows manually on a case-by-case basis.
反应式方法是指运营商试图通过监控来检测情况，并根据具体情况手动解决意外交通流的方法。
Anticipant or preventive approaches are those in which the routing system will not let the unexpected traffic flows actually take place when the scenario arises.
预期的或预防性的方法是指当场景出现时，路由系统不会让意外的交通流实际发生的方法。
We use the scenario depicted in Figure 5 to describe these two kinds of approaches. Since proactive approaches can be complex to implement and can lead to undesired effects, the reactive approach is the more reasonable recommendation to deal with unexpected flows.
我们使用图5中描述的场景来描述这两种方法。由于主动式方法的实施可能比较复杂，并且可能导致不期望的效果，因此，被动式方法是处理意外流的更合理的建议。
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| | | |
| | /32 | | | |
'. ,' . ,' . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
____,,................______
_,.---'''' `''---..._
,-'' AS64505 `-.
[ /
-.._ __.-'
. `'---....______ ______...---''
+ |/32 `''''''''''''''' |
| |/34 + |/32 |
v | v |/34 |
| | ^ |
| ^ |/32 | |/32
| + | + |/34
_,,---.:_ _,,---.._ _,,---.._
,' `. ,' `. ,' `.
/ AS64504 \ <-+ / AS64502 \ / AS64503 \
| |_________| | | |
| | /32 | | | |
'. ,' . ,' . ,'
`. ,' `. ,' `. ,'
``---'' ``---'' ``---''
| ^ |
^ |2001:DB8::/32 | |2001:DB8::/32
| | + |2001:DB8::/34
+ | _....---------...._|
,-'AS64501 ``-.
/' `.
`. _,
`-.._ _,,,'
`''---------'''
Figure 5: Traffic Engineering of Unexpected Traffic Flows - Base Example
图5：意外交通流的交通工程-基本示例
An operator who detects unexpected traffic flows originated by any of the cases described in Section 2 can contact the ASes that are likely to have performed the propagation tweaks, inform them of the situation, and persuade them to change their behavior.
检测到由第2节所述任何情况引起的意外交通流的运营商可以联系可能执行传播调整的ASE，通知他们情况，并说服他们改变行为。
If the situation remains, the operator can implement prefix filtering in order to stop the unexpected flows. The operator can decide to perform this action over the session with the operator announcing the more-specific prefix or over the session with the neighboring AS from which it is receiving the traffic. Each of these options carry a different repercussion for the affected AS. We briefly describe the two alternatives.
如果情况仍然存在，操作员可以实施前缀过滤以停止意外流。运营商可以决定在与运营商宣布更具体前缀的会话期间，或在与从其接收流量的相邻AS的会话期间执行此操作。每种选择都会对受影响的AS产生不同的影响。我们简要介绍这两种选择。
o An operator can decide to stop announcing the less-specific prefix at the peering session with the neighboring AS from which it is receiving traffic to the more-specific prefix. In the example of Figure 5, AS64502 would filter out the prefix 2001:DB8::/32 from the eBGP session with AS64504. In this case, traffic heading to the prefix 2001:DB8::/32 from AS64501 would no longer traverse AS64502. AS64502 should evaluate if solving the issues originated by the unexpected traffic flows are worth the loss of this traffic share.
o 运营商可以决定在与相邻AS的对等会话中停止宣布不太特定的前缀，该相邻AS从其接收到更特定前缀的流量。在图5的示例中，AS64502将从与AS64504的eBGP会话中过滤掉前缀2001:DB8:：/32。在这种情况下，AS64501中指向前缀2001:DB8:：/32的流量将不再穿过AS64502。AS64502应评估解决意外流量引起的问题是否值得损失此流量份额。
o An operator can decide to filter out the more-specific prefix at the peering session over which it was received. In the example of Figure 5, AS64502 would filter out the incoming prefix 2001:DB8::/34 from the eBGP session with AS64505. As a result, the traffic destined to that /32 would be forwarded by AS64502 along its link with AS64501, despite the actions performed by AS64501 to have this traffic coming in through its link with AS64503. However, as AS64502 will no longer know a route to the more-specific prefix, it risks losing the traffic share from customers different from AS64501 to that prefix. Furthermore, this action can generate conflicts between AS64502 and AS64501, since AS64502 does not follow the routing information expressed by AS64501 in its BGP announcements.
o 操作员可以决定在接收前缀的对等会话中过滤掉更具体的前缀。在图5的示例中，AS64502将从带有AS64505的eBGP会话中过滤掉传入前缀2001:DB8:：/34。因此，尽管AS64501执行了使该通信量通过其与AS64503的链路进入的操作，但AS64502将沿着其与AS64501的链路转发发送到该/32的通信量。但是，由于AS64502将不再知道到更具体前缀的路由，因此有可能失去从AS64501到该前缀的不同客户的流量份额。此外，此操作可能会在AS64502和AS64501之间产生冲突，因为AS64502不遵循AS64501在其BGP公告中表示的路由信息。
Note that it is possible that the behavior of the neighboring AS causing the unexpected traffic flows violates a contractual agreement between the two networks.
请注意，导致意外流量的相邻网络的行为可能违反两个网络之间的合同协议。
An operator could install access lists to prevent unexpected traffic flows from happening in the first place. In the example of Figure 5, AS64502 would install an access list denying packets matching 2001:DB8::/34 associated with the interface connecting to AS64504. As a result, traffic destined to that prefix would be dropped despite the existence of a valid route towards 2001:DB8::/32.
运营商可以安装访问列表，以防止意外流量的发生。在图5的示例中，AS64502将安装一个访问列表，拒绝与连接到AS64504的接口相关联的2001:DB8:：/34匹配的数据包。因此，尽管存在通往2001:DB8:：/32的有效路由，但以该前缀为目的地的流量将被丢弃。
The operational overhead of such a solution is considered high, as the operator would have to constantly adapt these access lists to accommodate inter-domain routing changes. Moreover, this technique lets packets destined to a valid prefix be dropped while they are sent from a neighboring AS that may not know about the policy conflict and hence had no means to avoid the creation of unexpected traffic flows. For this reason, this technique can be considered harmful.
这种解决方案的操作开销被认为很高，因为运营商必须不断调整这些访问列表以适应域间路由的变化。此外，该技术允许在从相邻的服务器发送目的地为有效前缀的数据包时丢弃这些数据包，因为这些服务器可能不知道策略冲突，因此无法避免创建意外的流量。因此，这种技术可能被认为是有害的。
An operator can technically ensure that traffic destined to a given prefix will be forwarded from an entry point of the network based only on the set of paths that have been advertised over that entry point.
运营商可以在技术上确保目的地为给定前缀的业务将仅基于在该入口点上公布的路径集从网络入口点转发。
As an example, let us analyze the scenario of Figure 5 from the point of view of AS64502. The edge router connecting to the AS64504 forwards packets destined to prefix 2001:DB8::/34 towards AS64505. Likewise, it forwards packets destined to prefix 2001:DB8::/32 towards AS64501. The router, however, only propagates the path of the less-specific prefix (2001:DB8::/32) to AS64504. An operator could implement the necessary techniques to force the edge router to forward packets coming from AS64504 based only on the paths propagated to AS64504. Thus, the edge router would forward packets destined to 2001:DB8::/34 towards AS64501, in which case no unexpected traffic flow would occur.
作为一个例子，让我们从AS64502的角度分析图5的场景。连接到AS64504的边缘路由器向AS64505转发以前缀2001:DB8:：/34为目的地的数据包。同样，它将发送到前缀2001:DB8:：/32的数据包转发到AS64501。但是，路由器仅将不太特定的前缀（2001:DB8:：/32）的路径传播到AS64504。操作员可以实施必要的技术，强制边缘路由器仅基于传播到AS64504的路径转发来自AS64504的数据包。因此，边缘路由器将向AS64501转发目的地为2001:DB8:：/34的数据包，在这种情况下，不会发生意外的业务流。
Different techniques could provide this functionality; however, their technical implementation can be complex to design and operate. An operator could, for instance, employ VPN Routing and Forwarding (VRF) tables [RFC4364] to store the routes announced to a neighbor and forward traffic exclusively based on those routes. A presentation from 2009 [on_BGP_RS_VPNs] describes the use of such an architecture for Internet routing and provides a description of its limitations.
不同的技术可以提供这种功能；然而，它们的技术实现在设计和操作上可能很复杂。例如，运营商可以使用VPN路由和转发（VRF）表[RFC4364]来存储向邻居宣布的路由，并专门基于这些路由转发流量。2009年的一篇演讲[关于_-BGP_-RS_-VPNs]描述了这种架构在互联网路由中的使用，并描述了其局限性。
In such architecture, packets received from a peer would be forwarded solely based on the paths that fit the path propagation policy for that peer and not based on the global routing table of the router. As a result, a more-specific path that would not be propagated to a peer will not be used to forward a packet from that peer, and the unexpected flow will not take place. Packets will be forwarded based on the policy-compliant, less-specific prefix. However, note that an operator must make sure that all their routers could support the potential performance impact of this approach.
在这种架构中，从对等方接收的分组将仅基于适合该对等方的路径传播策略的路径而不是基于路由器的全局路由表来转发。因此，不会传播到对等方的更特定路径将不会用于转发来自该对等方的数据包，并且不会发生意外流。数据包将根据符合策略且不太特定的前缀转发。但是，请注意，运营商必须确保其所有路由器都能支持此方法的潜在性能影响。
Note that similar to the solution described in Section 4.1, this approach could create conflicts between AS64502 and AS64501, since the traffic forwarding performed by AS64502 goes against the policy of AS64501.
请注意，与第4.1节中描述的解决方案类似，这种方法可能会在AS64502和AS64501之间产生冲突，因为AS64502执行的流量转发违反AS64501的策略。
This document describes how filtering and selective propagation of more-specific prefixes can potentially create unexpected traffic flows across some ASes. We provided examples of scenarios where these practices lead to unexpected traffic flows and introduce some techniques for their detection and prevention. Although there are reasonable situations in which ASes could filter more-specific prefixes, network operators are encouraged to implement this type of filter considering the cases described in this document. Operators can implement monitoring systems to detect unexpected traffic flows and react to them according to their own policy.
本文档描述了过滤和选择性传播更具体的前缀如何可能在某些ASE之间产生意外的流量。我们提供了这些实践导致意外交通流的场景示例，并介绍了一些检测和预防技术。尽管存在ASE可以过滤更具体前缀的合理情况，但考虑到本文档中描述的情况，鼓励网络运营商实施此类过滤器。运营商可以实施监控系统来检测意外的交通流，并根据自己的政策做出反应。
It is possible for an AS to use any of the methods described in this document to deliberately reroute traffic flowing through another AS. This document described the potential routing security issue and analyzed ways for operators to defend against it.
AS可以使用本文档中描述的任何方法故意重新路由流经另一AS的流量。本文档描述了潜在的路由安全问题，并分析了运营商防范该问题的方法。
It must be noted that, at the time of this document, there are no existing or proposed tools to automatically protect against such behavior. Operators can use network monitoring and collection tools to detect unexpected flows and deal with them on a case-by-case basis.
必须注意的是，在编写本文档时，没有任何现有或拟议的工具可以自动防止此类行为。运营商可以使用网络监控和收集工具来检测意外流量，并根据具体情况进行处理。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，DOI 10.17487/RFC1812，1995年6月<http://www.rfc-editor.org/info/rfc1812>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, DOI 10.17487/RFC4384, February 2006, <http://www.rfc-editor.org/info/rfc4384>.
[RFC4384]Meyer，D.，“BGP社区用于数据收集”，BCP 114，RFC 4384，DOI 10.17487/RFC4384，2006年2月<http://www.rfc-editor.org/info/rfc4384>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011]Claise，B.，Ed.，Trammell，B.，Ed.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，DOI 10.17487/RFC7011，2013年9月<http://www.rfc-editor.org/info/rfc7011>.
[INIT7-RIPE63] Kunzler, F., "How More Specifics increase your transit bill (and ways to avoid it)", Reseaux IP Europeens (RIPE) 63rd Meeting, October 2011, <http://ripe63.ripe.net/presentations/48-How-more-specifics-increase-your-transit-bill-v0.2.pdf>.
[INIT7-RIPE63]Kunzler，F.，“更多细节如何增加你的运输账单（以及避免的方法）”，欧洲研究IP（RIME）第63次会议，2011年10月<http://ripe63.ripe.net/presentations/48-How-more-specifics-increase-your-transit-bill-v0.2.pdf>.
[on_BGP_communities] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM Computer Communication Review, Volume 38, Number 2, pp. 55-59, DOI 10.1145/1355734.1355743, April 2008, <http://www.sigcomm.org/sites/default/files/ccr/ papers/2008/April/1355734-1355743.pdf>.
[关于BGP社区]Donnet，B.和O.Bonaventure，“关于BGP社区”，ACM SIGCOMM计算机通信评论，第38卷，第2期，第55-59页，DOI 10.1145/1355734.13557432008年4月<http://www.sigcomm.org/sites/default/files/ccr/ papers/2008/April/1355734-1355743.pdf>。
[on_BGP_RS_VPNs] Vanbever, L., Francois, P., Bonaventure, O., and J. Rexford, "Customized BGP Route Selection Using BGP/MPLS VPNs", Cisco Systems, Routing Symposium, October 2009, <http://inl.info.ucl.ac.be/system/files/ Cisco_NAG_2009_ns_bgp.pdf>.
[on_BGP_RS_VPNs]Vanbever，L.，Francois，P.，Bonaventure，O.，和J.Rexford，“使用BGP/MPLS VPN的定制BGP路由选择”，思科系统，路由研讨会，2009年10月<http://inl.info.ucl.ac.be/system/files/ Cisco_NAG_2009_ns_bgp.pdf>。
[PMACCT] "pmacct project: IP accounting iconoclasm", <http://www.pmacct.net>.
[PMACCT]“PMACCT项目：知识产权会计反传统”<http://www.pmacct.net>.
Acknowledgements
致谢
The authors would like to thank Wes George, Jon Mitchell, Bruno Decraene, and Job Snijders for their useful suggestions and comments.
作者要感谢韦斯·乔治、乔恩·米切尔、布鲁诺·德雷恩和乔布斯·斯奈德斯提出的有用建议和评论。
Authors' Addresses
作者地址
Camilo Cardona IMDEA Networks/UC3M Avenida del Mar Mediterraneo, 22 Leganes 28919 Spain
Camilo Cardona IMDEA Networks/UC3M地中海大道，22 Leganes 28919西班牙
Email: juancamilo.cardona@imdea.org
Email: juancamilo.cardona@imdea.org
Pierre Francois Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞塔斯曼大道西170号皮埃尔·弗朗索瓦·思科系统公司，邮编95134
Email: pifranco@cisco.com
Email: pifranco@cisco.com
Paolo Lucente Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞塔斯曼大道西170号保罗·朗森特思科系统公司，邮编95134
Email: plucente@cisco.com
Email: plucente@cisco.com